Deteriorat bază de date (ajutor, baza mea de date este corupt

bazei de date deteriorat - aceasta este, probabil, una dintre cele mai grave cosmaruri pentru majoritatea administratori de baze de date. Rezultatul este deteriorarea întreruperi, strigătele de manageri și tot felul de alte lucruri neplăcute.
În acest articol, voi explica faptul că este imposibil de a face cu o bază de date deteriorat, și să descrie unele din ceea ce trebuie făcut, unele tipuri de leziuni și modul în care acestea pot fi corectate.

Cum de a detecta faptul că baza de date este corupt

De obicei, daune detectate perfect atunci când încearcă să acceseze pagina afectată. Interoghează backup sau procedură Reindexare eșuează cu un nivel ridicat de severitate.
Iată câteva exemple de mesaje de sistem atunci când detectează deteriorarea bazei de date:
SQL Server a detectat o eroare logică I bazată pe consistență / O: checksum incorectă (de așteptat: 0xfdff74c9; real: 0xfdff74cb). Acesta a avut loc în timpul unei citire a paginii (1: 69965) în baza de date ID 13 compensate la 0x0000002229a000 în fișierul „D: \ Dezvoltarea \ Baze de date \ Broken1.mdf“.
Încercarea de a prelua pagina logică 1: 69 965 în baza de date 13 nu a reușit. Ea aparține unității de alocare 281474980642816 nu 72057594049069056.

Ce ar trebui să fac în cazul în care baza de date este încă intactă

1. Nu intrați în panică
2. Nu îndepărtați (detașați) l
3. Nu reporniți SQL Server
4. Nu recupera în curând
5. Rulați o verificare a integrității
6. găsi cauza

Nu intrați în panică

Cel mai important lucru atunci când detectează deteriorarea bazei de date - este de a nu intra în panică. Orice decizii ar trebui să fie cântărite cu atenție, în considerare ar trebui să fie luate toți factorii posibili. Fir-ar agrava doar situația prin adoptarea deciziei nu este pe deplin informat.

Nu detașați baza de date

În cele mai multe cazuri, atunci când SQL Server obnarzhivaet corupție de baze de date, aceasta înseamnă că, de fapt, baza de date au deteriorat pagini. Încercarea de a convinge SQL Server care nu este adevărat, prin deconectarea (Detașare) și reatașarea (atașați) baza de date, backup și recuperare, serviciul SQL Server este repornit, sau serverul este repornit, nu conduc la faptul că eroarea va dispărea.
În cazul în care baza de date este corupt, și SQL Server va detecta această aderare, nu va fi capabil să-l atașați. Există mai multe modalități de a obține-l pentru a vedea această bază de date, dar este mult mai bine să-l pur și simplu deconecta.

Nu reporniți SQL Server

În același mod ca atunci când deconectarea-aderare, reporniți serviciul SQL Server nu va fi capabil de a remedia erorile constatate (dacă este cazul).
Repornirea serviciul poate face situația mai rău. Dacă SQL Server detectează o eroare în timpul fazei de recuperare (de recuperare), după ce baza de date este repornită, ea va marca ca un „suspect“, care complică foarte mult procesul de recuperare a bazei de date.

Nu recupera în curând

Ați putea fi tentat să rula doar DBCC CHECKDB cu unul din „recuperare“ a parametrilor (de obicei, pierderea de date) și sperăm că totul va fi mai bine (în experiența mea - primul lucru pe care este recomandat în forumuri „non-core“ pe SQL Server - executați DBCC CHECKDB REPAIR_ALLOW_DATA_LOSS - nota traducătorului) .. Lansarea acestei reduceri nu este recomandată în multe cazuri. Aceasta nu garantează corecta toate erorile și poate duce la o pierdere inacceptabilă a datelor.
O astfel de recuperare - acesta este ultimul pas în corectarea erorilor. Ar trebui să fie pornit numai dacă aveți nici o altă opțiune, dar nu și în primul rând.

Rulați o verificare a integrității

găsi cauza

După ce sunt corectate erorile, lucrarea nu poate fi considerată completă. În cazul în care cauza erorii nu a fost stabilită, ele pot fi din nou. De obicei, principalul motiv pentru eroarea este o problemă cu subsistemul de intrare-ieșire, dar ele pot fi, de asemenea, cauzate de funcționarea necorespunzătoare a „software low-level“ (cum ar fi antivirus), un om de acțiune, sau bug-uri de SQL Server.

ce urmează

Informații incorecte despre spațiul liber de pe pagina

Msg 2508, nivel 16, statul 3, Linia 1
Pagina de date RSVD In rânduri conta pentru obiect "Broken1", indicele ID 0, partiție ID 76911687695381, Unitate alloc ID 76,911,687,695,381 (tip In-rand de date) este incorectă. Rulați DBCC UPDATEUSAGE.

Deteriorarea numai indicii non-cluster

În acest caz, prejudiciul poate fi corectată în totalitate prin îndepărtarea indicelui non-cluster deteriorate și re-crea acestora. Reconstruirea un index (ALTER INDEX REBUILD), în on-line (și, uneori, off-line) citește pagina de index vechi pentru a crea un nou și, prin urmare, nu reușește. Prin urmare, trebuie să eliminați indexul vechi și creați-l din nou.
Aceasta este ceea ce va face DBCC CHECKDB cu parametrul REPAIR_REBUILD, dar baza de date, în același timp, să fie în modul de utilizare unică. De aceea, de obicei, mai bine pentru a efectua manual aceste operațiuni la baza de date poate continua să funcționeze până când indicii sunt recreate.
Dacă aveți suficient timp încercând să re-crea indicele dorit și disponibil este „curat“ (care nu conține eroarea în sine) copie de siguranță completă și backup jurnal de tranzacții în lanț neîntrerupt de reviste, puteți repara pagini deteriorate ale acestora.

Deteriorările LOB-pagini

Msg 8964, nivel 16, statul 1, linia 1
Eroare Tabel: Object ID 181575685, index ID 1, partiția ID 72057594145669120, Unitate alloc ID 72057594087800832 (date LOB tip). Nodul de date off-rând la pagina (1: 2444050), slot 0, text ID 901891555328 nu se face referire.

Eroarea indică faptul că există LOB pagini (Large object), care nu se referă la o singură pagină de date. Acest lucru se poate întâmpla dacă anterior indicele de cluster a fost deteriorat (sau ciorchine) și pagini deteriorate au fost eliminate.
Dacă CHECKDB vorbește numai de astfel de erori, puteți rula DBCC CHECKDB cu opțiunea REPAIR_ALLOW_DATA_LOSS - aceste pagini vor fi distruse. Din moment ce încă nu au pagini de date, care se leagă de aceste pagini, o pierdere mare de date va fi plecat.

Erori asociate cu eliberarea de gama

Msg 2570, Sev 16, stat 3, linia 17
Pagina (1: 1103587), fanta 24 în ID obiect 34, indexul ID 1, partiția ID 281474978938880, Unitate alloc ID 281474978938880 (tip "In rânduri de date"). Coloana valoare „modificată“ este în afara intervalului pentru tipul de date „datetime“. Actualizați coloana la o valoare juridică.

Deteriorarea sau indicele de cluster haldei

În cazul în care se constată că gramada de pagini deteriorate sau nivelul de frunze (frunze de pagini) dintr-un indice de cluster - aceasta înseamnă că datele de pe ele se pierd. Pagini nivelul frunzelor de index grupat conține paginile de date în mod direct și pentru ei este furnizat nu redundanță.
Dacă rapoartele CHECKDB deteriora paginile de nivel de frunze ale indexului grupată, cerut „rata de recuperare“ pentru DBCC CHECKDB - REPAIR_ALLOW_DATA_LOSS.
Exemple de astfel de erori:
Server: Msg 8976, Nivel 16, stat 1, Linia 2
Eroare Tabel: Object ID 181575685, index ID 1, partiția ID 76911687695381, Unitate alloc ID 76,911,687,695,381 (tip In-rand de date). Pagina (1: 22417) nu a fost văzut în scanare, deși societatea-mamă (1: 479) și anterior (1: 715 544) se referă la ea. Server: Msg 8939, Nivel 16, stat 1, Linia 2
Eroare Tabel: Object ID 181575685, indice ID 0, pagina (1: 168576). Test (m_freeData> = PAGEHEADSIZE m_freeData <= (UINT)PAGESIZE - m_slotCnt * sizeof (Slot)) failed. Values are 44 and 8028.

Trebuie amintit faptul că în cazul în care erorile returnate checkdb, se referă la indicele id = 0 sau 1, ceea ce înseamnă că datele în sine este deteriorat.
Acest tip de eroare este corectată, dar corecția este de a distruge linii sau pagini întregi. Când CHECKDB șterge datele pentru a corecta eroarea, restricțiile impuse de chei străine, nu sunt verificate și nu conține declanșatoare nu se declanșează. Linia sau pagina doar șters. Ca urmare, datele nu pot fi convenite sau integritatea logică (LOB-la pagina nu mai poate invoca nici un rând sau o linie de index non-cluster poate indica „nicăieri“) poate fi compromisă. Din cauza acestor efecte, nu este recomandată o astfel de recuperare.
Dacă aveți o copie de rezervă „curat“, recuperarea este de obicei mai predpochitelnym pentru a corecta aceste erori. În cazul în care baza de date este în modelul de recuperare completă, și aveți copii de rezervă ale jurnalului de tranzacții cu lanț log neîntrerupt (începând de la ultima copie de rezervă „pur“ plin), puteți face o copie de rezervă a părții active a jurnalului și a restabili întreaga bază de date (sau doar paginile deteriorate), în prin care datele nu se vor pierde deloc.
În cazul în care nu există date de rezervă cu intacte, ai rămas cu doar o singură opțiune - pentru a rula DBCC CHECKDB cu opțiunea REPAIR_ALLOW_DATA_LOSS. Acest lucru va necesita baza de date de traducere în modul un singur utilizator pe durata acestei proceduri.
Cu toate că nu se poate preveni pierderea de date, puteți vedea ce date vor fi eliminate din index cluster. Pentru a face acest lucru, a verifica afară acest post de Paul Renadala.

deteriorarea metadatelor

Msg 3853, nivel 16, statul 1, linia 1
Atribut (object_id = 181,575,685) de rând (object_id = 181,575,685, column_id = 1) în sys.columns nu are un rând de potrivire (object_id = 181,575,685) în sys.objects.

daune ireparabile

CHECKDB nu poate rezolva totul. Orice erori, cum ar fi următoarele sunt incorigibili, iar singura cale - este restaurarea bazei de date dintr-o copie de rezervă, care nu are aceste leziuni. Dacă aveți o copie de siguranță completă și lanțul de jurnal nu este rupt până la ora actuală, puteți zabekapit fragmentul final al jurnalului de tranzacții și baza de date pot fi restaurate fără pierderi de date.
Dacă nu există copii de rezervă, singurul lucru pe care îl poți face - acele obiecte scriptate și încărcați datele care sunt încă disponibile. Este probabil că, din cauza prejudiciului, nu sunt disponibile toate datele, și, cel mai probabil, nu toate obiectele pot fi scriptate fara erori.

Deteriorarea tabelele de sistem

Msg 7985, Nivel 16, stat 2, linia 1
tabelul de sistem pre-controale: ID obiect 4. Nu s-a putut citi și pagina de blocare (1: 358) cu tipul SH declic.
Verificați declarația încheiată din cauza unei erori ireparabile. Msg 8921, nivel 16, statul 1, linia 1
Verificați terminat. O defecțiune a fost detectată în timp ce colectarea de fapte. Eventual tempdb în afara spațiului sau a unui tabel de sistem este incompatibil.

CHECKDB depinde de mai multe mese critice de sistem, în scopul de a obține o idee despre ceea ce ar trebui să fie în baza de date. Dacă faci aceste tabele sunt deteriorate, checkdb nu se poate imagina ceea ce ar trebui să fie în baza de date și ceva pentru a compara situația actuală, să nu mai vorbim de faptul de a repara ceva.

Deteriorarea la „distribuția de carduri“

Msg 8946, Nivel 16, stat 12, Linia 1
Eroare Tabel: Pagina de alocare (1: 2264640) are valori incorecte antet pagina PFS_PAGE. Tipul este 0. Verificați tipul, unitate aloc ID-ul și pagina de identitate pe pagină. Msg 8998, Nivel 16, stat 2, linia 1
erori de pagină de pe paginile GAM, SGAM sau PFS împiedice efectuarea unor controale de integritate de alocare în baza de date cu ID-ul de 13 de pagini de la (1: 2264640) la (1: 2272727)

În acest caz, una sau mai multe pagini care definesc localizarea datelor în baza de date (harta de distribuție - aprox. Translatori) deteriorate. Aceste pagini sunt utilizate pentru a determina care pagini și sunt utilizate în proporții baza de date, și care sunt gratuite. CHECKDB nu poate corecta aceste erori, deoarece este practic imposibil să se determine (fara aceste pagini), care sunt utilizate pentru extensiile de date, și care nu sunt. Eliminarea simplă a unei astfel imposibilă „carte de distribuție“, deoarece eliminarea oricăreia dintre ele atrage după sine eliminarea 4 GB de date.

Caută ajutor

Dacă nu sunteți sigur că trebuie să faceți - cere ajutor. Dacă dintr-o dată veți obține un mesaj despre efectele negative asupra unei baze de date pe care nu le înțelege și care nu este descris mai sus - cere ajutor. Dacă nu sunteți sigur ce să aleagă cea mai bună metodă de recuperare - cere ajutor.
Dacă aveți un DBA Senior, se referă la ea. Dacă aveți un „mentor“ - întreabă-l. Cere sfaturi pe forumuri, dar amintiți-vă că nu toate sfaturile primite pe forumuri utile. De fapt, ea a fost acolo din când în când să publice soluții absolut greșite și chiar periculoase.
Contactați Microsoft asistență pentru clienți la ultimul. Acesta nu este liber, dar ei chiar știu ce se poate face cu o bază de date deteriorat, și este probabil ca în cazul în care baza de date este critica pentru companie, costul de nefuncționare în timpul soluției de auto-căutare va fi mult mai mare decât costul tratamentului într-un suport.

concluzie

În acest articol, am dat câteva exemple de ceea ce se poate face atunci când detectează o bază de date deteriorat și, chiar mai important, ceea ce nu a făcut. Să sperăm că de acum să înțelegeți mai bine ce metode pot fi folosite pentru a rezolva problemele descrise mai sus, și cât de important este de a avea copii de siguranță bune (și alege corect modelul de recuperare - aprox. Interpret).