ce este avertisment: baza de date < db-nume> este SUSPECT? Probabil ați văzut o bază de date marcată ca SUSPECT în SSMS și nu știți ce reprezintă. Citiți mai jos articolul pentru a afla mai multe detalii despre acest lucru!
ce este avertisment: baza de date db-numele este SUSPECT?
uneori ne putem confrunta cu o situație critică, datorită bazei noastre de date SQL Server care intră în modul Suspect. În acel moment, baza de date nu mai poate fi utilizată și nu se poate face nicio lucrare.
principalul motiv pentru care baza de date intră în modul suspect este că grupul de fișiere primar a fost deteriorat și baza de date nu poate fi recuperată în timpul pornirii SQL Server.
de asemenea, baza de date poate ajunge în starea suspectă din mai multe alte motive, care pot include:
- o defecțiune a sistemului care ar putea fi cauzată de o închidere necorespunzătoare a serverului bazei de date
- un fișier jurnal deteriorat sau un fișier MDF deteriorat
- în cazul în care nu mai există spațiu pe disc
- SQL Server nu poate finaliza o operațiune de derulare înainte sau de revenire
- limitări în ceea ce privește spațiul pentru sistemele de fișiere FAT32 și alte motive
pentru a repara baza de date și a vă recupera din această stare, va trebui să faceți următorii pași:
- vom începe prin schimbarea stării bazei de date prin executarea procedurii stocate sp_resetstatus
EXEC sp_resetstatus 'TestDB'
- setați baza de date la modul „de urgență”
ALTER baza de date TestDB set de urgență;
- verificați baza de date pentru eventualele neconcordanțe
DBCC checkdb ('TestDB');
- în cazul în care întâmpinați erori în timpul fazei DBCC, puneți baza de date imediat în modul utilizator unic cu ajutorul interogării de mai jos:
ALTER baza de date TestDB set SINGLE_USER cu ROLLBACK imediat;
- de asemenea, în acest moment, din motive de siguranță, vă recomandăm să faceți o copie de rezervă a bazei de date
- după ce ați terminat de făcut o copie de rezervă a bazei de date, ar trebui să continuați să executați următoarea interogare. Dar amintiți-vă că în timp ce utilizați următoarea interogare, cu parametrul REPAIR_ALLOW_DATA_LOSS, executați o operație într-un fel care vă va repara baza de date, dar toate acțiunile efectuate în timpul acestui proces nu pot fi derulate înapoi. Nu există nicio soluție pentru a reveni la o stare anterioară a bazei de date, motiv pentru care vă recomandăm cu tărie să faceți backup-ul pe care l-am sugerat la punctul anterior
DBCC CheckDB ('TestDB', REPAIR_ALLOW_DATA_LOSS);
- ultima interogare pe care ar trebui să o executați este să setați baza de date în modul MULTI USER
ALTER baza de date TestDB SET MULTI_USER;
- ultimul pas este să reîmprospătați serverul bazei de date și să verificați dacă conectivitatea la baza de date funcționează. După acest punct, utilizatorii ar trebui să aibă posibilitatea de a se conecta la baza de date. În cazul în care există pierderi de date, puteți restaura baza de date pe care ați făcut backup anterior