În ciuda faptului că în materialele noastre anterioare am abordat deja problema copierii de rezervă a bazelor de date Microsoft SQL Server, răspunsul cititorului a arătat nevoia de a crea un material cu drepturi depline, cu un studiu mai profund al părții teoretice. Într-adevăr, articolele realizate cu accent pe instrucțiuni practice vă permit să configurați rapid o copie de rezervă, dar nu explică motivele alegerii uneia sau a altei setari. Vom încerca să remediem acest decalaj.
Modele de recuperare
Înainte de a începe să configurați o copie de rezervă, ar trebui să alegeți un model de recuperare. Pentru alegerea optimă, ar trebui să evaluați cerințele de recuperare și severitatea pierderii de date, comparându-le cu costurile generale ale implementării unui anumit model.
După cum știți, baza de date MS SQL constă din două părți: baza de date în sine și jurnalul de tranzacții al acesteia. Baza de date conține date despre utilizatori și servicii la momentul curent, jurnalul de tranzacții include istoricul tuturor modificărilor bazei de date pentru o anumită perioadă, având jurnalul de tranzacții, putem derula înapoi starea bazei de date în orice moment arbitrar.
Sunt oferite două modele de recuperare pentru utilizare în medii de producție: simplu si complet... Exista si un model cu înregistrare incompletă, dar este recomandat doar ca o completare la modelul complet pentru perioada operațiunilor în vrac la scară largă, atunci când nu este necesară restaurarea bazei de date la un anumit moment în timp.
Model simplu prevede doar backup-ul bazei de date, prin urmare, putem restabili starea bazei de date numai în momentul efectuării copiei de rezervă, toate modificările dintre crearea ultimei backup și eșec se vor pierde. În același timp, o schemă simplă are o mică suprasarcină: trebuie doar să stocați copii ale bazei de date, jurnalul de tranzacții este trunchiat automat și nu crește în dimensiune. De asemenea, procesul de recuperare este cel mai simplu și nu necesită mult timp.
Model complet vă permite să restaurați baza de date în orice moment arbitrar, dar necesită, pe lângă backupul bazei de date, să stocați copii ale jurnalului de tranzacții pentru întreaga perioadă pentru care poate fi necesară recuperarea. Cu lucrul activ cu baza de date, dimensiunea jurnalului de tranzacții și, în consecință, dimensiunea arhivelor, pot ajunge la dimensiuni mari. Procesul de recuperare este, de asemenea, mult mai complex și consumator de timp.
Atunci când alegeți un model de recuperare, ar trebui să comparați costul recuperării cu costul stocării backup-urilor și, de asemenea, trebuie să luați în considerare disponibilitatea și calificările personalului care va efectua recuperarea. Recuperarea cu un model complet necesită anumite calificări și cunoștințe din partea personalului, în timp ce cu o schemă simplă, va fi suficient să urmați instrucțiunile.
Pentru bazele de date cu o cantitate mică de informații suplimentare, poate fi mai profitabil să folosiți un model simplu cu o frecvență mare de copiere, care vă va permite să recuperați rapid și să continuați să lucrați prin introducerea manuală a datelor pierdute. Modelul complet ar trebui utilizat în primul rând acolo unde pierderea de date este inacceptabilă, iar posibila recuperare a acestuia este asociată cu costuri semnificative.
Tipuri de copii de rezervă
Copie integrală a bazei de date- după cum sugerează și numele, reprezintă conținutul bazei de date și o parte a jurnalului de tranzacții activ pentru momentul în care a fost formată copia de rezervă (adică informații despre toate tranzacțiile curente și incomplete). Vă permite să restaurați complet baza de date în momentul efectuării copiei de rezervă.
Copie diferențială a bazei de date- o copie integrală are un dezavantaj semnificativ, conține toate informațiile din baza de date. Dacă trebuie să faceți copii de siguranță destul de des, atunci se pune imediat întrebarea privind utilizarea irosită a spațiului pe disc, deoarece cea mai mare parte a spațiului de stocare va fi ocupată de aceleași date. Pentru a elimina acest dezavantaj, puteți utiliza copii diferențiate ale bazei de date, care conțin doar informații care s-au modificat de la ultima copie completă.
Vă rugăm să rețineți că o copie diferențială reprezintă date din ultima dată complet copierea, adică fiecare copie diferențială ulterioară conține datele celei precedente (dar în același timp pot fi modificate) iar dimensiunea copiei va crește constant. O copie de rezervă completă și una diferențială, de obicei cea mai recentă, sunt suficiente pentru recuperare. Numărul de copii diferențiale trebuie selectat în funcție de creșterea dimensiunii lor, de îndată ce dimensiunea copiei diferențiale este egală cu dimensiunea a jumătate din cea completă, este logic să faceți o nouă copie completă.
Backup pentru jurnalul tranzacțiilor- se aplică numai modelului de recuperare completă și conține o copie a jurnalului de tranzacții din momentul în care a fost creată copia anterioară.
Este important să rețineți următorul punct - copiile jurnalului de tranzacții nu sunt în niciun fel legate de copiile bazei de date și nu conțin informații din copiile anterioare, prin urmare, pentru a restaura baza de date, trebuie să aveți un lanț neîntrerupt de copii pentru perioada din timpul perioadei. pe care doriți să puteți derula înapoi starea bazei de date. În acest caz, momentul ultimei copieri reușite trebuie să fie în această perioadă.
Să ne uităm la figura de mai sus, dacă prima copie a fișierului jurnal este pierdută, atunci puteți restabili starea bazei de date numai în momentul copierii complete, care va fi similar cu un model de recuperare simplu, puteți restabili starea a bazei de date în orice moment în timp numai după următoarea copie diferențială (sau completă), cu condiția ca lanțul de copii de jurnal pornind de la cel care precede copierea bazei și în continuare să fie continuu (în figură - de la a treia încolo). ).
Jurnal de tranzacții
Pentru a înțelege procesele de recuperare și scopul diferitelor tipuri de backup, ar trebui să aruncați o privire mai atentă asupra structurii și funcționării jurnalului de tranzacții. O tranzacție este cea mai mică operațiune logică posibilă care are sens și poate fi efectuată numai în întregime. Această abordare asigură integritatea și consistența datelor în toate situațiile, deoarece starea intermediară a operațiunii este inacceptabilă. Jurnalul de tranzacții este conceput pentru a controla orice modificări în baza de date.
La efectuarea oricărei operațiuni, se adaugă în jurnalul de tranzacții o înregistrare despre începutul unei tranzacții, fiecărei înregistrări i se atribuie un număr unic (LSN) dintr-o secvență care nu se poate sparge, ori de câte ori se modifică datele, se introduce o înregistrare corespunzătoare în jurnal și după operațiunea este finalizată, în jurnal apare un semn de închidere a tranzacției (commit).
La fiecare pornire, sistemul analizează jurnalul de tranzacții și derulează înapoi toate tranzacțiile necommitate; în același timp, are loc trecerea înainte a modificărilor care au fost comise în jurnal, dar nu au fost scrise pe disc. Acest lucru face posibilă utilizarea memoriei cache și a scrierilor leneșe fără teama de integritatea datelor chiar și în absența sistemelor de alimentare de rezervă.
Partea din jurnal care conține tranzacții active și este utilizată pentru recuperarea datelor se numește partea activă a jurnalului. Începe cu un număr numit Număr minim de recuperare (MinLSN).
În cel mai simplu caz, MinLSN este numărul de înregistrare al primei tranzacții în așteptare. Dacă te uiți la figura de mai sus, atunci prin deschiderea unei tranzacții albastre vom obține MinLSN egal cu 321, după ce este înregistrat în înregistrarea 324, numărul MinLSN se va schimba în 323, care va corespunde numărului verde, nu încă comis, tranzacție.
În practică, totul este puțin mai complicat, de exemplu, este posibil ca datele unei tranzacții albastre închise să nu fie încă spălate pe disc și mutarea MinLSN la 323 va face recuperarea acestei operațiuni imposibilă. Pentru a evita o astfel de situație a fost introdus conceptul de punct de control. Un punct de control este creat automat atunci când sunt îndeplinite următoarele condiții:
- Când se execută în mod explicit instrucțiunea CHECKPOINT. Punctul de control este declanșat în baza de date a conexiunii curente.
- Când efectuați o operațiune înregistrată minim pe o bază de date, cum ar fi efectuarea unei operațiuni de copiere în bloc pe o bază de date care este acoperită de un model de recuperare înregistrată în bloc.
- Când adăugați sau eliminați fișiere de bază de date folosind instrucțiunea ALTER DATABASE.
- Când opriți instanța SQL Server folosind instrucțiunea SHUTDOWN sau când opriți serviciul SQL Server (MSSQLSERVER). În ambele cazuri, un punct de control va fi creat pentru fiecare bază de date în instanța SQL Server.
- Dacă instanța SQL Server creează periodic puncte de control automate în fiecare bază de date pentru a scurta timpul de recuperare al bazei de date.
- La efectuarea unei copii de rezervă a bazei de date.
- Când efectuați o acțiune care necesită închiderea bazei de date. Exemplele includ setarea AUTO_CLOSE la ON și închiderea ultimei conexiuni a utilizatorului la baza de date sau modificarea unui parametru al bazei de date care necesită repornirea bazei de date.
În funcție de evenimentul care a avut loc mai devreme, MinLSN i se va atribui valoarea fie a numărului de înregistrare a punctului de control, fie a începutului celei mai vechi tranzacții în așteptare.
Trunchierea jurnalului de tranzacții
Jurnalul de tranzacții, ca orice jurnal, necesită curățarea periodică a înregistrărilor învechite, altfel va crește și va ocupa tot spațiul disponibil. Având în vedere că atunci când lucrați activ cu o bază de date, dimensiunea jurnalului de tranzacții poate depăși semnificativ dimensiunea bazei de date, această problemă este relevantă pentru mulți administratori.
Din punct de vedere fizic, fișierul jurnal de tranzacții este un container pentru jurnalele virtuale, care sunt completate secvenţial pe măsură ce jurnalul crește. Jurnalul logic care conține intrarea MinLSN este începutul jurnalului activ, jurnalele logice care îl preced sunt inactive și nu sunt necesare pentru recuperarea automată a bazei de date.
Dacă este selectat modelul de recuperare simplă, atunci când jurnalele logice ating dimensiunea egală cu 70% din fișierul fizic, partea inactivă a jurnalului este curățată automat, așa-numita. trunchiere. Totuși, acest lucru nu reduce fișierul jurnal fizic, doar jurnalele logice sunt trunchiate și pot fi reutilizate după această operație.
Dacă numărul de tranzacții este mare și nu există jurnale logice inactive până la atingerea a 70% din dimensiunea fișierului fizic, atunci dimensiunea fișierului fizic va crește.
Astfel, fișierul jurnal de tranzacții cu un model simplu de recuperare va crește în funcție de activitatea de lucru cu baza de date până când va putea conține în mod fiabil întreaga parte activă a jurnalului. După care creșterea sa se va opri.
Cu un model complet, porțiunea inactivă a jurnalului nu poate fi trunchiată până când nu se face backup complet. Trunchierea jurnalului este efectuată cu condiția ca jurnalul de tranzacții să fi fost copiat de rezervă și apoi să fi fost creat un punct de control.
Backup-urile jurnalului de tranzacții configurate incorect sub modelul complet pot duce la creșterea necontrolată a fișierului jurnal, care este adesea o problemă pentru administratorii neexperimentați. Sfaturi pentru trunchierea manuală a jurnalului de tranzacții sunt de asemenea comune. Cu un model de recuperare completă, acest lucru nu trebuie făcut în mod categoric, deoarece, astfel, veți încălca integritatea lanțului de copii de jurnal și veți putea restaura baza de date numai în momentul creării copiilor, care va corespunde model simplu.
În acest caz, este timpul să ne amintim despre ce am vorbit la începutul articolului, dacă costurile modelului complet depășesc costurile de restaurare, ar trebui să acordați preferință modelului simplu.
Model simplu de recuperare
Acum, după obținerea cunoștințelor minime necesare, puteți trece la o examinare mai detaliată a modelelor de recuperare. Să începem cu unul simplu. Să presupunem că în momentul accidentului avem o copie completă și două copii diferențiate:
Copierea de rezervă a fost efectuată o dată pe zi, iar ultima copie a fost creată noaptea, între 21 și 22. Prăbușirea are loc în seara zilei de 22 înainte de crearea următoarei copii. În acest caz, va trebui să restabilim secvențial copiile diferențiale complete și ultimele, în timp ce datele pentru ultima zi lucrătoare se vor pierde. Dacă, dintr-un motiv oarecare, copia din data de 21 se dovedește a fi deteriorată, atunci putem restabili copia anterioară, pierzând încă o zi de muncă, în același timp, deteriorarea copiei pentru data de 20 nu va interfera în niciun fel cu recuperarea cu succes a datelor în seara zilei de 21, dacă este disponibilă o copie corespunzătoare.
Model de recuperare completă
Luați în considerare o situație similară, dar folosind modelul de recuperare completă. De asemenea, facem backup-uri zilnic, dupa principiul full + diferential, iar jurnalul de tranzactii este copiat de cateva ori pe zi.
Procesul de recuperare în acest caz va fi mai dificil. În primul rând, va trebui să creați manual o copie de rezervă a ultimei bucăți a jurnalului (indicată cu roșu), de exemplu. parte din jurnal din momentul ultimei copieri până la accident.
Dacă acest lucru nu se face, atunci baza de date poate fi restaurată numai la starea din momentul ultimei copii a jurnalului de tranzacții.
În același timp, deteriorarea fișierului de copiere a jurnalului pentru ziua anterioară nu ne va împiedica să restabilim starea actuală a bazei de date, ci ne va limita la momentul creării ultimei copii, adică. zilele curente.
Apoi restabilim secvențial copia completă și diferențială și lanțul de copii de jurnal create după ultima copie de rezervă, ultima restaurăm o copie a fragmentului de jurnal final, ceea ce ne va oferi posibilitatea de a restaura baza de date chiar în momentul efectuării dezastru sau unul arbitrar care l-a precedat.
Dacă ultima copie diferențială este deteriorată, atunci în cazul unui model simplu, acest lucru va duce la pierderea a încă o zi lucrătoare, modelul complet vă permite să restaurați penultima copie, după care va fi necesară restaurarea întregului lanț de copii ale jurnalului de tranzacții din momentul penultimei copii până la eșec. Adâncimea de recuperare depinde doar de adâncimea lanțului continuu de bușteni.
Pe de altă parte, dacă una dintre copiile jurnalului de tranzacții este deteriorată, să zicem penultima, atunci putem recupera datele doar la momentul ultimei backup + perioada din lanțul nedeteriorat de copii de jurnal. De exemplu, dacă jurnalele au fost făcute la ora 12, 14 și 16 și jurnalul creat la ora 14 este deteriorat, atunci având o copie zilnică putem restabili baza de date până la sfârșitul lanțului continuu, adică. pana la ora 12.
Etichete:
Continuăm să vorbim despre backup și astăzi vom învăța creați o arhivă a bazei de date MS SQL Server 2008... Vom lua în considerare totul ca de obicei, cu exemple folosind atât o interfață grafică, cât și o interogare SQL și, de asemenea, vom configura o interogare automată. crearea unei copii de rezervă folosind un fișier batch.
Nu vom reveni la întrebarea despre importanța copierii de rezervă a bazei de date, deoarece am ridicat deja acest subiect de mai multe ori, de exemplu, în materiale:
Și în ultimul articol am spus că vom lua în considerare posibilitatea creării unei arhive pe MS SQL Server 2008 DBMS, așa că acum vom face exact asta.
Și din moment ce a existat deja multă teorie, să trecem direct la practică, și anume, să creăm o bază de date de rezervă.
Notă! După cum puteți vedea din titlul articolului, vom face arhiva pe SGBD-ul Microsoft SQL 2008 folosind Management Studio. Serverul este localizat local. OS Windows 7.
Cum se creează o arhivă a unei baze de date SQL server
Să decidem că vom face o arhivă a unei baze de testare numită „test”. De la început prin interfața grafică, și pe parcursul procesului, vom scrie un script, astfel încât pe viitor să îl puteți rula pur și simplu și să nu vă mai lăsați distras introducând tot felul de parametri.
Deschide Management Studio, deschide „ Bază de date", Selectați baza necesară, faceți clic dreapta pe ea, selectați Sarcini-> Creați o copie de rezervă
Veți vedea o fereastră „ Backup pentru baze de date»Unde puteți seta parametri, arhivare. Tocmai am dat un nume" Setul de date de rezervă", Și, de asemenea, am schimbat numele arhivei și calea, deoarece implicit va fi creat în folderul Fișiere program, de exemplu, calea mea implicită a fost
C: \ Program Files \ Microsoft SQL Server \ MSSQL10_50.MSSQLSERVER \ MSSQL \ Backup \
De exemplu, l-am schimbat în C: \ temp \ și am numit arhiva test_arh.bak
De asemenea, dacă accesați articolul " Parametrii»Apoi puteți seta setarea pentru a suprascrie toate seturile de date, acum voi explica ce este. Dacă lăsați totul așa cum este, de exemplu. adăugați la un set de date existent, atunci veți avea un fișier cu o copie de rezervă, dar cu mai multe copii ale setului de date, de exemplu. la restaurare, pur și simplu selectați setul de care aveți nevoie. Și dacă pui „ Suprascrieți toate seturile de date de rezervă existente»Atunci setul va fi întotdeauna unul, atunci în acest caz va trebui să creați arhive (să spunem zilnic) cu nume diferite. Am setat să suprascriu, deoarece să zicem, pe viitor, plănuiesc să creez arhive pentru fiecare zi cu data în numele acestor arhive, astfel încât, dacă este necesar, să pot copia rapid backup-ul de care am nevoie pentru o anumită dată la orice loc.
Și apropo, în acest moment, după ce ați introdus toți parametrii, puteți crea un script pentru a-l înregistra și a-l utiliza pe viitor. Pentru a face acest lucru, chiar în partea de sus, faceți clic pe „ Scenariu»
Și în urma acestei acțiuni, se va deschide o fereastră de solicitare, în care va exista codul acestui script. Vom reveni la el puțin mai târziu, dar deocamdată faceți clic pe „OK” și după finalizarea operațiunii va apărea o fereastră în care va fi indicat rezultatul copiei de rezervă, dacă totul este în regulă, va apărea următorul mesaj
Creați o arhivă a bazei de date a serverului SQL printr-o interogare
Dacă ați făcut totul așa cum este indicat mai sus (adică ați făcut clic pe „Script”), atunci ați deschis o fereastră de solicitare, care conține de fapt cererea de creare a unei arhive în sine, dar o vom modifica puțin, deoarece am spus că suntem plănuiesc să-l lanseze în fiecare zi, așa că pentru ca numele să fie adecvat, vom scrie această instrucțiune SQL.
Declara @path ca varchar (200) set @path = N "C: \ temp \ test_arh_" + CONVERT (varchar (10), getdate (), 104) + ".bak" BACKUP DATABASE TO DISK = @path WITH NOFORMAT, INIT, NUME = N "Test baza de date", SKIP, NOREWIND, NOUNLOAD, STATS = 10 GO
Și acum, dacă îl rulăm, atunci vom crea o copie de rezervă a bazei de date numită test_arh_ Data curentă.bak
Crearea automată de backup pe serverul SQL
În aceste scopuri, în MS SQL 2008 există o caracteristică specială numită " Planuri de servicii»Unde puteți seta un program pentru crearea unei copii de rezervă a bazelor de date, dar vă sugerez să folosiți un fișier bat în aceste scopuri pentru a-l configura în planificator și astfel încât să pornească în fiecare zi și să facă o copie de rezervă a bazei de date. Pentru a face acest lucru, copiați instrucțiunea SQL despre care am discutat mai sus și inserați-o în notepad (recomand Notepad ++), apoi salvați-o cu extensia .sql acestea. acest script va fi executat pe MS Sql 2008. Apoi va trebui să scriem un fișier batch pentru ca acesta să se conecteze la serverul SQL și să ne executăm scriptul. De asemenea, scriem într-un bloc de note:
SET cur_date =% data: ~ 6.4 %% data: ~ 3.2 %% data: ~ 0.2% osql -S localhost -i C: \ temp \ test.sql -o C: \ temp \% cur_date % _log_sql.log –E
unde, am creat variabila cur_date pentru a stoca data curentă în ea, apoi mă conectez la serverul local prin utilitar osql care folosește ODBC și execută scriptul nostru (eu l-am numit test.sql) și, de asemenea, scrie un jurnal în care exact aveam nevoie de variabila noastră, atâta tot, îl salvăm cu extensia .băţ, creăm o sarcină în planificator și putem spune că uităm de procesul de arhivare a bazei de date, ei bine, verificăm doar periodic dacă arhiva a fost creată sau nu.
Pentru elementele de bază, acest lucru este suficient, acum știți cum puteți face copii de siguranță ale bazelor de date pe un server SQL 2008, în articolul următor vom vedea cum puteți restaura o bază de date pe MS Sql 2008. Deocamdată, asta este! Noroc!
Și, de asemenea: backup SQL, backup 1C.
Serverul 1C conține date într-o bază de date situată pe un server SQL. Astăzi luăm în considerare MS SQL 2005/2008.
Pentru a preveni pierderea datelor în cazul unui disc de server ars sau în alte situații de forță majoră, este necesar să faceți copii de siguranță încă de la început.
Desigur, nimeni nu vrea să facă Backup SQL al bazei de date 1C cu stilouri în fiecare zi. Există instrumente automate pentru aceasta. Să-i cunoaștem.
Configurarea SQL de rezervă
Configurarea Backup SQL pentru o bază de date 1C nu este diferită de configurarea unei copii de rezervă pentru orice altă bază de date.
Lansați MS SQL Management Studio pentru a configura. Acest program se află în grupul de programe MS SQL.
Adăugarea unei sarcini de rezervă pentru baza de date SQL 1C
Sarcinile de backup automate pentru bazele de date SQL sunt situate în ramura Planuri de management / întreținere.
Pentru a adăuga o nouă sarcină de rezervă, faceți clic dreapta pe grupul Planuri de întreținere și selectați Plan de întreținere nou.
Introduceți un nume pentru sarcină. Numele contează doar pentru tine. Este mai bine să folosiți caractere englezești pentru orice eventualitate.
Configurarea unei sarcini de rezervă pentru baza de date SQL 1C
Se va deschide editorul de misiuni. Vă rugăm să rețineți că joburile pot efectua diverse operațiuni cu baza de date, nu doar copii de rezervă.
Lista de opțiuni pentru operații este afișată în stânga jos. Faceți dublu clic pe Sarcina de copiere a bazei de date sau pur și simplu trageți la dreapta.
Atenție la săgeată. Puteți trage mai multe operațiuni diferite sau identice și le puteți lega cu săgeți. Apoi mai multe sarcini vor fi efectuate simultan în secvența pe care ați definit-o.
În fereastra de setări, selectați bazele de date SQL 1C necesare (puteți mai multe sau una odată).
Selectați locația pentru a salva backupul bazei de date SQL 1C. Trebuie să selectați un hard disk diferit din punct de vedere fizic. Din punct de vedere organizațional, puteți bifa caseta de selectare „Creați subdosare”.
Acum să setăm programul de rezervă. Programul de rezervă a fost adăugat în mod implicit de la sine. Dar puteți adăuga mai multe programe (de exemplu, unul este zilnic, unul săptămânal etc.). Faceți clic pe butonul pentru a configura programul de rezervă.
Captura de ecran arată un exemplu de backup zilnic SQL al bazei de date 1C la 3 nopți.
Pentru ca programul de rezervă din listă să fie ușor de înțeles, îl puteți modifica.
Salvarea unei sarcini de rezervă pentru baza de date SQL 1C
Faceți clic pe ardere. Sarcina va apărea în partea stângă a listei.
Este important! Verificați dacă jobul de bază de date Backup SQL a fost creat corect. Pentru a face acest lucru, faceți clic dreapta pe lucrare și selectați Executare.
Ca rezultat, un fișier de rezervă ar trebui să apară la calea specificată. Dacă ceva nu este în regulă, ștergeți sarcina (Del) și începeți de la capăt.
Acest articol vă va arăta cum să faceți manual o copie de rezervă completă a bazei de date folosind Microsoft SQL Server Management Studio.
1. Crearea unei copii de rezervă
De fapt, este destul de simplu. Lansăm snap-in-ul „ » (« start» — « Toate programele» — « SQL Server 2008 R2» — « Microsoft SQL Server Management Studio») Și introduceți datele pentru autorizare.
După aceea, în Object Explorer, deschideți fila „ Bază de date”Și faceți clic dreapta pe baza de date pentru care doriți să faceți o copie de rezervă. În meniul contextual care apare, selectați „ Sarcini» ( Sarcini) — « Creați o copie de rezervă» ( Backup...) .
Fereastra " Backup pentru baze de date» ( Faceți o copie de rezervă a bazei de date). Să ne asigurăm că merită" Deplin» ( Deplin), dacă este necesar, setați un nume și o descriere și, de asemenea, indicați scopul copiei de rezervă. În mod implicit, este selectată calea de pe hard diskul computerului către folderul Backup din locația principală a bazelor de date server SQL. Pentru a schimba locația copiei, apăsați mai întâi pe „ Șterge» ( Elimina) pentru a elimina atribuirea existentă, apoi „ Adăuga» ( Adăuga…) Pentru a adăuga unul nou.
Aici setăm locația și numele fișierului de rezervă și facem clic pe „ O.K". Puteți specifica mai multe astfel de destinații. În acest caz, backup-ul va fi împărțit în părți egale, fiecare parte din fișierul specificat.
Când toate setările sunt setate, faceți clic pe „ O.K„Și așteptați finalizarea sarcinii. Dacă totul este făcut corect, vom găsi fișierul de backup al bazei de date SQL în directorul specificat.
2. Restaurarea unei baze de date dintr-o copie de rezervă
Recuperarea are loc într-un mod similar. V" Microsoft SQL Server Management Studio»Alegeți o bază din care s-a făcut backup-ul, faceți clic pe el cu butonul drept al mouse-ului, în meniul contextual, selectați „ Sarcini» ( Sarcini) — « Restabili» ( Restabili) — « Bază de date…» ( Bază de date ...).
Fereastra " Recuperarea bazei de date» ( Restaurați baza de date). Aici, ca sursă, indicăm „ De la dispozitiv» ( De la dispozitiv) și selectați fișierul de rezervă (creat la pasul 1).
Să punem steagul „ Restabili» ( Restabili) vizavi de backup-ul selectat. Dacă este necesar, pe fila „ Parametrii» ( Opțiuni), puteți specifica opțiuni suplimentare de recuperare, al căror sens poate fi citit.
După ce au fost făcute toate setările, faceți clic pe „ O.K„Și așteptați mesajul despre recuperarea cu succes a bazei de date.
3. Restaurarea unei copii de rezervă într-o altă bază de date (copierea datelor)
Dacă trebuie să încărcați date în baza de date, diferit de cel din care s-a făcut backup-ul, apoi la încărcare, pe lângă acțiunile descrise la paragraful 2, este necesar pe fila " Parametrii„(Opțiuni) setați numele fișierelor acestei baze de date și setați steag-ul” Suprascrieți baza de date existentă„(CU ÎNLOCUIRE).
Te-a ajutat acest articol?
Să luăm în considerare o situație nedorită. Și anume: din anumite motive, baza de date este nefuncțională. Ce avem? O copie integrală, o copie diferențială de ieri, dar astăzi sunt și date, chiar a fost necesar să se facă o copie diferențială la fiecare oră? - Nu! Există Jurnal de tranzacții.
Jurnal de tranzacții - Un jurnal care înregistrează toate tranzacțiile și toate modificările bazei de date efectuate de fiecare tranzacție. Acestea. orice acțiune cu baza de date este înregistrată pas cu pas. Fiecare înregistrare este marcată de SGBD pentru finalizarea tranzacției, finalizată sau nu. Cu ajutorul acestuia, puteți restabili starea bazei de date nu numai după o eroare, ci și în cazul unor acțiuni neprevăzute cu date. Rotiți înapoi până la o anumită oră. Ca și în cazul bazei de date, jurnalul de tranzacții trebuie să fie copiat de rezervă, complet, diferențial, incremental. Pentru a restabili o parte din jurnalul de tranzacții după o eroare în intervalul dintre copii de rezervă, trebuie să faceți o copie de rezervă a fragmentului final al jurnalului, care, de fapt, este punctul de finalizare a copiei de rezervă. Executat după un eșec, ca punct de numărătoare inversă.
Deci, pentru a restabili baza de date după o eroare, avem nevoie de o copie reală completă a bazei de date, o copie diferențială a bazei de date și o copie a jurnalului de tranzacții.
Există 3 modele de recuperare pentru baza de date în sine - simplu, complet și în bloc. Considera:
- Model simplu - se folosește doar redundanța completă. Fără diferență. copii de siguranță, precum și copii de siguranță ale jurnalului de tranzacții. Copiile complete trebuie create cât mai des posibil. Relevant pentru bazele de date numai în citire.
- Modelul de recuperare completă este cel mai utilizat model în care sunt disponibile toate funcțiile de backup și recuperare a datelor. Suporta recuperarea paginilor de date individuale. Are loc înregistrarea completă a tranzacțiilor și jurnalul tranzacțiilor este salvat.
- Model înregistrat în bloc - Proiectat pentru a completa modelul complet de recuperare completă. Majoritatea operațiunilor în bloc nu acceptă înregistrarea în jurnal, prin urmare, nu acceptă recuperarea bazei de date la un anumit moment în timp.
Să luăm în considerare cel mai relevant lanț de backup: Backup complet - o dată pe săptămână, Backup diferențial - o dată pe zi, Backup jurnal de tranzacții - o dată pe oră.
Există mai multe opțiuni pentru a crea copii de rezervă:
- Folosind programul MS SQL Task Scheduler încorporat
- Folosind Transact-SQL
- Folosind sqlcmd și OS Task Scheduler
- Manual (ceea ce nu ne convine, pentru că adevăratul admin trebuie să se încurce constant)
Să considerăm prima opțiune ca fiind cea mai utilizabilă. Pentru aceasta se folosesc Windows Server 2008 R2 Enterprise și MS SQL Server 2008 Eng.
Deci, să presupunem că avem o bază de date TECH:
Trecerea la instrumentul de creare Joba:
Trei buton dreapta al mouse-ului și apelați Master la Job:
Bifam caseta de selectare „Execuție separată a fiecărei sarcini”, la urma urmei, efectuăm o singură acțiune
Un maestru fără turban, dar principalul lucru nu este dimensiunea turbanului)) Selectați tipul de dorință, în cazul nostru - rezervare completă:
Maestrul Iov, după cum sa dovedit, este puțin evreu, așa că el întreabă din nou:
„Merită să alegeți parametri suplimentari, despre tânărul paddawan!”:
aici selectăm baza de date, perioada de stocare a backup-ului, adresa (bandă sau disc), calea de salvare și, cel mai important, planificatorul de activități!
„Nu uita de baza de date atunci când o alegi pe a ta. Concentrează-ți puterea și alege o bază de date”:
„Prea repede vă grăbiți să creați o sarcină, apăsați butonul de mai jos cu numele Schedule - Define.”
Sobsno, programatorul de sarcini, unde selectăm tipul (repetiție, o dată etc.), ziua, ora, tipul de începere:
Asta e tot, creat. Job Master este cool și verde. Ne uităm la starea în Planurile de întreținere:
Pentru paranoici, nu vă fie teamă să recunoașteți acest lucru în oglindă, merită să vă uitați în sufletul SQL Server Agent - Job Activity Monitor, Job Wizard va arăta totul în detaliu:
Acum, când sunt îndeplinite condițiile specificate, ar trebui creată o copie de rezervă completă a bazei de date. După același principiu, sunt create copii de siguranță ale jurnalului de tranzacții și diferențiale (aceste sub-articole sunt situate sub „Copia de rezervă completă” în lista de selecție a sarcinilor).
Răsuciți urechile MSSQL după cum doriți, nu deșurubați
Următorul articol este crearea cu Transact-SQL și câteva exemple.
