MS SQL. Suspect database state.

Ieri la un client am întâlnit o bază de date MS SQL cu statut de SUSPECT…pare că după restabilire totul e ok, cel puțin până acum nu a apărut nimic critic. Deci metoda e bună și verificată:

Baza de date poate fi cu status “SUSPECT” din mai multe cauze: defecțiuni tehnice, LOG-file sau MDF-file defecte, lipsa spațiului pe disc etc. Pentru a afla cauza exactă pentru care baza de date a intrat în modul “SUSPECT”, putem să utilizăm următoarea interogare

DBCC CHECKDB (‘DatabaseName’) WITH NO_INFOMSGS, ALL_ERRORMSGS

Începem restabilirea bazei de date. Pentru simplitate vom lua cazul când este afectată baza de date utilizator.

1. Oprim MS SQL SERVER;

2. Copiem într-un loc sigur fișierele mdf și log ale bazei de date avariate;

3. Pornim serverul și ștergem baza de date avariată. La acest moment în unele cazuri, când nu este posibilă ștergerea, va trebui corectarea tabelului de sistem sysdatabases;

4. Creem o bază de date nouă, cu același nume și aceeași locație, ca și baza de date suspectă;

5. Oprim serverul și înlocuim fișierul mdf nou creat, cu cel salvat precedent;

6. Pornim serverul. În acest moment starea suspectă a bazei de date pentru noi nu mai este o problemă.

7. Executăm scriptul, care ne va permite redactarea tabelelor de sistem

Use master 
go
sp_configure ‘allow updates’, 1
reconfigure with override 
go

8. Tot acolo executăm scriptul care ne va afișa numărul status al bazei de date avariate, de exemplu, 536870912 – funcțiile full-text sunt incluse și etc

select status from sysdatabases where name = ‘<DatabaseName>’

   memorizăm această valoare în cazul eșecului restabilirii log-ului

9. Tot acolo executăm scriptul care ne va duce baza de date în emergency mode

update sysdatabases set status= 32768 where name = ‘<DatabaseName>’

10. Resetăm MS SQL SERVER;

11. Baza de date trebuie să se afle în emergency mode, și deja nu în suspect mode;

12. Executăm scriptul, care va crea un nou fișier de log la baza avariată

DBCC REBUILD_LOG(‘<DatabaseName>’, ‘<numele fișierului nou de log cu locație>’)

13. Executăm următorul script – utilizarea bazei în regim single user

Use master 
go
sp_dboption ‘<DatabaseName>’, ‘single user’, ‘true’
GO 
DBCC CHECKDB(‘<DatabaseName>’, REPAIR_ALLOW_DATA_LOSS)

  a) Dacă nu s-a reușit utilizarea bazei în regim single user mode, atunci pentru verificarea integrității datelor se poate de încercat  dbo only mode

sp_dboption ‘<databaseName>’, ‘dbo use only’, ‘true’ 

 b) Dacă totul a mers bine, atunci executăm

sp_dboption ‘<databaseName>’, ‘single user’, ‘false’ 
go 
Use master 
go 
sp_configure ‘allow updates’, 0
go

NOTA.

1. Dacă în stare SUSPECT vom găsi, de exemplu, baza de date TEMPBD, atunci va trebui să folosim recomandările  http://support.microsoft.com/kb/q288809/

2. Găsim informație interesantă și pe http://support.microsoft.com/default.aspx/kb/328354

Cu respect.