Mărimea bazei de date, fragmentarea indexurilor și disponibilitatea după failover sunt întrebările pe care administratorii sunt interesate în această lună.
Paul S. Randal
Aveți grijă să nu vă fragmentați
Întrebare: Am citit câteva articole de blog, care pare a fi implicat faptul că nu ar trebui să aibă grijă de fragmentare de index în baze de date găzduite pe solid-state drive (SSD), deoarece acestea sunt mult mai rapide decât hard disk-uri convenționale. Înțeleg corect că scăderea performanței va fi oprită, dar pot ignora fragmentarea indexurilor?
Răspuns Indiferent de discurile folosite - dispozitivele convenționale sau SSD, trebuie să monitorizați îndeaproape fragmentarea. Fragmentarea indexurilor este asociată cu două fenomene - pagini de index neordonate și probleme de densitate a paginilor. Primul fenomen reduce eficiența citirii înainte în momentul scanării intervalelor de pagini, iar al doilea reduce densitatea datelor.
Este adevărat că întârzierile în citire și scriere pe SSD-uri sunt foarte mici. În consecință, necesitatea unor operații de I / O mai frecvente și mai mici datorită fragmentării indexului nu are un efect de performanță atât de puternic ca și cu discurile hard disk convenționale.
Cu toate acestea, reducerea densității datelor din cauza fragmentării indexurilor poate fi în continuare o problemă. Fragmentarea indexurilor apare în principal din cauza operațiunilor, care se numesc "divizarea paginii". Faptul este că noul spațiu liber de pe pagină se formează prin transferarea a jumătate din liniile indexului pe o pagină nouă. În acest caz, vechile și noile pagini sunt aproape la jumătate umplut. În cazul fragmentării mari a indexului, deseori se întâmplă ca densitatea medie a paginii să fie de 70% sau mai mică (adică 30% din spațiul liber din pagină).
Și acest lucru înseamnă că, dacă există un număr mare de indici în bazele dvs. de date, discurile costisitoare de stare solidă stochează o cantitate mare de spațiu gol, este clar că această situație este departe de a fi optimă. De asemenea, deși adiționalii I / O necesari în paginile cu densitate scăzută nu reprezintă o problemă semnificativă pentru SSD-uri, ele ocupă mai mult spațiu în buffer-ul SQL Server (cache-ul de date în memorie). Acest lucru înseamnă, de asemenea, că memoria serverelor valoroase nu este utilizată optim.
În plus față de indexarea indexului în sine, trebuie să țineți cont de cauza sa: defalcarea paginii. Este operații costisitoare care generează o mulțime de înregistrări ale tranzacțiilor în jurnal (în următorul meu de intrare pe blog-i spun cât de mult se poate agrava situația: blog-ul posta Jurnalele suplimentare intrări indică necesitatea unei prelucrări ulterioare în orice componentă, citiți jurnalul de tranzacții (de exemplu, replicarea tranzacțiilor, arhivarea, oglindirea bazei de date, expedierea prin jurnal.) Aceasta poate duce la o scădere a performanței acestor procese, așa că nu ignorați fragmentarea, chiar dacă utilizați ETE rapid SSD-drive-uri.
Nu te uita în oglindă
În mecanismul de oglindire a bazei de date, nu există suport pentru abonarea la o bază de date oglindă (deoarece există un cititor de jurnal pentru oglindirea bazelor de date publicate). Cu toate acestea, puteți utiliza metoda "initialize from lsn" pentru a vă asigura o reinitializare rapidă după o tranziție în sistemul de oglindire.
Această tehnică se bazează pe determinarea numărului de înregistrare a tranzacției pentru cea mai recentă operație de replicare aplicată bazei de date a abonatului înainte de tranziția în oglindă. O vom numi LSN2.
Unele operații oglindesc, de asemenea, oglinda bazei de date înainte de tranziție. Acesta poate, de exemplu, să creeze un număr LSN3, care este puțin mai îndelungat decât LSN2. Vor exista, de asemenea, operațiuni care nu sunt aplicate deloc DB Abonatului. Sunt mai devreme decât LSN2 sau LSN3. Le vom numi LSN1.
Toate operațiile până la LSN2 sunt aplicate în baza de date principală a abonamentelor. Toate operațiile carnei până la LSN3 sunt aplicate în baza de date principală de abonament și copiate în baza de date oglindă. Pentru a efectua o inițializare din LSN pentru un abonament nou după trecerea la oglindă, trebuie să treci LSN3 ca argument la sp_addsubscription.
Prea mare
Întrebare Dimensiunea bazei noastre de date principale a ajuns la 9 TB. Sa dovedit că pur și simplu nu avem suficientă capacitate pentru a efectua întreținerea regulată, astfel încât să nu afecteze activitatea curentă a întreprinderii. În primul rând, suntem preocupați de arhivarea bazei de date pentru a asigura posibilitatea recuperării în caz de accident. Ce ați recomanda în această situație?
În orice caz, problema cheie este crearea mai multor grupuri de fișiere în baza de date. Când se face partiționarea, secțiunile individuale ale tabelelor sau indexurilor mari sunt situate în grupuri separate de fișiere. Când împărțiți manual fiecare tabel mare este localizat într-un grup de fișiere separat (posibil cu toate indexurile).
În astfel de situații, recuperarea în cazul unui eșec este, de asemenea, mai rapidă (dacă utilizați Enterprise Edition). Va fi suficient să restabiliți rapid grupurile de fișiere necesare pentru funcționarea sistemelor OLTP. Pentru aceasta, puteți utiliza recuperarea parțială, după care utilizați disponibilitatea parțială a bazei de date pentru a returna baza de date în modul interactiv. Puteți restabili mai târziu grupuri de fișiere care conțin date mai vechi utilizând o restaurare parțială atunci când operațiile OLTP apar în grupurile de fișiere deja disponibile.
În condiții de suprasarcină
În sine, o valoare PLE nu este foarte informativă. Este necesar să se analizeze tendințele valorilor. Este posibil ca operațiile destul de legitime ale serverului SQL să conducă la o scădere semnificativă a indicațiilor PLE. Adesea citirile revin la normal. Dacă lectura PLE scade și rămâne scăzută, atunci merită îngrijorătoare.
Pragul la care trebuie să răspundă nu este o valoare fixă, așa cum este adesea scrisă. O valoare de 300 înseamnă că întregul fond de rezervă este înlocuit la fiecare 300 de secunde. Dacă aveți o piscină de 100 GB, înseamnă că 100 GB de date noi sunt citite în memorie la fiecare cinci minute. Există o problemă de performanță. Cu toate acestea, aceasta devine o problemă de performanță imensă cu mult înainte ca PLE să atingă o valoare de 300. Se poate calcula o valoare mai rezonabilă:<размер буферного пула в ГБ> / 4) × 300, după cum este descris în următoarea intrare pe blog:
PLE este exact contorul pe care trebuie să-l monitorizați, dar citirile sale au sens dacă se încadrează cu mult sub normă și rămân în această poziție mult timp. Aceasta este o recomandare generală și, din păcate, nu este potrivită în toate situațiile.
Articole similare
Trimiteți-le prietenilor: