Restaurarea bazelor de date MySQL folosind metode manuale și „mecanice”. Recuperarea fișierelor de bază de date MySQL șterse

Citit, cum să recuperezi pierdut sau bază la distanță MySQL. Cum să recuperați mesele deteriorate baze de date MySQL folosind myisamchk. Baza de date MySQL este instalată implicit pe computer într-un folder de pe unitatea C:

C:\Program Files\MySQL\My SQL Server 5.7

Dar datele din tabel sunt stocate în fișiere într-un alt folder de pe unitatea C a computerului, acesta este:

Locația acestor fișiere este indicată în meniul Stare server aplicații MySQL Workbench, în secțiunea Server Directories.

Dacă trebuie să restaurați tabelele bazei de date, veți fi interesat de folderul cu datele unei anumite baze de date și fișierele care se află în aceasta.

Conţinut:

Fișierele bazei de date MySQL

MySQL este compatibil cu o cantitate mare formate de fișiere, cum ar fi: .sql, .arm, .cnf, .dbs, .ddl, .frm, .ibd, .ism, .mrg, .myd, .myi, .mysql, .opt, .phl, .sal , .sqr, .tmd, .arz, .ibz, .ibc, .qbquery, .rul. Dar acest articol nu este despre asta. Astăzi ne interesează tocmai acele fișiere în care sunt stocate date și tabele de baze de date, prin restaurare pe care utilizatorul le va putea returna Informații importanteși să evite posibila pierdere a acestuia în viitor.

Datele fiecărei baze de date sunt stocate într-un folder cu numele său și, în funcție de tipul tabelului, sunt stocate în fișiere cu următoarele extensii:

db.opt– un fișier în care sunt stocate caracteristicile bazei de date specificate la crearea acesteia;
.frm– fisier structura tabelului;
.myd– un fișier în care sunt stocate datele tabelelor MyISAM;
.myi– un fișier în care sunt stocați indecși ai tabelelor MyISAM;
.ibd– un fișier în care sunt stocate datele și indecșii tabelelor InnoDB.

Cum se restabilește o bază de date MySQL

Restaurarea unei baze de date MySQL nu este tehnic proces dificil, dar depinde de multe condiții. Pentru utilizatorii MySQL Funcția de banc de lucru este furnizată ExportȘi Import/Restaurare datele bazei de date.

În plus, este posibil să creați o copie de rezervă și să restaurați baza de date Date MySQL prin utilizarea mysqldump(pe care am descris-o în detaliu într-unul dintre articolele noastre).

Dar aceste caracteristici sunt mai mult legate de crearea de copii de siguranță a datelor MySQL folosind instrumente încorporate. Utilizatorii mai avansați sau cei care nu au folosit la timp funcția de backup a datelor bazei de date MySQL vor fi, de asemenea, interesați de metoda de creare a copiilor și restaurare manuală a datelor bazei de date, prin înlocuirea fișierelor de structură și a datelor de tabel descrise mai sus:

Crearea unei copii a datelor din tabelul bazei de date MySQL este posibilă prin copierea fișierelor de structură și de date (*.opt, *.frm, *.myd, *.myi pentru MyIsam; *.opt, *.frm, *.ibd pentru InnoDB) și salvându-le într-un alt folder.
Restaurarea datelor din tabelele bazei de date MySQL este posibilă prin înlocuirea structurii copiate anterior și a fișierelor de date în folderele bazelor de date existente (în cazul nostru, acestea sunt două baze de date: my_db și my_db2).

Recuperarea unei baze de date MySQL pierdute sau șterse

Deci, dacă dintr-un motiv oarecare ați șters baza de date MySQL, ați reinstalat Windows sau ați formatat HDD, apoi îl puteți restaura folosind metoda descrisă mai sus, plasând fișierele de bază de date copiate anterior în folderul cu numele bazei de date:

C:\ProgramData\MySQL\MySQL Server 5.7\Data

Dacă utilizatorul nu a creat o copie a fișierelor bazei de date în avans, acestea pot fi restaurate folosind , și apoi transferate în folderul doritîn modul descris mai sus.

Pentru aceasta:

Recuperarea tabelelor de baze de date MySQL deteriorate folosind myisamchk

Tabelele bazei de date MyISAM MySQL pot fi deteriorate ca urmare a întreruperii neașteptate a procesului de înregistrare sau a închiderii computerului, a defecțiunilor hardware sau software, și, de asemenea, în cazul încercării de a depana folosind myisamchk tabelul folosit de server.

Ca urmare a corupției, datele pot dispărea din tabel sau se pot afișa incorect, dar cel mai adesea, ca urmare a coruperii tabelului, utilizatorii întâmpină următoarea eroare: „Fișier cheie incorect pentru tabel: ‘table_name’. Încearcă să-l repari"

Pentru a restaura tabelele MyISAM deteriorate, puteți folosi comanda myisamchk.

Myisamchk funcționează prin depanarea și crearea unei copii a fișierului .myd și apoi înlocuind fișierul deteriorat cu acesta. Prin urmare, înainte de utilizare această comandă, este mai bine să creați mai întâi copie de rezervă fișier tabel care trebuie restaurat.

Deci, pentru a restaura un tabel deteriorat, utilizați comanda:

myisamchk -r -q TABLE_NAME

Unde, -r -q– acesta este modul recuperare rapida. ÎN în acest caz, va fi fixat fișier index fără a modifica fișierul de date. Dacă fișierul de date conține tot ce este necesar și legăturile de la distanță indică pozitii corecteîn fișierul de date, tabelul va fi corectat ca urmare a acestei comenzi.

Dacă comanda anterioară nu dă rezultatul cerut, apoi faceți o copie de rezervă a fișierului de date și rulați comanda:

myisamchk -r TABLE_NAME

Unde, -r- este doar modul de recuperare. În acest caz, intrările incorecte și pierdute vor fi șterse din fișierul de date, iar fișierul index va fi creat din nou (așa cum este descris mai sus).

Notă. Dacă intenționați să depanați și să restaurați tabelul din Linie de comanda, atunci trebuie mai întâi să opriți serverul. Trebuie remarcat faptul că atunci când rulați mysqladmin shutdown cu server la distanta mysqld va rula în continuare pentru o perioadă de timp după ce mysqladmin iese, până când toate interogările sunt oprite și toate cheile sunt spălate pe disc.

Astăzi la lecție: MySQL.(MySQL este un sistem gratuit de gestionare a bazelor de date). Restaurarea unei baze de date este destul de simplă, dar pentru a face acest lucru trebuie să aveți o copie de rezervă a bazei de date. Când am avut probleme cu baza de date, nu am putut accesa site-ul, iar toate articolele mele au dispărut. A trebuit să decid urgent cum să refac baza de date Wordprerss.

Această situație mi s-a întâmplat acum câteva zile, când scriam lecția 59. Literal, câteva minute mai târziu, am primit un SMS de la Yandex Metrica că site-ul meu nu era disponibil. Dacă ați mai întâlnit o astfel de problemă, atunci știți cum să returnați totul conditii de lucru, iar dacă nu, citiți mai departe.

Cum să restaurați baza de date WordPress (metoda 1)

Majoritatea oamenilor scriu pe Internet cum să facă o copie de rezervă a bazei de date, dar puțini oameni scriu, cum se restabilește baza de date Date WordPress . Nu este necesar ca cu Bază de date Pot apărea probleme din vina dumneavoastră. Pot apărea erori în baza de date din alte motive.

Dacă blogul tău nu a instalat încă un plugin sau unul similar, atunci riști să rămâi fără blog. Imaginează-ți că faci blog pentru o lungă perioadă de timp, și apoi o dată, și atât! Amba! Acest plugin va împiedica acest lucru să se întâmple. Păstrează permanent baza de date a blogului tău mod automatși fără participarea dvs.

Există o mulțime de informații despre recuperarea bazelor de date pe Internet, dar uneori scriu astfel de prostii pentru care oamenii sunt de asemenea recunoscători. Autorul articolului oferă sfaturi despre cum să faci asta și asta corect, dar el însuși nici măcar nu înțelege despre ce scrie. Gata, a venit timpul sa trecem la treaba :)

Pentru a vă readuce blogul la starea anterioară, trebuie să aveți o copie de rezervă nouă a bazei de date. Despachetați fișierul bazei de date și deschideți fișierul despachetat în Blocnotes Windows. Copiați conținutul fișierului în . Accesați panoul de control al găzduirii dvs. în PhpMyAdmin.

Faceți clic pe numele bazei de date pe care doriți să o restaurați.

Apoi trebuie să faceți clic pe „SQL" și inserați în fereastră ceea ce ați copiat din fișierul bazei de date făcând clic pe " CTRL " + "V". Faceți clic mai târziu " Bine ".

Așteptați până când restaurarea bazei de date este finalizată. Ar trebui să apară un mesaj de succes.

Blogul dvs. este acum complet restaurat.

Cum să restabiliți rapid baza de date WordPress (metoda 2)

Deci, fără introduceri inutile. Accesați găzduirea dvs. în panou de control(cPanel). Găsiți linkul " MySQL" sau " PhpMyAdmin ».

Acum trebuie să vă conectați la panoul de gestionare a bazei de date, adică PhpMyAdmin. Faceți clic pe " A intra»

Veți fi dus la PhpMyAdmin. În stânga, faceți clic pe baza de date pe care urmează să o restaurați. În cazul meu, aceasta este baza de date dvpress.

Odată ce selectați o bază de date, vor apărea toate tabelele din acea bază de date. Pentru a vă asigura că nu apar erori în timpul recuperării, această bază de date trebuie ștearsă complet. Coborâm în fund și găsim „ Marcați tot / Deselectați " Click pe " Selectează tot „astfel încât toate tabelele bazei de date să aibă o bifă în caseta de selectare. Selectați în fereastra din dreapta " Șterge"si apoi confirma" da". Baza de date ar trebui să fie complet șters de toate tabelele.

Acum sarcina dvs. este să restaurați această bază de date dintr-o copie de rezervă. Faceți clic în partea de sus " Import", apoi faceți clic pe butonul " Alege fișierul " Găsiți copia de rezervă a bazei de date pe computer și faceți clic pe „ Deschis" Acum, în PhpMyAdmin, în partea de jos, faceți clic pe „ Bine" Operația trebuie să aibă succes, ceea ce ar trebui să fie indicat prin inscripția „ interogare SQL finalizat cu succes ».

SQL Server acceptă trei tipuri variate copii de rezervă – backup complet, backup diferențial și backup jurnal de tranzacții. Primele două tipuri de copii de rezervă sunt disponibile pentru bazele de date în orice model de recuperare, o copie de rezervă a jurnalului de tranzacții este disponibilă pentru bazele de date în modelul de recuperare FULL și BULK-LOGGED (puteți citi pe scurt despre modelele de recuperare, sau mai bine zis, în BOL).

Dacă utilizați modelul de recuperare SIMPLE, veți putea să vă restaurați baza de date numai dintr-o copie de rezervă completă (bine și, în plus, copie diferenţială). Nu vă veți recupera niciodată la un moment dat înainte de defecțiune, cu excepția cazului în care ați creat o copie de rezervă imediat înainte de defecțiune. Dacă baza ta de date este în modelul de recuperare COMPLET și nu faci niciodată o copie de rezervă a jurnalului de tranzacții, dar tăiați jurnalul din când în când, citiți mai departe pentru a afla ce pierdeți :).

Dacă citiți acest lucru, presupun că baza de date este în modelul de recuperare COMPLET, faceți în mod regulat copii de rezervă complete și copii ale jurnalului de tranzacții. În plus, „lanțul de recuperare” din backup-urile jurnalului de tranzacții ar trebui să fie intact.

Ce este „lanțul de recuperare”? Aceasta este o secvență continuă de copii de siguranță constând dintr-o copie de rezervă completă și o secvență continuă de copii de siguranță ale jurnalului de tranzacții. De exemplu, la 12.30 ai creat backup complet(să-i spunem full1), iar la 12.45, 13.00 și 13.15 au creat copii de rezervă ale jurnalului de tranzacții (trlog1, trlog2, trlog3, respectiv). Atâta timp cât aveți toate aceste copii de siguranță, veți putea să vă restaurați baza de date în orice moment între 12.30 și 13.15, 12.48 de exemplu.

Dacă ștergeți copia trlog2 creată la 13.00, atunci copia de rezervă a trlog3 (și toate copiile făcute ulterior) va deveni complet inutilă - puteți restaura în orice moment între 12.30 și 12.45. Același lucru se va întâmpla dacă cineva creează o copie la 12.31 și o șterge - toate copiile ulterioare vor fi inutile. Pentru a începe un nou lanț de recuperare, va trebui să faceți o copie de rezervă completă și apoi o copie de rezervă a jurnalului de tranzacții.

Există un moment nu foarte evident (cel puțin pentru mine) în toate acestea. O copie de rezervă completă începe întotdeauna, dar nu întrerupe niciodată lanțul de restaurare (acest lucru este valabil pentru SQL Server 2005 și mai vechi). Să ne uităm la asta cu un exemplu. Pe lângă copiile existente (full1, trlog1, trlog2, trlog3 - un lanț de recuperare continuă), vom face o copie de rezervă completă a full2 la 13.30 și copii de rezervă ale jurnalului de tranzacții trlog3, trlog4, trlog5 la 13.45, 14.00 și 14.15, respectiv.

Acum, dacă trebuie să restaurăm baza de date la 14.15, cel mai simplu mod este să folosim lanțul de recuperare „noul”, adică. restaurați full2 și „roll” trlog3, trlog4, trlog5 pe el secvențial. Dar, dacă se dovedește că nu putem recupera de la copierea completă2 (de exemplu, discul care conține această copie a fost distrus), atunci putem folosi „primul” nostru lanț de recuperare - restaurați copia de rezervă full1 și rulați secvențial copii ale jurnalului de tranzacții trlog1 , trlog2 pe el, trlog3, trlog4, trlog5, trlog6. În același mod, putem folosi primul lanț de recuperare pentru a restaura baza de date la 13.29 - restaurăm full1 și rulăm trlog1, trlog2, trlog3 și trlog4.

Astfel, având un lanț de recuperare complet, ne putem restabili baza necesară date în orice moment între momentul în care a fost creată backupul complet și momentul în care a fost creată ultima copie de rezervă. Un mic indiciu - dacă ai model complet recuperare, există mai multe copii de rezervă și nu există copii ale jurnalului de tranzacții, dar nu ați „trunchiat” niciodată jurnalul de tranzacții - puteți crea această copie de rezervă chiar acum și puteți restabili în orice moment între momentul primului backup complet și ora momentului curent. Dar, repet, doar dacă backup-urile jurnalului de tranzacții nu au fost create înainte și jurnalul de tranzacții nu a fost tăiat.

În continuare, vă voi spune mai multe moduri de a utiliza backup-urile SQL Server.
Prima opțiune (funcționează pentru toate modelele de recuperare) este necesară restaurați o bază de date dintr-o copie de rezervă completă. Totul este simplu aici - trebuie să rulați scriptul T-SQL:

RESOTRE DATABASE [nume_database]
FROM DISK = „calea către backup complet”
CU ÎNLOCUIRE, RECUPERARE, STATISTICI = 10

Parametrul REPLACE indică faptul că, dacă există o bază de date numită [database_name], atunci vom înlocui conținutul acesteia cu conținutul copiei de rezervă. Dacă restaurați o bază de date utilizând GUI, trebuie să specificați „Suprascrieți baza de date existentă” în fila „Opțiuni”.

RECOVERY indică faptul că baza de date trebuie adusă într-o stare consecventă și să permită conexiunile utilizatorilor. În GUI, aceasta corespunde opțiunii „Lăsați baza de date gata de utilizare prin anularea tranzacțiilor necommitate. Jurnalele de tranzacții suplimentare nu pot fi restaurate." Adică, SQL Server derulează înapoi toate tranzacțiile neangajate și permite utilizatorilor să lucreze cu datele. După ce ați restaurat copia de rezervă de la cu parametrul RECOVERY, nu i se pot aplica copii suplimentare ale jurnalului de tranzacții și copii diferențiale. Fiți atenți, această opțiune este setată implicit și dacă doriți să „rulați” o altă copie, procesul de recuperare va trebui să înceapă din nou.

STATS = 10 este responsabil pentru afișarea informațiilor despre procesul de recuperare. În acest caz, când fiecare 10% din backup este restaurat, va apărea un mesaj în fila Mesaje din SSMS. Când restaurați folosind GUI, nu puteți controla acest parametru - puteți monitoriza modificările din „graficul” din colțul din stânga jos.

În mod implicit, copia este restaurată în aceeași locație de unde a fost făcută. Acestea. dacă inițial toate fișierele bazei de date se aflau în directorul C:\Database și doriți să restaurați copia într-o altă locație, atunci trebuie să utilizați parametrul MOVE. Pentru a utiliza MOVE trebuie să cunoașteți numele fișierelor logice - acestea pot fi vizualizate folosind vizualizarea sys.database_files. Figura prezintă un exemplu de utilizare a acestei vederi.

Prin urmare, pentru a restaura baza de date AdventureWorks dintr-o copie de rezervă și, în același timp, pentru a o muta în altă locație, puteți utiliza următorul script:

CU ÎNLOCUIRE, RECUPERARE, STATISTICI = 10,

Dacă restaurarea este efectuată folosind GUI, trebuie să specificați nume de fișiere noi în fila „Opțiuni” (tabelul „Restaurați fișierele bazei de date ca:”, coloana „Restaurare ca”).

A doua varianta - restaurarea dintr-o copie de rezervă completă și toate copiile de rezervă ale jurnalului de tranzacții(sau copii diferențiale).

O restaurare începe întotdeauna cu restaurarea unui backup complet, dar dacă doriți să restaurați orice copii suplimentare după aceea, trebuie să lăsați baza de date în starea RESTAURARE. Pentru a face acest lucru, vom folosi următorul script:

RESTAURARE BAZĂ DE DATE
FROM DISK = „D:\backup\awfull.bak”
CU ÎNLOCUIRE, NORECUPERARE, STATISTICI = 10,
MUTAȚI „AdventureWorks_Data” ÎN „D:\database\AW_data.mdf”,
MUTAȚI „AdventureWorks_Log” ÎN „D:\database\AW_log.ldf”

Dacă după efectuarea restaurării încerci să accesezi baza de date, vei primi eroarea:
Baza de date „AdventureWorks” nu poate fi deschisă. Este în mijlocul unei restaurări.
După restaurarea copiei de rezervă completă, restaurați ultima copie diferențială (dacă există):

RESTAURARE BAZĂ DE DATE
FROM DISK = „D:\backup\awDIFF.bak”
CU NORECOVERY, STATISTICI = 10

Dacă aveți un model SIMPLU, vă puteți opri aici - nu veți face nimic altceva. Dacă aveți un model FULL, puteți în plus derulați înapoi copiile de rezervă ale jurnalului de tranzacții:

RESTAURARE Jurnal
FROM DISK = „D:\backup\awlog1.trn”
CU NORECOVERY
….
RESTAURARE Jurnal
FROM DISK = „D:\backup\awlog12.trn”
CU RECUPERARE

Notă, ultima copie trebuie restaurat cu parametrul RECOVERY. Dacă baza de date rămâne în starea RESTAURARE, aceasta poate fi introdusă stare operaționalăși fără copii de rezervă:

RESTAURARE BAZĂ DE DATE
CU RECUPERARE

După aceasta, baza de date va „reveni la viață”.
A treia varianta - recuperare punct în timp. Am baza de date AdventureWorks, o copie de rezervă completă a acesteia și o copie de rezervă a jurnalului de tranzacții de mai devreme. Rezultatul cererii

SELECTAȚI *
FROM Person.AddressType

prezentat în figură:

La ora 13.46 acest tabel a fost șters. Aceeași interogare returnează acum:
Nume obiect nevalid „Person.AddressType”
Pentru a readuce totul la locul său, în primul rând facem o copie de rezervă a jurnalului de tranzacții:

Jurnalul de backup
TO DISK = „D:\backup\awlog2.trn”

Odată ce copia este creată, restaurați copia de rezervă completă și prima copie de rezervă a jurnalului de tranzacții (ambele cu parametrul NORECOVERY).
Acum să restaurăm ultima copie de rezervă creată DUPĂ ștergerea tabelului:

RESTAURARE Jurnal
CU RECUPERARE, STOPAT = "09/10/2010 13:45"
(data aici este specificată în formatul „LL/ZZ/AAAA HH:LL”)
După aceasta, interogarea originală returnează un rezultat normal, tabelul a fost restaurat.

O altă opțiune pentru recuperarea datelor. Povestea vieții :).
Acum câteva luni ne-am trezit într-o situație nu tocmai plăcută - înregistrările într-unul din registrele de informații (periodice, nesubordonate registratorului) erau „corupte”. Adică par să fi rămas, dar și-au pierdut sensul. Registrul era mare și necesar. Eroarea a apărut în urmă cu câteva ore, așa că a fost imposibil să restaurați complet baza de date. Urmau să transfere date folosind procesarea XML Data UploadLoading, dar programatorii au cerut să încerce transferul de date folosind SQL, în speranța că va fi mai rapid.

Am restaurat o copie a bazei de date de la copii de rezervă până la momentul anterior coruperii datelor. Folosind funcția „GetDatabaseStorageStructure”, am aflat numele registrului de informații din baza de date - _InfoReg4452 (de exemplu, nu îmi amintesc exact). Am șters acest registru „deteriorat” din baza de date principală folosind TRUNCATE TABLE _InfoReg4452.
Pe copia bazei de date am selectat TASKS -> ExportData, a fost specificată o copie cu registru normal ca sursă, un server de lucru și o bază de date de lucru (cu registru șters) ca destinație. Pe pagina de selecție a obiectelor, am selectat doar unul – tabelul de care avem nevoie:

Încă două clicuri de mouse și gata. Masa a fost mutată, oamenii au continuat să lucreze.
Aș dori să vă atrag atenția asupra mai multor nuanțe. În primul rând, dacă nu ștergeți tabelul de destinație, toate datele vor rămâne în el și este posibil să nu apară altele noi. În al doilea rând, această metodă poate fi potrivită pentru unele registre și directoare de informații, dar pentru tabelele pe care se fac mișcări sau obiecte care fac mișcări, va fi necesar să se restabilească multe mese suplimentare– Gândește-te de 100 de ori înainte de a folosi această metodă. Ei bine, în general, această metodă este împotriva acord de licențiere, dar este rapid și convenabil în unele cazuri.
Sper că această informație a fost de folos măcar cuiva.

P.S. Nu mă crede pe cuvânt - încearcă să faci toate acestea pe copiile tale!

Pentru dezvoltatori și administratori Microsoft SQL Server destul de des apare nevoia restaurarea unei baze de date dintr-o arhivă(backup), de exemplu, pentru a crea o copie a bazei de date care va fi folosită pentru a testa aplicația sau, de exemplu, ați reinstalat sistem de operareși trebuie să restaurați baza de date, care este exact ceea ce vom face astăzi.

În acest articol ne vom uita la recuperarea bazei de date folosind un SGBD ca exemplu. Microsoft SQL Server 2000. Pentru a restaura o bază de date, trebuie să aveți o arhivă a acestei baze de date. Este creat cu extensia *.dat. Recomand tuturor să creeze arhive ale bazelor lor de date și ale celor zilnice; dacă se întâmplă ceva, veți avea întotdeauna o arhivă de restaurat.

Descrierea procesului de restaurare a unei baze de date din Backup

Să începem, deschideți Enterprise Manager, selectați baza de date pe care doriți să o restaurați sau dacă tocmai ați instalat DBMS și nu există încă baze de date acolo, atunci pur și simplu creați o bază de date și restaurați-o din arhivă. Deschide meniul " Instrumente->Restaurare baza de date"și se va deschide următoarea fereastră:

Selectați " De la dispozitiv" și faceți clic pe " Selectați Dispozitive».

(banner de poziție de încărcare 3

Faceți clic pe OK și în „ Alegeți Restaurare bază de date» faceți clic și pe OK. Și în fereastra principală " Restaurați baza de date„Nu vă grăbiți să faceți clic pe OK încă, accesați fila „ Opțiuni» și bifați caseta ca în imagine.

Tot aici setați calea pentru fișierele bazei de date, deoarece poate fi incorectă și puteți suprascrie, de exemplu, baza existenta date, dacă creați o copie a bazei de date și dacă tocmai ați instalat totul (DBMS), atunci nu trebuie să o modificați.

Asta e, după aceea poți să dai clic pe OK. După ceva timp, baza de date va fi restaurată și o puteți utiliza.

Apropo, daca e cineva interesat Limbajul T-SQL (este o extensie a limbajului SQL din Microsoft SQL Server), atunci pot recomanda cartea „ Calea programatorului T-SQL. Tutorial limbajul Transact-SQL", după ce ai citit-o vei putea programa cu ușurință în T-SQL.

Pe care l-am postat săptămâna trecută părea să trezească un oarecare interes, dar, din păcate, nu conținea „practică”. Da, spune cum puteți salva datele, dar nu există exemple.
Inițial, am vrut să fac o altă traducere a aceluiași autor, dar după ce m-am gândit la asta, am decis să scriu o postare „pe cont propriu”, parcă „pe baza ei”. Voi descrie motivele care m-au determinat să fac asta la finalul postării, în note.

Restaurarea bazelor de date în SQL Server

După cum sa menționat în articolul anterior, dacă paginile unui index cluster sau ale unui heap sunt deteriorate, atunci datele conținute în aceste pagini se pierd și singura opțiune de recuperare este restaurarea directă a bazei de date.

SQL Server oferă multe opțiuni pentru recuperarea bazei de date. În primul rând, aceasta este o restaurare a întregii baze de date - poate dura destul de mult timp (în funcție de dimensiunea bazei de date și viteza grea discuri). În al doilea rând, recuperarea grupurilor de fișiere individuale sau a fișierelor dacă baza de date constă din mai multe grupuri de fișiere (sau, în consecință, fișiere). În acest caz, este posibil să restaurați numai părțile deteriorate ale bazei de date fără a afecta restul. Aceste două tipuri de recuperare a bazelor de date sunt folosite destul de des și nu vor fi discutate în continuare.
În al treilea rând, SQL Server 2005 a introdus capacitatea de restaurare pagini individuale DB - numai în acest caz pagini specificate. O astfel de recuperare va fi deosebit de importantă dacă DBCC CHECKDB găsește mai multe pagini deteriorate într-un tabel imens „întins” într-un fișier voluminos. Datorită faptului că nu întregul fișier și nici măcar întregul tabel, ci doar câteva pagini vor fi restaurate, timpul de nefuncționare poate fi redus semnificativ.

Cerințe și restricții

Model de recuperare și disponibilitatea copiilor de rezervă ale jurnalului de tranzacții

Cel mai important lucru de reținut este că pentru a recupera pagini individuale, baza de date trebuie să utilizeze un model de recuperare complet sau în bloc. Dacă bazele de date sunt într-un model simplu de recuperare, nu trebuie să citiți mai departe.
A doua cerință este ca backup-urile dvs. complete și ale jurnalului de tranzacții trebuie să formeze un lanț de jurnal neîntrerupt. Dacă nu lansați niciodată comanda BACKUP LOG WITH TRUNCATE_ONLY (NO_LOG) și comutați la model simplu recuperare pentru a reduce jurnalul de tranzacții și aveți TOATE copiile de rezervă ale jurnalului de tranzacții de la ultima copie de rezervă completă care nu conține pagini corupte (inclusiv cea mai completă copie de rezervă) - nu trebuie să vă faceți griji cu privire la lanțul de jurnal.
În modelul de recuperare în jurnal în bloc, teoretic, recuperarea paginilor individuale ar trebui să funcționeze bine, atâta timp cât condițiile descrise mai sus sunt îndeplinite și paginile care sunt recuperate nu au fost modificate de operațiunile înregistrate liber.

Edițiile SQL Server

Restaurarea paginilor este posibilă în orice ediție de SQL Server, dar pentru Enterprise Edition și Developer Edition este posibilă restaurarea paginilor deteriorate on-line, de ex. baza de date poate fi accesată în timpul recuperării (și, în plus, puteți accesa chiar și tabelul care este restaurat în acest moment pagini, dacă aceste pagini în sine nu vor fi „atuse” - în caz contrar, cererea va eșua). Pentru edițiile „de mai jos” Enterprise Edition, restaurarea paginii are loc off-line, iar baza de date devine inaccesibilă în timpul perioadei de restaurare.

Tipul paginii deteriorate

Dacă paginile de index sau de date sunt deteriorate, acestea pot fi restaurate online în Enterprise Edition.
Paginile care aparțin tabelelor de sistem critice pot fi restaurate, dar baza de date, atunci când este restaurată, nu va fi disponibilă în nicio ediție a SQL Server.
„Cartele de plasare” nu pot fi restaurate „separat”. Dacă paginile GAM, SGAM, PFS, ML, DIFF sunt deteriorate, este necesară restaurarea întregii baze de date. Singura excepție sunt paginile IAM. Deși sunt clasificate ca „hărți de locație”, ele descriu un singur tabel, nu întreaga bază de date și pot fi restaurate.
Pagina de încărcare a bazei de date (a 9-a pagină din primul fișier al bazei de date) și pagina antetului fișierului (a 0-a pagină din fiecare fișier) nu pot fi restaurate „separat”; dacă sunt deteriorate, întreaga bază de date va trebui restaurată.

De fapt, restaurare

Acum, în sfârșit, trecem de la teorie la practică.
În primul rând, pentru antrenament, aveți nevoie de o bază de date coruptă.

Portarea bazei de date

Pentru experimentele mele, voi folosi baza de date AdventureWorks care vine cu SQL Server. Dacă nu l-ați instalat, îl puteți descărca dacă doriți. O traduc în modelul de recuperare completă:
ALTER DATABASE AdventureWorks SET RECOVERY FULL Mă asigur că nu există încă erori în ea:
DBCC CHECKDB(„AdventureWorks”) WITH NO_INFOMSGS, ALL_ERRORMSGS, DATA_PURITY și creați o copie de rezervă completă:
BACKUP DATABASE AdventureWorks PE DISK = „D:\tmp\aw_backups\aw_full_ok1.bak”

În această bază de date creez un tabel de blocare.
Crash CREATE TABLE (txt varchar(1000)) Vom corupe câmpul de tip varchar pentru a verifica ce se va întâmpla dacă SQL Server găsește brusc în el date care nu sunt aceleași cu cele scrise acolo.
Înainte de a strica ceva, trebuie să-l umpleți cu ceva. Introduc datele din stânga în tabelul creat.
SET NOCOUNT ON DECLARE @i INT SET @i = 1 WHILE @i<100000 BEGIN INSERT INTO crash SELECT REPLICATE("a", 1000) SET @i = @i + 1 END SET NOCOUNT OFF Теперь делаю резервную копию журнала транзакций:
JURUL DE BACKUP AdventureWorks TO DISK = „D:\tmp\aw_backups\aw_log_ok1.trn”

Acum să schimbăm puțin datele:

Deci, totul este gata. Deconectam baza de date și deschidem fișierul mdf cu FAR (sau orice este mai convenabil pentru dvs.), căutăm linia „zzzzzzz” în ea și înlocuim mai multe „z” cu caractere arbitrare:

Acum că baza de date este coruptă, o conectăm. Și, da, îmi amintesc că în articolul precedent s-a spus clar că nu trebuie să detașați/atașați baza de date. Dar în cazul nostru este absolut „sigur” - baza de date în „suspect” nu va cădea.

Caut erori

Deci, baza de date deteriorată a revenit în funcțiune cu succes. Să rulăm din nou verificarea integrității:
DBCC CHECKDB(„AdventureWorks”) WITH NO_INFOMSGS, ALL_ERRORMSGS, DATA_PURITY Rezultatul este ceea ce așteptam ( Asigurați-vă că vă amintiți numărul de pagini deteriorate!):

Mesajul 8928, nivel 16, stat 1, linie 1
ID obiect 1883153754, ID index 0, ID partiție 72057594054246400, ID unitate aloc 72057594061651968 (tip Date în rând): Pagina (1:20455) nu a putut fi procesată. Vedeți alte erori pentru detalii.
Mesajul 8939, Nivelul 16, Statul 98, Linia 1
Eroare de tabel: ID obiect 1883153754, ID index 0, ID partiție 72057594054246400, ID unitate aloc 72057594061651968 (tip Date în rând), pagina (1:20455). Testul (IS_OFF (BUF_IOERR, pBUF->bstat)) a eșuat. Valorile sunt 29493257 și -4.
CHECKDB a găsit 0 erori de alocare și 2 erori de consistență în tabelul „crash” (ID obiect 1883153754).
CHECKDB a găsit 0 erori de alocare și 2 erori de consistență în baza de date „AdventureWorks”.
repair_allow_data_loss este nivelul minim de reparare pentru erorile găsite de DBCC CHECKDB (AdventureWorks).
În acest caz, datele în sine situate în heap (index id = 0) sunt deteriorate, astfel încât SQL Server nu va putea recupera aceste date.
În acest moment avem trei opțiuni:

Acceptați pierderea datelor și rulați DBCC CHECKDB ("AdventureWorks", REPAIR_ALLOW_DATA_LOSS)
Faceți o copie de rezervă a părții active a jurnalului de tranzacții și restaurați întreaga bază de date - nu va exista nicio pierdere de date ca urmare, dar va dura mult timp
Faceți o copie de rezervă a părții active a jurnalului de tranzacții și restaurați o singură pagină deteriorată (!).

Cu a doua opțiune, totul ar trebui să fie clar, dar voi arăta ce se întâmplă dacă rulați DBCC CHECKDB sau cum sunt restaurate paginile individuale.

Restaurarea unei pagini deteriorate

În primul rând, trebuie să facem o copie de rezervă a fragmentului final al jurnalului de tranzacții (backup de coadă). În același timp, dacă aveți o ediție Enterprise, nu trebuie să adăugați parametrul NORECOVERY, care va pune baza de date în starea de „restaurare”, deoarece această ediție acceptă restaurarea paginii online. Mai mult, dacă aveți copii de siguranță ale jurnalului de tranzacții efectuate în mod regulat, pentru a nu rupe lanțul de jurnal, în Enterprise Edition, puteți face o copie de rezervă COPY_ONLY.
Urmează calea recuperării off-line și fac:
JURUL DE BACKUP AdventureWorks TO DISK = „D:\tmp\aw_backups\aw_log_fail3.trn” CU NORECOVERY

Acum, puteți restaura pagina deteriorată. În primul rând, folosim o copie de rezervă completă (aw_full_ok1.bak):

RESTAURĂ BAZA DE DATE AdventureWorks PAGE = "1:20455" FROM DISK = "D:\tmp\aw_backups\aw_full_ok1.bak" CU NORECOVERY
Ca urmare, avem:

Vă rugăm să rețineți că trebuie să utilizați opțiunea NORECOVERY, deoarece încă mai trebuie să rulăm copiile de rezervă ale jurnalului de tranzacții pe ea.
RESTAURARE JURUL AdventureWorks FROM DISK = „D:\tmp\aw_backups\aw_log_ok1.trn” CU NORECOVERY și
RESTAURARE JURUL AdventureWorks DE PE DISK = „D:\tmp\aw_backups\aw_log_fail3.trn” CU RECUPERARE

Totul pare să fi mers bine, hai să rulăm DBCC CHECKDB și...

Restaurarea a avut succes.
Vă rugăm să rețineți că timpul de nefuncționare este redus datorită faptului că dintr-o copie de rezervă completă nu restaurăm întreaga bază de date, ci doar paginile deteriorate (dacă aș fi restaurat întreaga copie de rezervă, backup-ul ar fi fost restaurat în 8,5 secunde, dar cu cât era mai mare). dimensiunea bazei de date, diferența de timp va fi mai mare). Cei norocoși cu SQL Server Enterprise Edition care folosesc recuperarea on-line vor economisi timp și la restaurarea din backup-urile de jurnal, iar cu recuperarea off-line, din păcate, jurnalele vor fi procesate în întregime.
De asemenea, merită adăugat că în SQL Server 2005, 2008, 2008 R2, restaurarea unei singure pagini este posibilă numai folosind T-SQL; în Denali, a devenit posibil să se facă acest lucru prin GUI.

Dar dacă este DBCC CHECKDB?

Pentru orice eventualitate, am decis să verific ce ar face SQL Server dacă aș rula DBCC CHECKDB cu parametrul REPAIR_ALLOW_DATA_LOSS. Tot aceeasi eroare:

Mai întâi, comutăm baza de date în modul SINGLE_USER:
ALTER DATABASE AdventureWorks SET SINGLE_USER Apoi, începem recuperarea:
DBCC CHECKDB(„AdventureWorks”, REPAIR_ALLOW_DATA_LOSS) WITH NO_INFOMSGS, ALL_ERRORMSGS, DATA_PURITY Ca rezultat:
Reparație: Pagina (1:20455) a fost dealocată de la ID obiect 1883153754, ID index 0, ID partiție 72057594054246400, ID unitate aloc 72057594061651968 (tip Date în rând).
Da, SQL Server a șters pagina „coruptă”. Trecem baza de date în modul MULTI_USER, astfel încât să devină accesibilă tuturor și verificăm ce lipsește:

Având în vedere că dimensiunea paginii în SQL Server este de 8KB, iar pentru datele utilizatorului este disponibil ceva mai puțin, totul este firesc, tabelul a „slăbit” cu 7 înregistrări (la început erau 99999). Deoarece nu a existat un index grupat pe acest tabel, datele puteau fi stocate în ordine aleatorie, adică nici măcar nu am putut ști ce date s-ar pierde.

Deci, de ce, la urma urmei, nu o traducere?

Deci, de ce aceasta nu este o traducere, ci o postare „bazată pe”? Faptul este că articolul „Restaurare pagină” scris de Gail Shaw nu este disponibil public. Există o astfel de secțiune în cartea SQL Server MVP Deep Dives vol.2, care se vinde pentru o sumă destul de importantă de bani (dar, desigur, se găsește ușor pe Internet) și nu sunt sigur că publicarea traducerii are um... dreptate sau ceva.
În general, am citit articolul, am luat notă de punctele principale, apoi am scris singur textul și, pe parcurs, am efectuat un experiment de restaurare. Sper că această experiență a fost de folos cuiva.
Și, domnilor, sper din tot sufletul că dacă vă decideți să repetați acest experiment, veți fi extrem de atenți (de exemplu, nu veți experimenta cu baza de date principală de pe serverul de producție). Amintiți-vă că nu îmi asum nicio responsabilitate pentru acțiunile dvs.