Pagina 3 din 4
Fragmentarea indicilor
În plus față de fragmentarea la nivelul sistemului de fișiere și în interiorul fișierului jurnal, este posibilă și fragmentarea în fișierele de date, în structurile care stochează date tabele și index. În fișierul de date există două tipuri de fragmentare de bază:
Fig. 1. Structura paginii bazei de date
Deseori, fragmentarea internă este cauzată de schimbările de date, cum ar fi inserțiile, actualizările și ștergerile, care pot lăsa pagini goale pe pagină. Ordonarea greșită a factorului de umplere poate contribui, de asemenea, la fragmentare, detalii sunt furnizate în documentația tehnică. În funcție de schema tabelei / indexului și de caracteristicile aplicației, acest spațiu gol poate să nu fie utilizabil după ce acesta apare, ceea ce poate duce la o creștere permanentă a spațiului neutilizat din baza de date.
Luați în considerare, de exemplu, un tabel de 100 de milioane de rânduri, unde înregistrarea medie este de 400 de octeți în dimensiune. În timp, șablonul de modificare a datelor aplicației va avea ca rezultat o medie de 2800 de octeți de spațiu liber pe pagină. Spațiul total cerut de tabel este de 59 GB, acesta fiind generat de următorul calcul: 8096-2800 / 400 = 13 intrări pe o pagină de 8 kilobyte, apoi împărțiți 100 de milioane cu 13 pentru a obține numărul de pagini. Dacă spațiul nu a dispărut, atunci pe o singură pagină ar fi posibil să se potrivească 20 de înregistrări, ceea ce reduce spațiul total necesar până la 38 GB. O economie imensă!
Un spațiu neutilizat pe paginile de date / indexuri poate duce astfel la stocarea aceleiași cantități de date pe un număr mai mare de pagini. Acest lucru nu numai că duce la mai mult spațiu pe disc, dar, de asemenea, înseamnă că cererea trebuie să efectueze mai multe operații I / O pentru a citi același număr de date. Toate aceste pagini suplimentare ocupă mai mult spațiu în cache-ul de date, preluând astfel memoria serverului.
În Fig. 2 arată paginile index create recent cu un factor de umplere de 100% - paginile sunt pline, iar ordinea fizică a paginilor coincide cu ordinea logică. În Fig. 3 prezintă fragmentarea care poate apărea după inserții / actualizări / ștergeri aleatorii.
Fig. 2. Paginile proaspete create ale indexului fără fragmentare, paginile sunt pline de 100%
Fragmentarea poate fi prevenită uneori prin modificarea schemei tabel / index, dar, așa cum am menționat mai sus, acest lucru poate fi foarte dificil sau imposibil. Dacă prevenirea este nerealistă, există modalități de a elimina fragmentarea după apariția acesteia - în special prin restaurarea sau reorganizarea indexului.
Unii utilizatori decid pur și simplu să restaureze sau să reconstruiască toate indexurile în fiecare noapte sau în fiecare săptămână (folosind, de exemplu, o variantă cu un plan de întreținere), mai degrabă decât să-și imagineze ce indexuri sunt fragmentate și beneficiile eliminării fragmentării. Deși aceasta poate fi o soluție bună pentru un administrator de baze de date care nu dorește să aplice o soluție cu un efort minim, aceasta poate fi o alegere foarte proastă pentru bazele de date și sistemele mai mari, în care resursele sunt puține.
Indiferent de metoda utilizată, este recomandat să căutați în mod regulat și să remediați fragmentarea.
Procesorul de interogare face parte din SQL Server, care decide cum să execute interogarea - și anume, ce tabele și indexuri de utilizat și ce operații să le efectueze pentru a obține rezultate; acest lucru se numește un plan de interogare. Cea mai importantă contribuție la acest proces decizional este statisticile care descriu distribuția valorilor datelor pentru coloanele dintr-un tabel sau un index. Evident, pentru a fi util pentru procesorul de interogări, statisticile trebuie să fie corecte și proaspete, altfel pot fi selectate planuri de interogare neproductive.
Statisticile sunt create prin citirea datelor tabele / index și determinarea distribuției datelor pentru coloanele corespunzătoare. Statisticile pot fi construite prin verificarea tuturor valorilor datelor pentru o anumită coloană (scanare completă), dar poate fi de asemenea construită pe baza procentului de date specificat de utilizator (cazuri de testare). Dacă distribuția valorilor din coloană este relativ uniformă, atunci verificarea exemplelor poate fi suficientă, ceea ce face ca crearea și actualizarea statisticilor să fie mai rapidă decât printr-o verificare completă.
Fig. 4. Modificarea setărilor bazei de date prin SQL Server Management Studio
Dacă aveți nevoie să actualizați statisticile ca parte a planului de întreținere obișnuit, trebuie să vă amintiți despre un truc. Atât STATISTICILE UPDATE, cât și sp_updatestats utilizează implicit nivelul de colectare a datelor specificat anterior (dacă este specificat) - și poate fi mai mic decât scanarea completă. Recuperarea indexului actualizează automat statisticile cu o scanare completă. Dacă actualizați manual statisticile după restaurarea indexului, puteți obține statistici și mai puțin precise! Acest lucru se poate întâmpla dacă verificarea exemplelor din actualizare suprascrie manual scanarea completă creată prin restaurarea indexului. Pe de altă parte, atunci când indexul este reorganizat, statisticile nu sunt actualizate deloc.
Din nou, mulți dintre aceștia au un plan de întreținere care actualizează toate statisticile în orice moment înainte sau după restaurarea tuturor indiciilor - și fără să știe, se pot dovedi statistici mai puțin corecte. Dacă alegeți o recuperare simplă a tuturor indexurilor din când în când, atunci va avea grijă de statistici. Dacă selectați o cale mai complexă cu eliminarea fragmentării, merită să faceți și să mențineți statistici. Propun următoarele:
- Analizați indexurile și determinați ce index trebuie utilizat și cum să defragmentați.
- Actualizați statisticile pentru toate indexurile care au fost restaurate.
- Actualizați statisticile pentru toate coloanele care nu sunt indexate.
Văd toate aceste întrebări pe forumurile SQL Server, așa că în acest articol voi oferi o imagine de ansamblu asupra sistemului de înregistrare și de recuperare și va explica de ce aceasta este o parte integrantă a modulului de stocare SQL Server. Arhitectura jurnalului de tranzacții va fi luată în considerare și cum.
Dar acesta este singurul lucru care se poate face? Este posibil să se efectueze o monitorizare proactivă a performanței, o procedură de gestionare simplă care utilizează definiția parametrilor de bază ai sistemului, achiziționarea de standarde și monitorizarea continuă. În acest articol, voi vorbi despre cum să n.
Cu toate acestea, nu trebuie să faceți acest lucru. Există o alternativă foarte simplă care folosește ceea ce este cunoscut sub numele de blocuri hash sau chei hash. Ce este hash? Pe scurt, hash este un rezultat întreg al unui algoritm (cunoscut ca o funcție hash) aplicat unui șir dat.
Articole similare
Trimiteți-le prietenilor: