Metodele de programare a operațiilor de backup și restaurare sunt cunoscute de mulți, la fel și în cazul folosirii comenzilor BACKUP și RESTORE. Majoritatea administratorilor de baze de date sunt familiarizați cu parametrii de comandă utilizați în mod obișnuit, dar puțini știu despre beneficiile unor parametri mai puțin cunoscuți. Aplicarea unor astfel de parametri va fi discutată în acest articol
Infrastructura IT pentru întreprinderea dvs.
Metodele de programare a operațiilor de backup și restaurare sunt cunoscute de mulți, la fel și în cazul folosirii comenzilor BACKUP și RESTORE. Majoritatea administratorilor de baze de date sunt familiarizați cu parametrii de comandă utilizați în mod obișnuit, dar puțini știu despre beneficiile unor parametri mai puțin cunoscuți. Aplicarea unor astfel de parametri va fi discutată în acest articol.
Verificarea integrității copiei de rezervă
Sunt de acord cu afirmația că nu există nicio copie de siguranță până când nu este restaurată. Din păcate, administratorii de baze de date uită adesea despre necesitatea de a verifica integritatea copiilor de rezervă. Ajutând vizitatorii la diverse forumuri pentru a face față pierderii de date, deseori aflu că și copiile de rezervă sunt corupte.
Suma de control a paginii este verificată de fiecare dată când pagina fișierului de date este citită în memorie pentru procesare. Cu toate acestea, acest lucru nu garantează detectarea tuturor distorsiunilor. Multe aplicații de lucru nu efectuează citirea regulată a tuturor paginilor plasate în baza de date, făcând acest lucru numai în timpul verificării integrității și al copierii complete. Când se verifică integritatea, se calculează sumele de control ale paginilor. Dar, în mod prestabilit, backup-urile complete și diferențiale nu efectuează controale de verificare a sumelor de control.
Ecranul 1. Un mesaj despre o eroare de rezervă din cauza paginii de corupție
Unii administratori de baze de date verifică integritatea backup-ului într-un alt mod: utilizând comanda RESTORE cu parametrul VERIFYONLY. Din păcate, este verificată numai antetul, dar nu datele de rezervă. Trebuie să utilizați comanda RESTORE cu doi parametri: CHECKSUM și VERIFYONLY. Doar în acest caz, procesul de recuperare verifică în mod repetat toate sumele de control ale paginilor și ale întregii copii de rezervă. Rețineți că nu puteți verifica sumele de control ale paginilor de rezervă create fără parametrul CHECKSUM.
Reducerea pierderii de date în caz de accident
Adesea, prima reacție a administratorului bazei de date în caz de accident este trecerea la un sistem de rezervă sau pornirea unei restaurări dintr-o copie de rezervă. Odată ce operația de restaurare este pornită, capacitatea de a stoca ultima porțiune din jurnalul de tranzacții este pierdută iremediabil. Aceasta este o copie de siguranță a fragmentului final al jurnalului: porțiunea de jurnal care nu este scrisă în copie de rezervă este cunoscută ca coada jurnalului.
Ecranul 2. Un mesaj de eroare de rezervă din cauza fișierelor de date lipsă sau deteriorate
Creșteți viteza de salvare
Majoritatea administratorilor de baze de date nu bănuiesc că puteți îmbunătăți în mod semnificativ viteza de backup. Sunt obținute mai multe avantaje, printre care:
* Reducerea prezenței timpului în sistemul de volumul de lucru suplimentar pe sistemul de intrare-ieșire (și potențial - CPU aeriene asociate cu compresie de rezervă);
* Reduce pericolul de proliferare a jurnalului de tranzacții, fișierul jurnal ca urmare a tranzacțiilor generate în timpul de rezervă, în special în timpul copie de siguranță a bazei de date completă prelungită.
Reducerea timpilor de întrerupere după un accident
Un obiectiv comun al unei operații de restaurare este de a restabili cât mai puține date posibil pentru a reduce timpul de întrerupere. Odată cu apariția metodei de restaurare etapă-etapă, această sarcină a devenit mult mai ușoară. Un avantaj suplimentar este restaurarea treptată în modul online. În timpul unei operații pas cu pas, este restabilită doar o parte a bazei de date, de exemplu, o pagină (utilizând parametrul PAGE) sau un fișier (cu parametrul FILE). Recuperarea online on-line resuscită o parte din baza de date, iar restul bazei de date rămâne accesibil. Acest lucru este posibil din cauza disponibilității parțiale a bazei de date.
Doar câțiva administratori utilizează recuperarea unei singure pagini. Se poate recupera orice pagină, cu condiția să existe o modalitate de a aduce pagina de recuperare la ora curentă, cu excepția hărților de alocare de biți, care funcționează în întreaga întreaga bază de date și pagini unice, cum ar fi antetele de boot și fișiere (aceleași restricții se aplică corectarea automată pagini cu oglindirea bazei de date). Prin urmare, trebuie să aveți o copie de rezervă a jurnalului de tranzacții. Unele pagini (de exemplu, care conțin metadate de tabel) nu pot fi restaurate online, dar sunt restaurate cu succes offline.
Uneori doriți să restaurați întregul o bază de date foarte mare (VLDB), dar chiar și în acest caz, puteți reduce timpul necesar pentru a transfera baza de date pentru a veni on-line, oferind acces parțial la bazele de date și folosind o recuperare treptată în modul on-line. În acest caz, doar un fragment din baza de date este restabilit și pus online. Ca urmare, utilizatorii nu trebuie să aștepte până când întreaga bază de date este restabilită.
Recuperarea punct-în-timp
Uneori este necesară restaurarea bazei de date pentru un anumit moment, și nu pentru cel mai recent moment. Exemplu: unele date au fost șterse și este necesar să se restabilească baza de date cu o copie de siguranță a jurnalului creat chiar înainte ca datele să fie șterse. Dacă știți timpul de ștergere, puteți utiliza pur și simplu parametrul STOPAT astfel încât recuperarea jurnalului să nu depășească un anumit interval de timp.
O abordare alternativă este utilizarea tranzacțiilor marcate. În acest caz, etichetele speciale sunt create în jurnalul de tranzacții. exemplu:
Ulterior, acest punct cunoscut poate fi folosit pentru a restabili baza de date. Puteți restabili baza de date "la", inclusiv tranzacția cu tag, utilizând parametrul STOPATMARK. Dacă trebuie să restaurați baza de date "înainte", dar fără a include tranzacția marcată, utilizați parametrul STOPBEFOREMARK.
Pentru a aplica oricare dintre aceste opțiuni, trebuie să știți numele etichetei jurnalului. În cazul în care nu au fost scrise de mână, ele pot fi găsite în tabelul din logmarkhistory msdb (un alt motiv pentru MSDB de date de backup a bazei de date). Dacă informațiile din tabelul istoric de istoric se pierd, este dificil să găsiți numele etichetelor jurnalului. Pentru a face acest lucru, trebuie să utilizați un instrument terță parte sau comenzi de copiere de jurnal și jurnal fără documente.
Dacă un nume de etichetă este utilizat în mod repetat, trebuie să specificați un timp de oprire utilizând parametrul AFTER. În caz contrar, oprirea apare la prima etichetă, care coincide cu numele specificat în instrucțiunea RESTORE.
Repornirea unei operații de restaurare întreruptă
CU RESTART este unul dintre parametrii puțin cunoscuți ai comenzii RESTORE. Cu aceasta, puteți reporni o operație de restaurare întreruptă. Operația de restaurare scrie periodic un fișier de puncte de control, ceea ce indică în ce punct sa efectuat restaurarea. Fișierele punct de control (care nu sunt legate de punctele de control baza de date uzuale) sunt stocate în folderul \ InstanceName \ MSSQL \ Backup.
Fișierul de punct de control este actualizat în următoarele condiții:
* A fost finalizată crearea și completarea unui fișier de bază de date cu zerouri;
* Toate seturile de date de rezervă sunt procesate;
* Etapa de repetare este finalizată în timpul recuperării.
Dacă fișierul de punct de control există și este utilizat parametrul WITH RESTART, toți pașii deja întreprinși vor fi săriți. Dacă se aplică WITH RESTART și lipsește fișierul de control, se va afișa mesajul afișat pe ecranul 3.
Ecranul 3. Mesaj de eroare: nu a fost detectat niciun punct de control
Parametrul cel mai util
Sunt adesea întrebat care dintre opțiunile puțin cunoscute de backup și recuperare este cea mai utilă. Enorma câștig în viteză poate fi obținută prin reglarea bufferele de intrare-ieșire prin intermediul parametrilor BUFFERCOUNT și MAXTRANSFERSIZE. Datorită unei recuperări de o singură pagină și a pasului cu etapă, utilizând parametrii PAGE și PARTIAL, perioada de downtime după un accident este redusă semnificativ. Dar dacă ar trebui să specific un singur parametru, aș fi ales NO_TRUNCATE pentru a face backup pentru fragmentul final al jurnalului. Aceasta este singura modalitate de a efectua recuperarea chiar înainte de accident, dacă fișierele de date nu sunt disponibile.
Distribuiți materialul împreună cu colegii și prietenii
Articole similare
Trimiteți-le prietenilor: