Sql101 de ce recuperarea dintr-o copie de rezervă este mai lentă decât crearea acesteia

SQLskills lansează o nouă inițiativă de postare a înregistrărilor cu cunoștințe de bază, numită SQL101. Vom scrie despre lucruri care, așa cum adesea vedem, sunt făcute incorect, tehnologii utilizate în mod incorect și multe neînțelegeri care duc la probleme grave. Dacă doriți să găsiți toate intrările din această serie, verificați linkul SQLskills.com/help/SQL101 (în engleză).







Una dintre întrebările pe care le întreabă mereu este motivul pentru care este nevoie de mai mult timp pentru a restaura o bază de date dintr-o copie de rezervă completă decât pentru a crea o copie de rezervă completă. Răspunsul este că aproape întotdeauna procesul de recuperare necesită mai multă muncă.

Crearea unei copii de rezervă complete include următorii pași principali:

  1. Creați un punct de control.
  2. Citirea tuturor datelor utilizate din fișierele de date (din punct de vedere tehnic, citirea tuturor extensiilor alocate, indiferent de câte dintre cele 8 pagini, în măsura în care se utilizează efectiv).
  3. Citirea jurnalului de tranzacții de la începutul celei mai vechi tranzacții nefixate de la punctul de control inițial până la momentul finalizării celei de-a doua etape. Este necesar ca baza de date să poată fi restaurată într-o stare convenită în momentul de timp al perioadei de rezervă (pentru a explica detaliat acest articol (în engleză)).
  4. (Opțional, testarea sumelor de control pentru toate paginile, efectuarea opțională a compresiei de copiere de rezervă și opțional criptarea copiei de rezervă).

Recuperarea dintr-o copie de rezervă completă include următorii pași principali:

Etapa 3 este deseori cea mai lungă etapă de recuperare și este proporțională cu dimensiunea jurnalului de tranzacții. Acest proces se desfășoară într-o etapă separată, în loc să fie efectuat în paralel cu etapa 1-2, iar pentru studiu aprofundat, consultați intrarea recentă a blogului lui Bob Ward.







Etapa 5 poate fi cea mai lungă etapă a procesului de recuperare, dacă au existat tranzacții lungi, neangajate în timpul copierii de rezervă. Și chiar mai mult, poate fi dacă există un număr mare de fișiere log logice (mii) în jurnalul de tranzacții, deoarece acestea încetinesc foarte mult mecanismul de reluare a tranzacțiilor neangajate.

Iată o listă a lucrurilor pe care le puteți face pentru a vă restabili dintr-o copie de rezervă completă mai repede:

  • Asigurați-vă că activarea instantanee a fișierelor este activată pentru o instanță a serverului SQL care efectuează operația de restaurare pentru a evita pierderea timpului pentru a popula orice fișiere de date care trebuie create cu zerouri. Acest lucru poate economisi ore de timp de nefuncționare pentru fișierele de date foarte mari.
  • Dacă este posibil, restaurați baza de date existentă - nu ștergeți fișierele existente. Acest lucru evită necesitatea creării și, eventual, umplerea cu zerouri a întregii cantități de fișiere, în special a fișierelor din jurnalul de tranzacții. Fiți foarte atenți atunci când utilizați acest element, deoarece baza de date existentă va fi distrusă imediat după ce procesul de restaurare începe să îl suprascrie.
  • Luați în considerare utilizarea compresiei de rezervă, acest lucru poate accelera operațiile și crea și restabili din copiile de rezervă și poate economisi spațiu pe disc și costurile de stocare.
  • Luați în considerare utilizarea mai multor fișiere de rezervă, fiecare dintre ele pe un volum separat. SQL Server recunoaște această situație și va folosi scrierea paralelă (un fir pe volum) pentru intrările de fișiere atunci când creează o copie de rezervă și o citire în timpul procesului de restaurare - accelerarea tuturor proceselor. Dacă aveți mai multe fișiere de baze de date, va exista o paralelizare similară a proceselor I / O - oferind o accelerare chiar mai mare.
  • Încercați să evitați tranzacțiile lungi, deoarece acestea vor dura mult timp până la revenirea înapoi.
  • Gestionați jurnalul de tranzacții astfel încât să evitați existența unui număr excesiv de fișiere istorice virtuale, astfel încât, dacă există tranzacții care necesită returnare, revocarea este cât mai rapidă posibil. Vedeți această intrare de blog (în engleză) pentru o explicație detaliată.

Sper că acest lucru a fost util!







Articole similare

Trimiteți-le prietenilor: