Este o greșeală să ia în considerare în baza de date ca un fel de unitate standard, deoarece, în timp, pot apărea diferite tipuri de situații nedorite - degradarea performanței, funcționarea necorespunzătoare și așa mai departe.
Pentru a minimiza apariția unor astfel de situații, planurile de servicii sunt create din sarcini care garantează stabilitatea și performanța optimă a bazelor de date.
Dintre aceste sarcini, putem distinge următoarele:
Să luăm în considerare automatizarea fiecăreia dintre aceste sarcini.
Deci, primul punct ...
Pe lângă fragmentarea sistemului de fișiere și a fișierului jurnal, un impact semnificativ asupra performanței bazei de date este fragmentarea în fișierele de date:
1. Fragmentarea în paginile index individuale
După introducerea, actualizarea și ștergerea intrărilor, spațiile goale ale paginilor apar în mod inevitabil. Nu este nimic în neregulă cu acest lucru, deoarece această situație este destul de normală, dacă nu pentru una ...
Un rol foarte important îl joacă lungimea șirului. De exemplu, dacă șirul are o dimensiune care durează mai mult de o jumătate de pagină, o jumătate liberă a acestei pagini nu va fi utilizată. Ca urmare, pe măsură ce numărul de rânduri crește, va exista o creștere a spațiului neutilizat din baza de date.
Pentru a combate acest tip de fragmentare este în stadiul de proiectare a schemei, adică alegerea acelor tipuri de date care s-ar potrivi compact pe pagini.
2. Fragmentarea în structurile indexului
Motivul principal al acestui tip de fragmentare este operațiunile de divizare a paginilor. De exemplu, în funcție de structura cheii primare, trebuie introdus un rând nou pe o anumită pagină index, dar nu există suficient spațiu pentru a plasa datele introduse.
În acest caz, este creată o pagină nouă, la care se mută aproximativ jumătate din intrările din pagina veche. O pagină nouă adesea nu este adiacent fizic celei vechi și, prin urmare, este marcată de sistem ca fiind fragmentată.
În orice caz, fragmentarea duce la creșterea numărului de pagini pentru stocarea aceleiași cantități de informații. Acest lucru duce automat la o creștere a dimensiunii bazei de date și la creșterea spațiului neutilizat.
Atunci când execută interogări care accesează indexuri fragmentate, sunt necesare mai multe operații IO. În plus, fragmentarea impune costuri suplimentare pe memoria serverului în sine, care trebuie să stocheze pagini suplimentare în memoria cache.
Pentru a preveni fragmentarea în arsenalul SQL Server, există comenzi pentru reorganizarea și reconstruirea indexurilor.
Reconstrucția indexului implică ștergerea celui vechi și crearea unui nou exemplu de index, în care datele de pe pagini sunt comprimate și organizate cât se poate de continuu. Este important de menționat că operațiunea de restructurare a indicelui este foarte costisitoare.
Prin urmare, în cazul în care fragmentarea este neglijabilă, este preferabil să se reorganizeze indicele existent. Această operațiune necesită mai puține resurse de sistem decât re-crearea indexului și constă în reorganizarea paginilor cu nivel de frunză. În plus, reorganizarea, dacă este posibil, comprimă paginile indexurilor.
Gradul de fragmentare a unui index poate fi învățat din reprezentarea dinamică a sistemului sys.dm_db_index_physical_stats:
În această interogare, ultimul parametru stabilește modul, din valoarea căruia este posibil să se facă rapid, dar nu determină exact nivelul de fragmentare al indexului (modurile LIMITATE / NULL). Prin urmare, se recomandă setarea modurilor SAMPLED / DETAILED.
Știm unde să obținem lista de indicatori fragmentați. Acum este necesar ca fiecare dintre ele să genereze comanda ALTER INDEX corespunzătoare. În mod tradițional, cursorul este utilizat pentru aceasta:
Pentru a accelera procesul de reconstrucție a indexului, este recomandat să specificați și opțiunile SORT_IN_TEMPDB și ONLINE.
Primul vă permite să reconstruiți indici în baza de date tempdb, care este utilă în special pentru indexurile mari în caz de lipsă de memorie sau în alt mod - opțiunea este ignorată. În plus, dacă tempdb este localizat pe un alt disc, acest lucru va reduce semnificativ timpul în care a fost creat indicele. A doua opțiune vă permite să recreați indexul fără a bloca interogările față de obiectul pentru care este creat acest index.
După cum se arată, defragmentarea indici cu un grad scăzut de fragmentare sau cu un număr mic de pagini nu aduce îmbunătățiri semnificative care sporesc productivitatea atunci când se lucrează cu ei.
În plus, interogarea de mai sus poate fi rescrisă fără a utiliza cursorul:
Ca rezultat, ambele cereri în timpul execuției vor genera cereri de defragmentare a indexurilor de probleme:
De fapt, în această primă parte, pentru a crea un plan de întreținere pentru baza de date este finalizată. În următoarea parte, vom scrie o interogare pentru a actualiza automat statisticile.
Acest lucru se datorează faptului că pot exista (și ar trebui să fie) declanșatoare care declanșează când o anumită etichetă este schimbată. De exemplu, există un tabel cu directorul - spr, directorul are mai multe câmpuri. Cum puteți urmări ce sa modificat în mod specific un anumit utilizator? Faceți un declanșator care ar scrie în tabelul spr_his toate modificările.
1) Ei bine, și unde este restructurarea indicilor? Cine vă împiedică să refaceți indicii în prezența unui declanșator, nu credeți că va funcționa în acest caz? ;)
2) Declanșatorii nu datorează nimic nimănui. Ei bine, cu excepția faptului că aveți o legătură 2. Și la mine toate schimbările de date în bază trec printr-un strat de server de aplicații, de acolo și am log (anchete separate), dacă este necesar pentru mine.
CU ONLINE = ON. A doua opțiune vă permite să recreați indexul fără a bloca interogările față de obiectul pentru care este creat acest index. Aici ne referim doar la interogările SELECT.
2) Este o chestiune de gust. Pentru mine, stocarea centralizată a logicii este mult mai convenabilă / mai practică / mai rapidă pentru a fi menținută etc. și altele asemenea. Pur și simplu aceleași "hranimki" nu ar trebui să fie utilizate universal, ci numai acolo unde va fi mai necesar / mai necesar / mai simplu.
Nu gagging. Ați scos această frază din contextul din paragraful despre performanță. Se spune că există mai multe resurse pe UPDATE / INSERT / DELETE. Știți de ce? Deoarece toate aceste cereri sunt puse în așteptare în tampon și numai după reconstrucția indexului, aceste modificări se fac în baza de date. Prin urmare, utilizarea acestei opțiuni poate încărca puternic serverul.
permiteți-mi să vă întreb: în ce proiect ați trebuit să procesați baza de date și care este greutatea acesteia pe disc?
PS: în biroul meu efectul maxim a fost dat de setările unui rack normal de disc (multe, multe axe, câteva regulatoare, o memorie cache cu o baterie, un raid). Orice defragmentare a indicilor și curățarea statisticilor a dus la o creștere a productivității cu o sumă care se încadrează în limita de eroare. Serverul MSSQL pentru 1C
Aici, mai degrabă decât dimensiunea bazei de date, dimensiunea tabelelor individuale este mai importantă. care au o dimensiune mare și o caracteristică neplăcută - schimbă adesea datele. Este pentru astfel de tabele - este recomandabil să faceți defragmentarea indexurilor.
Ora este specificată în fusul orar setat pe dispozitiv.