Pagina 5 din 6
Modificarea funcției de urmărire a modificărilor
După cum am menționat, modificările de urmărire reprezintă un proces sincron, care este mult mai puțin complicat decât colectarea datelor privind modificările. Aceasta este o parte a tranzacției care face o schimbare a rândului în tabela monitorizată și faptul că șirul s-a schimbat este urmărit într-un tabel separat. Acest tabel este ceea ce se numește tabelul intern, iar numele acestuia cu locația de stocare nu poate fi controlat. Nu consider că este o problemă, deoarece în acest tabel trebuie să existe mult mai puține date decât în tabelul de schimbare utilizat pentru colectarea datelor de schimbare. Dar, așa cum voi explica acum, problemele cu spațiul de pe discuri sunt încă posibile.
Faptul că urmărirea schimbării rulează în mod sincron înseamnă că există o procesare mult mai mică în fiecare tranzacție care modifică tabela monitorizată. Impactul asupra performanței este similar cu ceea ce se întâmplă atunci când există un indice nonclust în tabel care trebuie schimbat cu fiecare schimbare de tabel. De asemenea, tranzacțiile sunt urmărite atunci când sunt angajate succesiv în tabela internă sys.syscommittab.
Modificări de urmărire este activată și dezactivată folosind o sintaxă convențională a ALTER DATABASE și ALTER TABLE, și ar trebui să fie același model ca și colectarea de date modificări, în cazul în care acesta ar trebui să fie incluse la nivelul bazei de date înainte de a porni la nivel de masă. Secvența de operații va arăta cam așa:
permisiunile necesare pentru a permite urmărirea schimbărilor la nivelul bazei de date și tabelele de date sunt, de asemenea, diferite de cele necesare pentru a permite modificări de colectare a datelor:, respectiv db_owner și proprietarul de masă. Când este activată urmărirea modificărilor la nivelul bazei de date, puteți seta o perioadă de păstrare și puteți specifica dacă datele schimbării vor fi șterse automat. Perioada de reținere implicită este de 2 zile, cu un maxim de 90 de zile și un minim de un minut.
Curățarea automată este, de asemenea, activată implicit. Atunci când efectuați modificări la acești parametri, este necesar să evaluați aceleași priorități pe care le-am menționat în legătură cu colectarea acestor modificări, ceea ce este mai important pentru aplicație: spațiu pe disc sau performanță.
În mod implicit, pentru fiecare rând se colectează numai modificarea acesteia. Acest lucru se face prin a face o notă de cheia primară a liniei schimbat (ceea ce înseamnă incapacitatea de a urmări modificările la masă fără o cheie primară), împreună cu numărul versiunii (după cum urmărirea modificărilor bazei de date activată, setați numărul de versiune, care permite pentru a determina ordinea operațiilor) și tipul operațiunea care a efectuat modificarea. Alternativ, puteți urmări și coloanele care s-au modificat, aceasta necesită 4 octeți pe fiecare coloană modificată.
Monitorizarea spațiului pe disc este puțin diferită de modificările de urmărire, deoarece datele de schimbare sunt stocate în tabele interne. Pentru a găsi numele tabelelor interne utilizate, pur și simplu utilizați vizualizarea directorului de sistem sys.internal_tables:
Apoi treceți numele la sp_spaceused pentru a vedea cât spațiu pe disc este utilizat.
Spre deosebire de colectarea datelor de modificare, atunci când este activată urmărirea schimbării, există restricții asupra DDL care poate fi efectuată pe tabela monitorizată. Limita cea mai notabilă este incapacitatea de a modifica în orice mod cheia primară. O altă limitare demn de menționat este faptul că ALTER TABLE SWITCH va eșua dacă oricare din tabelele afectate a permis urmărirea schimbării. Acest lucru este cel mai probabil cauzată de faptul că nu are sens să pornească automat sau de a elimina modificările de urmărire pentru a fi întrerupt de urmărire, rupt în secțiuni, tabele, partiții sau de masă urmărite pentru a fi incluse într-un tabel compartimentate.
Modificările sunt preluate din tabelele de schimbare internă folosind noua funcție CHANGETABLES (CHANGES ...). Este nevoie de numele monitorizate pentru modificări în tabel plus numărul versiunii din vremurile anterioare, când a fost utilizat, și returnează informații despre toate rândurile care au schimbat de la ultima dată. Există diferite funcții pentru a găsi versiunea actuală și cea mai veche. Aplicația poate apoi să utilizeze informațiile returnate pentru a interoga tabelul urmărit pentru modificări pentru a obține valorile reale ale coloanei. Aceasta, desigur, procedeu în mai multe etape - a obține mai întâi versiunea curentă, atunci acea versiune este utilizată pentru a solicita tabelul de urmărire modificarea și apoi de fapt, solicitată pentru datele din coloana corespunzătoare versiunii.
Toate aceste întrebări am vedea întotdeauna la forumuri SQL Server, astfel încât în acest articol am de gând să ofere o imagine de ansamblu a exploatării forestiere și de recuperare și de a explica de ce există această 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: