Paul S. Randal
Mutarea la o nouă matrice de discuri
Mai întâi, puneți baza de date în modul offline folosind următoarea comandă. Dacă utilizatorii sunt conectați la baza de date, trebuie mai întâi să resetați conexiunile:
Blocări de pagină pe termen scurt
Î: Nu pot să găsesc câteva lucruri despre reglarea performanțelor. Am citit de mai multe ori că trebuie să eviți blocarea paginilor pe termen scurt. Nu înțeleg ce înseamnă "pagina" sau "blocarea" sau de ce blocarea paginii pe termen scurt poate fi o problemă. Ați putea explica toate acestea în detaliu?
Răspuns: Toate datele din baza de date SQL Server sunt stocate în fișierele de date. Structura internă a acestor fișiere este astfel încât acestea sunt organizate sub formă de secvențe de blocuri de lungime de 8 KB, numite pagini. Page - principala unitate de stocare și I / O din sistemul de management SQL Server. Paginile sunt de obicei stocate în fișierele de date de pe disc, iar înainte de a procesa cererea, SQL Server trebuie să citească și să aloce paginile corespunzătoare din memoria cache (numită și un pool buffer).
SQL Server folosește diferite tipuri de pagini pentru a stoca diferite tipuri de date relaționale (de exemplu, rânduri de tabelă, linii de indici nonclust, text sau date LOB). Există, de asemenea, pagini care stochează părți ale structurilor de date interne solicitate de SQL Server pentru a organiza și a accesa paginile de stocare a datelor relaționale.
Blocarea pe termen scurt (blocare) este un mecanism intern ușor, utilizat de SQL Server pentru a sincroniza accesul la o pagină din memoria cache. Există două tipuri de încuietori pe termen scurt pe care trebuie să le monitorizați: blocarea normală și blocarea I / O. Dacă firul SQL Server trebuie să aștepte primirea unuia dintre aceste încuietori, acest lucru are un efect negativ asupra performanței.
Când SQL Server așteaptă ca o parte din fișierul de date să fie citită de pe disc, poate fi creată blocarea I / O a paginii. Dacă astfel de blocări durează prea mult timp, aceasta indică de obicei probleme cu performanța subsistemului disc (adică, supraîncărcarea acestuia).
Încercarea mai multor fire SQL Server de a accesa o singură pagină a unui fișier de date din memorie într-un mediu competitiv pentru acest acces poate duce la așteptarea închiderii paginii. Cel mai adesea acest lucru se întâmplă atunci când folosiți intensiv obiecte temporare mici în baza de date tempdb.
O explicație detaliată a modului de observare și de soluționare a problemei blocării pe termen scurt a paginilor depășește domeniul de aplicare al acestei rubrici, iar pentru informații mai detaliate, vă rugăm să consultați următoarele surse:
Flipping Snapshots de baze de date
Î: Doar acum am descoperit instantanee de baze de date. Acum le văd ca pe o alternativă la restaurarea completă și la copierea de rezervă a buștenilor. Am de gând să creez un instantaneu în fiecare oră sau cam așa ceva și dacă ceva nu merge bine, pot recupera datele corupte. Acest mod de recuperare a datelor este mult mai puțin supărător și mult mai rapid. Există ceva în neregulă cu acest plan?
Un instantaneu al bazei de date vă va permite să recuperați datele șterse accidental din ea, dacă baza de date însăși este încă disponibilă. De exemplu, dacă tabelul șters din baza de date se află încă în instantaneu, îl puteți folosi pentru a restaura tabelul șters.
În acest caz, ideea de a crea prea multe instantanee de baze de date (ca tranzacții de schimb de backup jurnal la fiecare jumătate de oră), se pare că nu din cauza unor posibile probleme de performanță. Înainte de a schimba pagina de baze de date (pentru detalii vezi. „Închiderea Page dispozitivul de blocare“ secțiune), este necesar să copiat sincronă în toate instantaneele de baze de date existente, care versiune a acestei pagini încă. Cele mai multe imagini ale bazei de date, cu atât mai multe pagini trebuie să copiați și performanța scade.
Un alt motiv pentru a nu crea prea multe instantanee ale bazei de date este că fiecare dintre ele va conține copii ale paginilor bazei de date înainte de a le modifica. Fiecare dintre ele va crește pe măsura creșterii numărului de modificări ale bazei de date. Acest lucru poate duce la probleme legate de spațiul de pe disc, precum și de performanță.
Lumina mea, o oglindă.
Î: Am fost rugat să creez o oglindă pentru baza noastră de date, dar mă tem că oglindirea bazei de date nu ne va rezolva problema. Am avut probleme cu coruperea datelor în rețeaua de stocare (SAN), deci intenționăm să creăm o bază de date oglindă pentru asigurare. Nu toate distorsiunile vor cădea automat în oglindă? Cum poate ajuta oglindirea bazei de date să rezolve această problemă?
Răspuns: Este o întrebare foarte interesantă și complicată, multe provocând neînțelegeri și confuzii. Se pare că, cu orice tehnologie de creare a copiilor redundante ale bazei de date, distorsiunile de date vor fi propagate din baza de date principală în oglindă, dar în realitate acest lucru nu se întâmplă.
Cheia este în înțelegerea modului în care funcționează oglinda bazei de date. Desigur, distorsiunile vor ajunge la oglindă dacă motorul de sincronizare copiază complet paginile bazei de date din baza de date principală în oglindă. În acest caz, paginile distorsionate din baza de date principală vor cădea pe oglindă.
Chiar dacă pagina bazei de date este coruptă de subsistemul de bază I / O din baza de date principală, daunele nu pot ajunge direct la oglindă. Cel mai rău care se poate întâmpla - SQL Server nu poate detecta pagini corupte (din cauza checksum pagina off) și deteriorat valoarea coloanei va fi utilizată pentru calcularea valorii stocate în baza de date. Ca rezultat, rezultatul greșit va cădea în oglinda bazei de date - aceasta este așa-numita daună secundară. Așa cum am spus mai devreme, în cazul în care checksum pagina de autentificare, distorsiunea va fi atentionat cand citirea unei pagini de pe disc, iar distorsiunea de ordinul doi nu.
Acest comportament explică, de asemenea, de ce verificarea integrității din baza de date principală nu oferă nicio informație despre integritatea stării de date în oglindă și invers. Acestea sunt două baze de date independente care sunt menținute într-o stare sincronizată prin furnizarea de descrieri de modificări fizice către baza de date, mai degrabă decât pagini specifice de bază de date.
Materiale conexe
Trimiteți-le prietenilor: