MS SQL. Suspect database state.

0

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 (‘YourDBname’) 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>’ ,

pe SQL SERVER 2008 folosim comanda:

EXEC(‘ALTER DATABASE <databaseName> SET EMERGENCY’)

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>’)

sau

ALTER DATABASE <database_name> REBUILD LOG ON(NAME=NumeleLog_Nou, FILENAME=‘<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

Leave A Reply