partea 1

Setarea ms de backup sql. aceasta este una dintre primele lucruri pe care vine în minte atunci când reflecta asupra consecințelor pierderii bazelor de date de producție. De multe ori, mulți administratori este de a rezolva această problemă începe prima întâlnire cu SQL Server Management Studio (SSMS), și limbajul Transact SQL (T-SQL). Această publicație, am decis să înceapă o serie de articole dedicate greșelile tipice și erori. Nu vom descrie modul în care să efectuați pașii de configurare de rezervă, și să se concentreze pe punctele importante, care sunt de obicei neglijate, astfel încât anulează toate setările de backup ms sql.

Afirmatie: Am nevoie doar de configurat backup-uri ...

Deci, de obicei, cred că cei mai întâi care se confruntă cu această întrebare. Cu toate acestea, toate nu este la fel de ușor cum pare la prima vedere. Aici este o listă minimă de probleme care vor trebui să înțeleagă:

Care este strategia de rezervă?
Care este modelul de recuperare a bazei de date, și care model pentru a alege?
În cazul în care mai bine pentru a pune backup de fișiere și cum să le verifice?
De-a lungul ce perioadă de timp, stoca backup-urile?
Cum să instituie un control periodic integritatea bazei de date SQL Server?
Cum de a crea e-mail de notificare de erori?

Aproape fiecare problemă are propria listă de erori și erori de model.

Eroare: Selectați strategia greșită pentru backup și recuperare

strategia de backup și recuperare este determinată de modelul bazei de date de recuperare, frecvența de rezervă (full, diferențial și jurnal de tranzacții) și adâncimea de stocare backup. Strategia de fapt determină ce maximul pentru perioada de timp, veți pierde date în caz de eșec, și durata de recuperare va fi efectuată. Cu alte cuvinte, strategia de planificare ar trebui să fie ghidate de importanță informații și gravitatea consecințelor, atunci când se pierde în caz de eșec, precum și o viteză acceptabilă failover. Foarte des, pentru a nu deranja, a selectat cea mai simplă strategie, în timp ce pierderea de date, chiar și pentru o perioadă scurtă de timp este plină cu consecințe grave pentru afaceri.

Trebuie remarcat faptul că SQL Server vă permite să recuperați baza de date, nu numai în momentul în care a fost creat copie de siguranță deplină (de rezervă), dar, de asemenea, în orice alt punct în timp. Pentru a face acest lucru în SQL Server jurnal de tranzacții este mecanismul. Mecanismul este simplu - toate solicitările de date de schimbare, care sunt primite de SQL Server, sunt înregistrate în jurnalul de tranzacții. În același timp, revista trebuie periodic de rezervă. Acest lucru se face rapid și fără probleme pentru utilizatori. În cazul unei defecțiuni recuperarea întregului lanț la rândul său: în primul rând, copie de siguranță completă a bazei de date, și apoi log backup. Ca urmare, baza de date va fi restabilită în momentul de rezervă a ultimei tranzacții.

de recuperare de date model este una dintre cele mai importante proprietăți care determină dacă jurnalul de tranzacții se menține. Deci, în modelul de recuperare completă, jurnalul de tranzacții se menține, și este trunchiată automat cu un model simplu.

Eroare: modelul complet de recuperare fără o copie de rezervă jurnal de tranzacții

Pentru a minimiza erorile la crearea unei politici de serviciu a șablonului QMB va seta automat modelul corect de baze de date.

Afirmatie: Modelul de recuperare completă este mai puțin productiv decât un simplu

Unele diferențe notabile între performanță completă și simplu model de recuperare nr. Trebuie spus că datele scrise în jurnalul de tranzacții pentru orice model de recuperare. Cu toate acestea, în cazul în care modelul simplu de recuperare, fișierul jurnal este trunchiat automat.

Eroare: Nu s-a putut configura o notificare de administrator

Setarea ms de backup sql nu va fi făcută până notificările sunt configurate (de obicei prin e-mail). Cred că toată lumea înțelege că administratorul trebuie să verifice cu promptitudine pentru orice erori în timpul operațiunilor de salvare de rezervă, în caz contrar, totul cu o copie de rezervă nu are nici un sens. La urma urmei, faptul că backup-ul este astăzi nu înseamnă că va funcționa mâine. Motivele pentru acest lucru poate fi mai multe: rămâne fără spațiu pe disc, schimba regulile directorului, etc. În practica noastră, a fost un caz de testare, atunci când un administrator în momentul prăbușirii constatat că copiile de rezervă a bazei de date de lucru a fost de câteva luni, nu au fost create.

Este necesar de menționat un moment neplăcut: o notificare, care trimite o DataBase componentă regulată Mail nu conține informații despre eroare. Prin urmare, după ce îl primiți, pentru a înțelege gravitatea erorilor, administratorul trebuie sa ma uit de fiecare dată când jurnalele SQL Server. Din păcate, în timp, mulți administratori nu mai ignora erorile și să le răspundă. Prin lege, genul a fost la o astfel de bază de timp zboară în iad.