în capitolul de deschidere al cărții lui Craig Mullin, Administrarea Bazelor de date, el spune „în multe feluri, de afaceri de astăzi este de date”. În cadrul majorității organizațiilor, persoana responsabilă pentru protejarea datelor este administratorul bazei de date … dvs.

asta-i drept; întreaga afacere este în mâinile tale capabile, rulează pe acel server care nu se prăbușește niciodată, cu toți acei utilizatori finali care nu greșesc niciodată folosind aplicații, construite de acei dezvoltatori care scriu cod fără cusur prima dată, de fiecare dată, cu asistența capabilă a acelei noi cooperative care are privilegii sa datorită șefului tău.

bine. Nu mai plânge. Există lucruri pe care le puteți face pentru a proteja datele SQL Server sub îngrijirea dumneavoastră și una dintre cele mai importante se execută backup-uri regulate de baze de date.

backup-uri

Microsoft, în SQL Server Books Online, definește backup-uri ca:

o copie de date care este utilizat pentru a restaura și recupera datele după o eroare de sistem

backup SQL pot fi create un număr de moduri și poate încorpora toate sau o parte din date, precum și o parte din jurnalul de tranzacții. În timp ce acest articol se concentrează pe sintaxa din 2005, majoritatea conceptelor sunt aplicabile anului 2000. Acesta este un subiect imens. În cel mai bun caz, voi zgâria suprafața și vă voi oferi suficiente informații, astfel încât să nu începeți să plângeți din nou. După ce ați citit acest lucru, ar trebui să puteți configura un set rezonabil de copii de rezervă pentru sistemul dvs.

modele de recuperare

pentru a începe lucrul la copii de rezervă, nevoile de afaceri definesc un model de recuperare a bazei de date. În esență, un model de recuperare definește ce veți face cu datele jurnalului de tranzacții.

există trei modele de recuperare: complet, simplu și în vrac logat. Acestea sunt destul de ușor de definit:

• simplu – în modul de recuperare simplă, Jurnalul de tranzacții nu este susținut, astfel încât să puteți recupera doar la cea mai recentă copie de rezervă completă sau diferențială.
• Full – în modul de recuperare completă vă rezervă baza de date și Jurnalul de tranzacții, astfel încât să puteți recupera baza de date la orice moment în timp.
• modul logat în bloc în bloc, majoritatea tranzacțiilor sunt stocate în Jurnalul de tranzacții, dar unele operațiuni în bloc, cum ar fi încărcările în bloc sau crearea indexului, nu sunt înregistrate.

cele două moduri cele mai frecvent utilizate sunt simple și complete. Nu presupuneți neapărat că, desigur, trebuie să utilizați întotdeauna recuperarea completă pentru a vă proteja datele. Este o decizie de afaceri. Afacerea vă va spune dacă trebuie să vă recuperați la un moment dat sau dacă pur și simplu aveți nevoie de ultima copie de rezervă completă. Va defini dacă datele dvs. sunt recuperabile prin alte mijloace, cum ar fi introducerea manuală sau dacă trebuie să vă protejați cât mai mult posibil pe măsură ce vine peste fir. Utilizați recuperare simplă dacă vă puteți permite să pierdeți datele stocate de la ultima copie de rezervă completă sau diferențială și/sau pur și simplu nu aveți nevoie de recuperare până la un moment dat. În modul simplu, trebuie să restaurați toate grupurile de fișiere secundare de citire / scriere atunci când restaurați principalul. Utilizați simplu mai ales pe baze de date secundare, care nu sunt o parte vitală absolută a întreprinderii sau a sistemelor de raportare, cu acces numai în citire, astfel încât nu există un jurnal de tranzacții să vă faceți griji oricum. Utilizați complet dacă fiecare bit de date este vital, trebuie să vă recuperați la un moment dat sau, de obicei, în cazul bazelor de date foarte mari (VLDB), trebuie să restaurați fișiere individuale și grupuri de fișiere independent de alte fișiere și grupuri de fișiere.

cu ambele modele simple și complete de recuperare, puteți rula acum o copie de rezervă numai pentru copiere, care vă permite să copiați baza de date într-un fișier de rezervă, dar nu afectează Jurnalul, programele de rezervă diferențiale sau recuperarea impactului până la un moment dat. Voi încerca să detaliez cât mai multe dintre aceste subiecte posibil prin articol, dar nu fișierele și grupurile de fișiere.

lucrul cu recuperare simplă

discuție suficientă. Să trecem la rularea copiilor de rezervă. Să presupunem că suntem în recuperare simplă pe o bază de date mică până la medie. Voi folosi AdventureWorks pentru toate scripturile de probă. Pentru a-l seta la recuperare simplă:

strategia de backup simplu este de a rula, la intervale regulate, următoarea comandă SQL Server backup, care va efectua o copie de rezervă completă a bazei de date:

ce e cu toate tastarea vă întreb? Nu avem instrumente GUI să se ocupe de munca pentru noi? Da, cele mai multe backup-uri simple pot fi efectuate folosind SQL Server Management Studio. Cu toate acestea, dacă doriți să învățați și să înțelegeți ce face Management Studio pentru dvs. sau dacă doriți un control fin asupra a ceea ce este susținut, cum și unde, atunci va trebui să scoateți tastatura și să lăsați mouse-ul.

comanda de mai sus va precipita o copie de rezervă de bază pe disc. Cele mai multe DBA știu de rezervă la dosar și apoi razuiti fișierele pe o bandă sau un alt suport. Acest lucru se datorează faptului că fișierele de pe disc sunt simple și rapid de recuperat, în timp ce mass-media poate fi uneori un pic de durere. De exemplu, avem, în general, două-trei zile în valoare de backup pe sistemele noastre de fișiere pentru recuperare imediată. Mergem doar la sistemele de bandă dacă trebuie să rulăm restaurări pentru copii de rezervă mai vechi.

ce a făcut această poruncă? A făcut o copie a tuturor datelor angajate în baza de date. De asemenea, a copiat intrările de jurnal neangajate. Acestea sunt utilizate în timpul recuperării fie pentru a comite, fie pentru a reveni la modificările care au avut loc la date în timpul procesului de backup.

copy-only backup

în mod normal, copierea de rezervă a unei baze de date afectează alte procese de backup și restaurare. De exemplu, după rularea comenzii anterioare, orice copie de rezervă diferențială (o copie de rezervă care copiază doar datele modificate de la ultima copie de rezervă) ar folosi acest lucru ca punct de plecare pentru modificările datelor, nu copia de rezervă pe care ați rulat-o aseară. După cum sa menționat mai devreme, SQL 2005 introduce un nou concept pentru backup-uri, copy_only backup-uri, care ne permit să păstreze de la întreruperea ciclului:

deja am găsit unul dintre acele momente mai granulare în care studioul de Management nu te-ar ajuta. Dacă doriți o copie de rezervă numai, trebuie să utilizați linia de comandă.

backup-uri diferențiale

să presupunem pentru un moment, că suntem încă în recuperare simplu, dar avem de-a face cu o bază de date mai mare, spune ceva peste 100 GB în dimensiune. Copiile de rezervă complete pot începe să încetinească puțin procesul. În schimb, după consultarea cu afacerea, am decis să facem o copie de rezervă completă săptămânală și copii de rezervă diferențiale zilnice. Copii de rezervă diferențiale rezervă numai paginile de date care s-au schimbat de la ultima copie de rezervă completă. În urma este comanda SQL backup pentru a efectua o copie de rezervă diferențială:

acum, dacă ar trebui să restaurăm această bază de date, am merge mai întâi la ultima copie de rezervă completă, am restabili-o și apoi am restabili backup-urile diferențiale în ordine (mai multe despre asta mai târziu).

există o serie de alte opțiuni de rezervă pe care nu le voi detalia aici. Citiți cărțile online pentru a vedea detalii despre BLOCKSIZE, EXPIREDATE, RETAINDAYS, parolă, nume, statistici și așa mai departe.

de asemenea, puteți rula o declarație care va verifica integritatea unei copii de rezervă a bazei de date. Nu verifică integritatea datelor dintr-o copie de rezervă, dar verifică dacă copia de rezervă este formatată corect și accesibilă.

recuperare completă și log backup

am fost în primul rând de lucru pe o bază de date care a fost în modul de recuperare simplu (acest folosit pentru a fi numit trunchia Log on Checkpoint). În acest mod, nu facem backup jurnalele de tranzacții pentru recuperare ulterioară. Fiecare copie de rezervă în cadrul acestui mecanism este o copie de rezervă a bazei de date. Copiile de rezervă ale jurnalului nu sunt pur și simplu posibile.

cu toate acestea, ați protejat datele doar de la ultima copie de rezervă bună, fie completă, fie diferențială. Să ne schimbăm presupunerile. Acum avem de-a face cu o aplicație și o bază de date mari, critice pentru misiune. Vrem să putem recupera această bază de date până la ultimul minut. Acesta este un punct foarte important. În teorie, din moment ce intrările jurnal sunt stocate și susținute, suntem protejați până la punctul de orice eșec. Cu toate acestea, unele eșecuri pot provoca corupția jurnalului, ceea ce face imposibilă recuperarea la un moment dat. Deci, trebuie să determinăm care va fi timpul minim rezonabil între copiile de rezervă ale Jurnalului. În acest caz, putem trăi cu nu mai mult de 15 minute în valoare de date pierdute.

deci, să începem prin a pune baza noastră de date în modul de recuperare completă:

apoi, în mod programat, în acest caz la fiecare 15 minute, vom rula comanda SQL backup pentru jurnalul de tranzacții:

acest script va face backup tranzacțiilor comise din jurnalul de tranzacții. Are markeri în fișier care arată timpul de pornire și oprire. Acesta va trunchia Jurnalul când se finalizează cu succes, curățând din jurnalul de tranzacții tranzacțiile comise care au fost scrise în fișierul de rezervă. Dacă este necesar, puteți utiliza instrucțiunea cu NO_TRUNCATE pentru a captura date din jurnalul de tranzacții, indiferent de starea bazei de date, presupunând că este online și nu într-o stare de urgență. Acest lucru este doar pentru Situații de urgență.

rețineți că nu folosim instrucțiunea INIT în acest caz, dar puteți face acest lucru dacă alegeți. Când faceți backup-uri de jurnal, aveți opțiuni:

1. rulați toate copiile de rezervă într-un singur fișier, unde vor stiva și tot ce trebuie să faceți, pe Restaurare (acoperit mai târziu), este ciclul prin ele.
2. denumiți copiile de rezervă în mod unic, probabil folosind data și ora în șir.

în acest ultim caz, siguranța spune, utilizați INIT pentru că exercitați un control maxim asupra a ceea ce se face backup unde și veți putea ști exact ce este o copie de rezervă, când a fost luată și de unde pe baza numelui. Acesta este încă un alt loc în care backup-urile de operare din linia de comandă vă oferă mai mult control decât GUI. Am folosit ambele abordări în sistemele noastre din diferite motive. Puteți decide ce este cel mai bine pentru cerințele dvs. tehnologice și de afaceri.

majoritatea opțiunilor disponibile pentru backup-ul bazei de date sunt incluse în backup-ul jurnalului, inclusiv COPY_ONLY. Acest lucru vă va permite să capturați un set de date despre tranzacții fără a afecta jurnalul sau următoarea copie de rezervă programată a jurnalului. Acest lucru ar fi util pentru a lua datele de producție la un alt sistem de depanare etc.

dacă aveți baza de date setată la recuperare completă, trebuie să rulați copiile de rezervă ale Jurnalului. Uneori, oamenii uită și Jurnalul de tranzacții crește până la punctul în care umple unitatea de disc. În acest caz, puteți rula:

atașarea NO_LOG la backupul jurnalului și nu specificarea unei locații pentru jurnal, determină eliminarea părții inactive a jurnalului și face acest lucru fără o intrare în jurnal în sine, învingând astfel unitatea de disc completă. Acest lucru nu este absolut recomandat, deoarece rupe lanțul de jurnal, seria de backup-uri de jurnal de la care v-ar recupera baza de date la un moment dat. Microsoft recomandă rularea unei copii de rezervă complete imediat după utilizarea acestei instrucțiuni. Mai mult, ei avertizează că această declarație ar putea fi depreciată într-o versiune viitoare.

restaurarea bazelor de date

oricât de importante sunt copiile de rezervă SQL Server și sunt vitale, sunt inutile fără capacitatea de a restabili baza de date.

restaurarea unei copii de rezervă a bazei de date complete

restaurarea unei copii de rezervă a bazei de date complete este la fel de simplă ca și crearea:

este într – adevăr atât de simplu-cu excepția cazului în care, în timp ce noi, facem backup pentru totul într-un fișier ca și cum ar fi un dispozitiv de rezervă. În acest caz, va trebui să specificați fișierul din „dispozitivul” pe care îl accesați. Dacă nu știți ce fișier, va trebui să generați o listă:

acest lucru vă va oferi aceeași listă așa cum am arătat mai sus de la Management Studio. Deci, acum, dacă am vrut să restaurăm al doilea fișier din grup, copy_only backup, ați emite următoarea comandă:

din păcate, dacă urmăriți, este posibil să descoperiți că tocmai ați generat această eroare:

ceea ce înseamnă acest lucru este că baza dvs. de date este în modul de recuperare completă, dar nu ați făcut backup pentru „coada jurnalului”, adică tranzacțiile introduse de la ultima dată când ați rulat o copie de rezervă. Puteți suprascrie această cerință dacă modificați sintaxa anterioară la:

aceasta este prima dată când am stivuit clauzele cu (cu FILE=2 și cu REPLACE este reprezentat ca cu FILE=2, REPLACE), dar nu va fi ultima. Citiți cărțile online. Majoritatea enunțurilor cu clauze pot fi utilizate în combinație cu celelalte.

ce se întâmplă dacă vrem să restaurăm la o bază de date diferită de cea originală? De exemplu, dorim să facem o copie a bazei noastre de date dintr-o copie de rezervă separată. Poate vrem să-l mutăm pe un server de asistență pentru producție, unde vom lucra la el, separat de copia de producție a bazei de date. Dacă luăm abordarea simplă, ei bine, încercați acest lucru:

în acest caz, ar trebui să vedeți o serie întreagă de erori legate de faptul că fișierele nu sunt suprascrise. Puteți crea cu adevărat baze de date noi din copii de rezervă, dar dacă o faceți pe un server cu baza de date existentă, va trebui să schimbați locația fișierelor fizice folosind numele logice. Pentru a cunoaște numele logice ale fișierelor pentru o anumită bază de date, executați acest lucru înainte de a încerca să mutați fișierele:

acest lucru poate fi apoi utilizat pentru a identifica numele logice adecvate pentru a genera acest script:

restaurarea unei copii de rezervă diferențială

ultima metodă este de a aplica copia de rezervă diferențială. Acest lucru necesită doi pași. În primul rând, vom restaura baza de date, dar cu o răsucire și apoi vom aplica copia de rezervă diferențială:

cele mai multe dintre acestea sunt probabil auto-explicative pe baza a ceea ce am acoperit deja. Un rid este includerea cuvântului cheie NORECOVERY. Foarte simplu, în timpul unei restaurări, este posibil ca tranzacțiile să fi început în timpul procesului de backup. Unele dintre ele sunt complete, iar altele nu. la sfârșitul unei restaurări, tranzacțiile finalizate sunt derulate înainte în baza de date și tranzacțiile incomplete sunt derulate înapoi. Setarea NORECOVERY menține tranzacțiile deschise. Acest lucru permite ca următorul set de tranzacții să fie preluat din următoarea copie de rezervă în ordine.

avem de-a face în principal cu copii de rezervă și restaurări simple în acest articol, dar o restaurare mai avansată în 2005 permite restaurarea grupurilor de fișiere secundare în timp ce baza de date este online. Grupul său principal de fișiere trebuie să fie online în timpul operației. Acest lucru va fi mai util pentru sistemele de baze de date foarte mari.

restaurarea bazelor de date SQL Server la un moment dat

restaurarea jurnalelor nu este mult mai dificilă decât restaurarea bazei de date diferențiale pe care tocmai am finalizat-o. E doar destul de un pic mai implicat în restabilirea la un moment în timp. Presupunând că faceți backup pentru jurnalele dvs. într-un singur fișier sau dispozitiv:

în caz contrar, pur și simplu mergeți și obțineți numele fișierelor de care aveți nevoie. Mai întâi rulați restaurarea bazei de date, având grijă să o lăsați într-o stare nerecuperată. Urmați acest lucru cu o serie de log restabilește la un moment dat în timp.

acum, ceea ce avem este o bază de date care este de până la exact, ultima tranzacție angajat la 14:30:29 pe 23 octombrie. Amintiți-vă, în timpul restaurărilor în mai mulți pași, cum ar fi aceasta, trebuie să lăsați baza de date într-o stare de recuperare. Asta înseamnă adăugarea NORECOVERY la fiecare declarație până când ați finalizat procesul de restaurare. Dacă din anumite motive ați adăugat NORECOVERY la toate declarațiile dvs. sau pur și simplu vă opriți la mijloc și doriți să readuceți baza de date online, puteți utiliza această declarație pentru a finaliza procesul:

baza de date instantanee

SQL Server 2005 a introdus conceptul de instantaneu, sau o vizualizare statică numai în citire a unei baze de date. Instantaneele sunt create în principal pentru a furniza o versiune numai în citire a unei baze de date în scopuri de raportare. Cu toate acestea, ele funcționează într-un mod similar cu copiile de rezervă. Singura diferență principală este că toate tranzacțiile neangajate sunt derulate înapoi. Nu există nicio opțiune pentru rularea înainte, capturarea jurnalelor etc., că backup-urile oferă și nici nu sunt utilizate foarte multe resurse SQL Server. Mai degrabă, Tehnologia discului este utilizată pentru a crea o copie a datelor. Din acest motiv, acestea sunt mult mai rapide decât copiile de rezervă atât pentru a crea, cât și pentru a restabili.

notă:
pentru mai multe detalii despre Sql 2005 instantaneu, vă rugăm să consultați http://www.simple-talk.com/sql/database-administration/sql-server-2005-snapshots/.

o bună utilizare a instantaneelor, pe lângă raportare, ar putea fi crearea unuia înainte de întreținere după ce ați eliminat deja toți utilizatorii activi (și tranzacțiile lor) din sistem. În timp ce instantaneele nu acceptă volatilitatea copiilor de rezervă live, viteza și ușurința lor de recuperare fac un instrument excelent pentru recuperarea rapidă dintr-o lansare greșită. Instantaneele sunt stocate pe server, deci trebuie să vă asigurați că aveți spațiu de stocare adecvat.

sintaxa este diferită deoarece nu faceți backup pentru o bază de date; creați una nouă:

acum va fi accesibil pentru acces numai în citire. Deoarece suntem preocupați în primul rând de utilizarea acestui mecanism ca mecanism de rezervă, să includem metoda de revenire a unei baze de date la un instantaneu al bazei de date.

mai întâi, identificați instantaneul pe care doriți să îl utilizați. Dacă există mai multe în orice bază de date pe care o veți reveni, va trebui să ștergeți toate, cu excepția celei pe care o utilizați:

apoi puteți reveni la baza de date executând o declarație de restaurare( metafore mixte, nu este bună):

asta e. Pe sistemul meu, rularea instantaneelor bazei de date ale Adventureworks a durat 136 ms. copia de rezervă completă a durat 5.670 ms. restaurarea instantaneului a durat 905ms, iar restaurarea bazei de date a durat 13.382 ms. Încorporarea acestui lucru într-un proces de lansare a producției ar putea duce la beneficii semnificative

din nou, merită remarcat faptul că există unele avertismente pentru utilizarea instantaneului. Trebuie să aveți suficient spațiu pe disc pentru oa doua copie a bazei de date. Trebuie să aveți grijă să vă ocupați de instantanee, deoarece cea mai mare parte a sintaxei este similară cu cea utilizată de bazele de date. Ultimul, în timp ce există instantanee atașate la o bază de date, nu puteți rula o restaurare dintr-o copie de rezervă a bazei de date a acelei baze de date.

cele mai bune practici

modul în care efectuați copii de rezervă ale bazei de date nu ar trebui să fie o decizie tehnică. Ar trebui să fie dictată de afaceri. Sistemele mici cu rate scăzute de tranzacție și / sau sisteme de raportare care sunt încărcate în mod regulat vor avea nevoie doar de o copie de rezervă completă a bazei de date. Sistemele de dimensiuni medii și sistemele mari devin dependente de tipul de date gestionate pentru a determina ce tipuri de backup sunt necesare.

pentru un sistem de dimensiuni medii, o copie de rezervă zilnică cu backup-uri de jurnal în timpul zilei ar răspunde probabil majorității cerințelor de date în timp util.

pentru o bază de date mare, cea mai bună abordare este de a amesteca și potrivi copiile de rezervă pentru a asigura recuperarea maximă în timp minim. De exemplu, executați o copie de rezervă completă săptămânală. De două ori pe zi în timpul săptămânii, executați o copie de rezervă diferențială. La fiecare 10 minute în timpul zilei, executați o copie de rezervă a jurnalului. Acest lucru vă oferă un număr mare de mecanisme de recuperare.

pentru baze de date foarte mari, va trebui să intrați în rularea fișierelor de rezervă și a fișierelor, deoarece este posibil să nu fie posibilă o copie de rezervă completă sau chiar o copie de rezervă diferențială a bazei de date complete. O serie de funcții suplimentare sunt disponibile pentru a ajuta în acest domeniu, dar nu voi intra în ele aici.

ar trebui să ia timp pentru a dezvolta unele script-uri pentru rularea backup-uri și restaurări. O convenție de denumire, astfel încât să știți ce bază de date, de la ce server, de la ce dată, în ce copie de rezervă și format specific vor fi foarte favorabile sănătății voastre. Ar trebui definită o locație comună pentru copii de rezervă, jurnal, complet sau incremental. Toți cei responsabili ar trebui să fie instruiți atât în backup, cât și în recuperare și în rezolvarea problemelor la fel. Există multe modalități de a face acest lucru, dar puteți găsi câteva sugestii în pop back-up și pop restaurează.

testul real este de a rula mecanismele de backup și apoi executați o restaurare. Apoi încercați un alt tip de restaurare, altul și altul. Asigurați-vă că, nu numai că ați făcut due diligence în definirea modului de backup al sistemului, dar că ați făcut pasul suplimentar de a vă asigura că puteți recupera aceste copii de rezervă. Dacă nu ați practicat acest lucru și nu ați documentat practica și apoi ați testat documentul, de fapt, nu sunteți pregătiți pentru un dezastru.

rezumat

backup-uri în cadrul întreprinderii dumneavoastră ar trebui să fie ca vot în Chicago, devreme și de multe ori. Configurarea copiilor de rezervă de bază este destul de simplă. Adăugarea pe backup-uri jurnal și diferențialele este ușor, de asemenea. Explorați opțiunile pentru a vedea cum să adăugați în fișiere și fișiere backup de grup și restabilește pentru a crește viteza de backup și restabilește ambele din care va crește disponibilitatea sistemului și până timp. Păstrați un standard comun de denumire. Aveți grijă când utilizați instantanee, dar cu siguranță le folosiți. Stocați fișierele într-o locație standard între servere. Exersează-ți recuperările. În cele din urmă, pentru a face cu adevărat copiile de rezervă să cânte, descărcați o încercare gratuită a backupului SQL Red Gate De La Red Gate. Oferă compresie de înaltă performanță și rezistență la rețea pentru a face procesul de scriere sau copiere a copiilor de rezervă în rețelele fulgi tolerante la erori.