În timpul prezentării backup și restaurare a bazelor de date SQL Server, vi se oferă de obicei două tipuri de întrebări. Primul set direct în cursul prezentării sălii, al doilea set după aceea, într-o conversație privată. Aceste probleme „private“ sunt adesea mai interesante și voi încerca să dea răspunsuri la cele mai complexe și interesante, în loc de a scrie un alt articol despre modul în care ar trebui să facă copii de siguranță, sau de ce ar trebui să facă copii de siguranță, sau chiar de ce trebuie verificați backup-urile (dar ar trebui să verificați backup-urile).
Pot implementa o copie de rezervă pe o versiune de SQL Server diferită de cea pe care a fost făcută copia de rezervă? Ce probleme pot apărea?
Pentru a determina pe care versiune de SQL Server backup-ul a fost creat, trebuie să te uiți la antetul fișierului de backup:
Pot folosi operația de restaurare pentru a crea o copie a bazei de date? Ce poate merge prost?
Da, puteți face acest lucru. Dacă implementați o copie de siguranță la un alt server, trebuie să vă asigurați că noul server, vă prezintă aceleași unități logice, la fel ca în serverul de „vechi“ sau manual, setați calea corectă pentru fișierele bazei de date folosind cu echipa opțiunea MOVE Restaureaza baza de date:
Fișierele de bază de date au atât nume logice, cât și nume fizice de fișiere. Trebuie doar să înregistrați toate numele logice ale fișierelor și să definiți o nouă locație fizică pentru fiecare dintre acestea.
Principalele probleme care pot apărea sunt erori asociate cu lipsa de spațiu liber pe disc la care restaurați baza de date, sau s-ar putea uita să specifici un nume nou pentru baza de date, și SQL Server va încerca să restaurați baza de date pe partea de sus a unei baze de date existente.
Când restaurați baza de date de pe noul server, puteți întâlni o problemă «Utilizatorii orfanii» (utilizatori care și-au pierdut conexiunea lor la evidența contabilă, în conformitate cu traducerea pe MSDN. - comentariul traducătorului), În cazul în care utilizatorul de bază de date asociată contului nu este reprezentat pe noul server . Veți avea nevoie pentru a corecta această eroare.
Pot atașa un fișier MDF ca bază de date dacă nu am un fișier jurnal de tranzacții?
Singura dată când este acceptabil - în cazul în care jurnalul de tranzacții a fost pierdut deja după muncă de bază de date a fost completată în mod corespunzător. În orice caz - nu este o idee bună. Când atașați o bază de date, fișier jurnal de tranzacții, precum și fișierul de date care sunt necesare pentru procesul de recuperare a bazei de date (aici restaurarea bazei de date nu este înțeleasă de operare RESTORE DATABASE, și de recuperare - un proces care are loc de fiecare dată când porniți SQL Server, în care SQL Server «are loc „în jurnalul de tranzacții și fișierele de date duce la o stare consistentă - nota traducătorului) .. Cu toate acestea, în unele cazuri, se pot alătura fișierul de date fără un fișier jurnal de tranzacții, dar această caracteristică este doar pentru acele cazuri în care fișierul jurnal de tranzacții a fost deteriorate sau pierdute ca urmare a unor probleme cu echipamentele și absența backup-uri. Desigur, baza de date nu poate exista fără jurnalul de tranzacții, iar atunci când atașați baza de date, fără un fișier jurnal de tranzacții, SQL Server pur și simplu recrea.
Îmbinarea fișierul de date fără un fișier jurnal de tranzacții rupe lanțul de jurnal și, în plus, este posibil ca baza de date compromisă integritatea structurală a tranzacțională sau (în funcție de starea bazei de date la momentul „pierderea“ a jurnalului de tranzacții). Funcționarea atașării unei astfel de baze de date poate duce la o eroare, indiferent de acțiunile care nu sunt luate.
Baza de date este pe SAN. Am auzit că backup-urile SAN sunt suficiente. Este adevărat?
Acest lucru poate fi adevărat. Principalul lucru pe care SAN (sisteme de stocare, rețea / stocare. - Aprox interpret) acceptă tranzacții SQL Server. Dacă este așa, atunci ea ar ști că există o tranzacție și existența acestor tranzacții ar putea însemna în baza de date, datele din fișierele de date nu poate fi completă, deoarece procesul de înregistrare a datelor schimbate în aceste tranzacții pe hard disk poate fi nu a fost finalizată la momentul backup. Aceste backup-uri, care se face SQL Server, desigur, să ia în considerare acești factori.
Domeniul de date EMC, de exemplu, este o combinație de software și SAN care acceptă suportul tranzacțiilor, precum produsele altor furnizori, dar trebuie să verificați documentația SAN. Rețineți prezența unor fraze precum "consistența tranzacțiilor" sau "conștient de tranzacții" sau ceva similar. Dacă nu le-ați găsit, v-aș sfătui să verificați recuperarea bazei de date înainte de a decide că backup-urile SAN sunt suficiente pentru a vă îndeplini toate cerințele de rezervă. Cu toate acestea, chiar și după ce v-ați asigurat că backup-urile SAN sunt executate corect, aceasta nu înseamnă că nu mai aveți nevoie de copii de rezervă "native" SQL Server. Dacă aveți nevoie de capacitatea de a restabili baza de date la un moment dat, de exemplu, trebuie să efectuați copii de siguranță ale jurnalului de tranzacții utilizând SQL Server.
De obicei, atunci când creați o copie de siguranță, un SAN activat de SQL Server utilizează interfața VDI SQL Server și "îngheață" baza de date pentru durata copierii. Dacă executați mecanismul de creare a unei astfel de copii de rezervă și căutați în jurnalul de erori SQL Server, acolo veți vedea mesajele că operațiile IO au fost înghețate.
Dacă vă bazați pe backup-urile create de SAN, trebuie să efectuați controale de integritate a bazei de date fie în baza de date "live", fie pe copii restaurate din copia de rezervă SAN. În caz contrar, puteți crea o copie de rezervă a bazei de date deteriorate pentru o lungă perioadă de timp și nici măcar nu știți despre ea.
De ce nu pot folosi copii de siguranță ale fișierelor de date create de Windows ca backup? Nu am nevoie de capacitatea de recuperare în orice moment.
SQL Server nu este o aplicație desktop obișnuită. El își gestionează dosarele astfel încât să asigure performanța tuturor proprietăților ACID (Atomic, Consistency, Isolated, Durable). Pe scurt, pentru a asigura finalizarea cu succes a tranzacțiilor, SQL Server încearcă să nu dea nimănui accesul la fișierele sale și le modifică după cum este necesar.
Dacă copiați doar fișierul de date, ignorarea și blocarea tranzacțiilor care pot fi efectuate în acest moment, ceea ce înseamnă că, atunci când încercați să atașați fișierul mai târziu, acesta va fi într-o stare necorespunzătoare, care va duce la erori.
Este mult mai sigur și mai ușor de utilizat mecanismul încorporat din SQL Server
pentru a crea copii de rezervă. Această copie de rezervă va fi o copie completă a bazei dvs. de date și toate proprietățile ACID vor fi executate.
Am o bază de date foarte mică. De ce nu pot "descarca" fiecare tabel pe un disc pentru a crea o copie de rezervă?
Puteți folosi ceva asemănător SQLCMD și descărcați tabelele într-un fișier text simplu, dar în loc să restaurați doar o bază de date cu o singură comandă, trebuie să executați o serie întreagă de comenzi. În primul rând, va trebui să creați o bază de date goală. Apoi, va trebui să creați și să încărcați fiecare tabel din fișier. Dacă orice tabel conține o coloană IDENTITY, va trebui să efectuați SET IDENTITY_INSERT în fiecare dintre aceste tabele. De asemenea, va trebui să definiți cu atenție ordinea în care veți încărca datele în tabele pentru a asigura integritatea.
În plus, rețineți că toate mesele spălate pe disc la momente diferite, astfel încât, dacă datele sunt într-un fel modificat în timpul descărcării, după recuperare, nu obține baza de date într-o stare consistentă și va trebui să căutați manual și să remedieze erorile.
Desigur, aveți dreptul să faceți acest lucru. Pe de altă parte, puteți executa pur și simplu comanda BACKUP DATABASE și, atunci când este necesar, puteți restabili această copie de rezervă.
De ce să plătiți bani pentru utilitarele care fac backup, dacă SQL Server în sine știe cum să facă acest lucru?
Există trei motive principale pentru utilizarea programelor de terțe părți care creează copii de rezervă: de management, automatizare și funcționalitate. Dacă sunteți un începător sau DBA există un administrator de baze de date, dar trebuie să mențină baza de date ca un plus față de locul de muncă principal, este posibil să nu fie conștienți de modul în care, în cazul în care și de ce pentru a configura copii de rezervă în SQL Server. Un bun instrument (cum ar fi SQL Backup Pro) vă poate oferi doar un fel de conducere de care aveți nevoie pentru a păstra integritatea bazei de date din copiile de rezervă.
Backups create de SQL Server în sine funcționează bine, dar trebuie să faceți o mulțime de lucru pentru a le configura și chiar mai mult pentru a le automatiza. O bună utilitate a terților va face procesul de automatizare foarte simplu. Mai mult decât atât, cu ajutorul acestuia puteți automatiza alte procese asociate copiilor de rezervă, precum oglindirea / expedierea jurnalului și verificarea integrității copiei de rezervă.
În cele din urmă, deși backup-urile SQL Server fac ceea ce aveți nevoie, probabil că nu o fac cel mai bine. De exemplu, unele utilitare comprimă mai eficient copii de rezervă, economisind astfel mai mult spațiu pe disc și scurtează timpul de backup. De asemenea, ele adaugă funcționalități - cum ar fi criptarea unui fișier de backup (ceva asemănător este posibil cu instrumentele SQL Server built-in numai dacă baza de date însăși este criptată).
Dacă copia de rezervă se află pe un balon de rețea, poate cineva să o citească?
Mai mult, puteți obține o schemă de bază de date sau date din copia de rezervă, chiar dacă nu o restaurați. Dacă aveți un instrument Compara de date SQL, ea a început să folosească cheia / export va fi capabil de a trage toate datele de rezervă în CSV format, comparând backup într-o bază de date goală, fără a cere nici o parolă. De asemenea, același SQL Data Compare poate crea pentru dvs. un script care creează o schemă de bază de date.
Pentru a împiedica accesul neautorizat la backup, va trebui să faceți mai multe lucruri. În primul rând, asigurați-vă că mingea pe care sunt stocate copii de rezervă este disponibilă unui număr limitat de persoane. În al doilea rând, trebuie să stocați doar copiile de rezervă de care aveți nevoie. În cele din urmă, dacă utilizați un utilitar terț pentru a crea backup-uri (SQL Backup Pro tip), puteți cripta de rezervă, astfel încât, dacă cineva și să obțină acces direct la un fișier, apoi citiți afară nu se poate face nimic.
Fără instrumentele terță parte, puteți realiza acest lucru utilizând Transcrierea datelor criptate (TDE).
Pentru a asigura cel mai bun nivel de securitate, trebuie să efectuați toate cele de mai sus.
Poate cineva să modifice conținutul copiei de rezervă?
Există vreun steag pe care l-am setat când creez o copie de rezervă, pot fi sigur că mă pot întoarce întotdeauna din ea?
Dacă sub acest pavilion vrei să spui că procesul de rezervă include operația de restaurare VERIFYONLY după crearea unei copii de rezervă, atunci nu, nu poți fi sigur că puteți restaura baza de date de la această copie de rezervă. RESTORE VERIFYONLY poate efectua un set de două controale.
Mai întâi, verifică antetul copiei de rezervă pentru a vă asigura că nu există erori în ea. Dacă antetul este corupt, atunci nu puteți restaura baza de date din această copie de rezervă.
Problemele pot apărea în două locuri. În primul rând, verificarea antetului în timpul VERIFYONLY nu verifică tot ce poate afecta procesul de recuperare. Aceasta înseamnă că RESTORE VERIFYONLY poate fi finalizat fără erori, însă baza de date nu poate fi restaurată din copia "verificată".
În al doilea rând, CHECKSUM nu poate detecta prejudiciul care a avut loc în memorie. Dacă pagina de date a fost actualizată, în timp ce în memorie, iar apoi a fost vina ei înainte de a fi fost scrisă pe disc (și, prin urmare, în rezervă), apoi calculul sumei de control nu arată nici o eroare, ci pur și simplu confirmă faptul că backup-ul a fost scris același lucru pagină care conținute în baza de date la momentul backup. Ie în cazul în care pagina a fost deja deteriorat în momentul creării copiei de rezervă, eroarea nu poate fi găsit folosind o sumă de control și de a restabili această copie de rezervă poate eșua.
Singura modalitate de a ști cu certitudine că vă puteți recupera din baza de date de rezervă și din baza de date rezultată nu este deteriorată este să o restabiliți și, de preferință, să executați o verificare a integrității bazei de date pe copia restaurată.
Dispozitivul de backup conține altceva decât date? Poate cineva să citească parole de la el?
Backup conține nu numai date. Acesta conține întreaga structură a bazei de date. Acesta include toate datele, procedurile, vizualizările, funcțiile și tot restul codului. De asemenea, conține toate setările bazei de date. În cele din urmă, acesta conține toate informațiile despre utilizatorii bazei de date. Pentru o bază de date normală, fiecare utilizator bază de date este asociat cu un cont SQL Server. Parolele acestor utilizatori sunt stocate împreună cu contul, astfel încât aceste parole nu vor fi salvate.
Cu toate acestea, stand-alone baze de date (baze de date conținute - un comentariu al traducătorului.), Există conceptul de USER CU PAROLA, ca ideea de bază de date autonomă necesită o conexiune minimă a unui astfel de baze de date la server. În acest caz, parola va fi în rezervă, ceea ce poate duce la încercarea de a obține de acolo. Parolele nu sunt stocate în text clar, acestea sunt trunchiate, la fel ca parolele de conturi (care sunt stocate în baza de date a sistemului, desigur, datele de bază și căderea în rezervă sa).
Microsoft oferă câteva bune practici pentru securitatea bazelor de date offline.
De ce în indexele de rezervă, statistici și alte lucruri care sunt ușor de recreat? Este doar o pierdere de timp?
Și, în opinia mea, o pierdere de timp - ea încearcă să împartă lucrurile în acest mod și să facă o copie de rezervă de doar o parte. În primul rând, cum se face? De exemplu, ca date zabekapit, face, cu, de backup indicii grupat? Este imposibil, deoarece nivelul de frunze al indicelui cluster - pagina de date. Ie putem spune că indicii grupat - ei înșiși aceste tabele, indecși, astfel grupate ar trebui să fie incluse în copia de rezervă. Desigur, este posibil să se separe indexurile nonclustered într-un filegroup separat și face o copie de rezervă, dar apoi, după restaurarea copiei de rezervă, pe care o avem, avem încă nevoie să se întoarcă acest grup fișier la viață și de a reconstrui toate indexurile. Deci, ce vom realiza?
Statisticile vor provoca, de asemenea, probleme. SQL Server susține statisticile împreună cu baza de date (și necesită foarte puțin spațiu, deoarece o histogramă numită statistici este construită doar pe 200 de linii) și o restaurează împreună cu baza de date. Cu toate acestea, dacă după recuperare începem să recreăm indiciile, deoarece nu au făcut o copie de rezervă, va trebui să recrea statisticile. Acest lucru va necesita, de asemenea, timp suplimentar, iar baza de date, în același timp, va rămâne inaccesibilă.
În final, aș argumenta cu fraza „ușor pentru a recrea“, pentru că în caz de urgență, întregul proces poate fi foarte confuz, ceea ce va duce în mod inevitabil la faptul că persoanele care lucrează cu această bază de date nu vor putea accesa mult mai mult să-l timp decât în cazul unui simplu de restaurare de la spate.
Ideea de a crea o copie de rezervă este că puteți restabili baza de date cât mai repede și mai eficient posibil. Cu cât este mai complex procesul de recuperare, cu atât este mai puțin eficientă backup-ul. Da, stocarea indexurilor, a utilizatorilor, a procedurilor stocate și a tuturor celorlalte necesită mai mult spațiu, dar creșterea vitezei de recuperare datorită faptului că totul se află într-un singur loc costă acest spațiu suplimentar.
OMG! Tocmai am șters masa! Știu că acesta este în jurnalul de tranzacții. Cum pot să-l primesc înapoi?
O altă opțiune este utilizarea unor utilități terță parte, cum ar fi SQL Backup Pro, care poate restaura obiecte individuale de baze de date online din backup-urile existente.
Și dacă vreau doar să creez folosind un script de rezervă pentru a construi baza de date, fără a restabili backup-ul direct ...?
Nu există instrumente standard pentru crearea unui astfel de script în SQL Server. Cu toate acestea, utilitarele, cum ar fi SQL Compare, o pot genera. Este ușor de creat utilizând o interfață grafică, dar este posibil să utilizați PowerShell:
'C: \ Program Files (x86) \ Red Gate \ SQL Compara 8 \ SQLCompare.exe' /Backup1:C:\MyBackups\MyBackupFile.bak / MakeScripts: "C: \ MyScripts \ MyBackupScript"
De asemenea, puteți acorda atenție programului SQL Virtual Restore. Acest utilitar vă permite să montați un backup pe serverul dvs. SQL ca și cum ați executa procesul de restaurare din această copie de rezervă, dar nu necesită utilizarea întregului loc necesar pentru recuperare. De backup instalat în acest fel arata ca baza de date cea mai comună și puteți să-l script-ul în orice mod convenabil.
Trimiteți-le prietenilor: