Tabele și indexuri partiționate

Partiționarea de tabele sau indexuri mari poate oferi următoarele avantaje în ceea ce privește gestionarea și performanța.

Aceasta vă permite să transferați rapid și eficient subseturi de date și să le accesați, păstrând în același timp integritatea setului de date. De exemplu, o operație, cum ar fi încărcarea datelor din OLTP într-un sistem OLAP, se efectuează în câteva secunde, nu în minute și ore, ca în cazul datelor nedistribuite.

Operațiile de întreținere pot fi efectuate mai rapid cu una sau mai multe secțiuni. Operațiile sunt mai eficiente, deoarece ele sunt efectuate numai cu subseturi de date, și nu cu întreaga masă. De exemplu, puteți comprima datele într-una sau mai multe secțiuni sau puteți reconstrui una sau mai multe secțiuni ale indexului.

Puteți îmbunătăți viteza executării interogării, în funcție de interogările care sunt adesea efectuate în configurația hardware. De exemplu, optimizatorul de interogare poate efectua rapid interogări pe echidistante se alăture a două sau mai multe tabele partiționate atunci când aceste tabele sunt aceleași coloane de separare, pentru că vă puteți conecta secțiune.

La sortarea datelor pentru operațiile I / O SQL Server, mai întâi, datele sunt sortate după secțiune. SQL Server poate accesa un singur disc la un moment dat, ceea ce poate degrada performanța. Pentru a accelera sortarea datelor, este recomandat să distribuiți fișierele de date în secțiuni pe mai multe hard disk-uri, creând RAID. Astfel, deși datele sunt sortate pe secțiuni, SQL Server poate accesa simultan toate hard disk-urile din fiecare partiție.

În plus, puteți îmbunătăți performanța prin aplicarea de încuietori la nivel de secțiune, mai degrabă decât întregul tabel. Acest lucru poate reduce numărul de conflicte de blocare pentru tabel.

Următorii termeni se aplică partiționării tabelelor și indexurilor.

Funcția de partiționare
Un obiect de bază de date care determină distribuirea rândurilor de tabele sau indexuri pe secțiuni pe baza valorilor anumitor coloane, numite coloane de partiționare. Aceasta înseamnă că funcția de partiție determină numărul de partiții din tabel și modul în care vor fi definite limitele partițiilor. De exemplu, este posibil ca un tabel care conține date despre comenzile de vânzări să fie împărțit în 12 secțiuni lunare cu valorile coloanei datetime. de exemplu după data vânzării.

Schema de separare
Un obiect de bază de date care săruri secțiuni ale funcției de partiție la un set de grupuri de fișiere. Principalul motiv pentru care secțiunile sunt împărțite în diferite grupuri de fișiere este nevoia de backup independent a acestor partiții, deoarece este întotdeauna efectuată separat pentru fiecare grup de fișiere.

Partiția de partiționare
Coloana din tabel sau indexul utilizat de funcția de partiție pentru a împărți tabelul sau indexul. Coloanele calculate care participă la funcția de partiție trebuie să fie marcate în mod explicit ca PERSISTED. Toate tipurile de date care sunt valabile pentru a fi utilizate ca coloane index pot fi folosite ca coloane de partiționare, cu excepția timestampului. Tipuri de date Ntext. text. imagine. XML. varchar (max). nvarchar (max) sau varbinary (max) nu pot fi specificate. De asemenea, nu puteți specifica un tip de date definit de utilizator pentru CLR și coloane Microsoft .NET Framework pentru tipul de date alias.

Alinierea indexului
Un index creat pe baza aceleiași scheme de partiționare ca și tabelul corespunzător. Dacă tabela și indexurile acesteia sunt aliniate, SQL Server poate trece rapid dintr-o secțiune la alta, păstrând în același timp structura de partiție atât a tabelului, cât și a indexurilor acestuia. Pentru alinierea la tabela de bază, indexul nu trebuie să utilizeze funcția de partiție cu același nume. Cu toate acestea, nici o funcție trebuie să partiție tabelul index și baza variază semnificativ, adică 1) argumentele funcției de partiție trebuie să aibă același tip de date, 2), funcțiile trebuie să definească același număr de secțiuni și 3) funcția trebuie să stabilească pentru secțiunile aceleași valori limită.

Indice necorectat
Indicele este împărțit independent de tabelul corespunzător. Adică, indexul are o schemă de partiționare diferită sau nu se află în grupul de fișiere unde se află masa de bază. Crearea unui indice partajat neparticipat poate fi util în următoarele cazuri:

Tabela de bază nu este divizată.

Cheia index este unică și nu conține o coloană de partiționare a tabelului.

Tabela de bază este necesară pentru a participa la asocierea aliniată cu tabelele care utilizează alte coloane de asociere.

Secțiunile de depanare
Procesul în care optimizatorul de interogări accesează numai anumite secțiuni în conformitate cu filtrul de interogare.

Un nou număr maxim de secțiuni (15.000) afectează memoria, operațiile indexului partiționat, comenzile DBCC și interogările. Această secțiune arată modul în care performanța afectează crearea a mai mult de 1.000 de secțiuni și cum se pot rezolva problemele. Creșterea numărului maxim de secțiuni la 15 000 vă permite să stocați date mai mult. Cu toate acestea, este recomandat să stocați datele exact cât timp este necesar și să mențineți un echilibru între performanță și numărul de secțiuni.

Utilizarea memoriei și recomandările

Cu un număr mare de partiții utilizate, se recomandă utilizarea a cel puțin 16 GB de memorie RAM. Dacă sistemul nu are suficientă memorie, instrucțiunile Limbajul de procesare a datelor (DML), instrucțiunile DDL (Language Definition Language) și alte operații pot eșua din cauza lipsei de memorie. În sistemele cu memorie RAM de 16 GB și un număr mare de procese care utilizează intensiv memoria, operațiile care operează pe un număr mare de secțiuni pot eșua din cauza lipsei de memorie. Prin urmare, cu cât aveți mai multă memorie de peste 16 MB, cu atât este mai puțin probabil să aveți o problemă cu performanța și memoria.

Limitările RAM pot afecta performanța sau capacitatea de a crea un index partiționat. Acest lucru se întâmplă, de exemplu, când indicele nu este aliniat la tabela de bază sau la indexul său cluster, dacă există în tabel.

Operațiuni cu indexuri partajate

Limitările RAM pot afecta performanța sau capacitatea de a crea un index partiționat. Acest lucru este valabil mai ales pentru indicii nealiniate. Crearea și reconstruirea indexurilor nealiniate pentru un tabel cu un număr de secțiuni mai mari de 1000 este posibilă, dar nu este acceptată. Acest lucru poate duce la degradarea performanțelor sau la consumul excesiv de memorie în timpul acestor operațiuni.

Crearea și rearanjarea indexurilor aliniate poate dura mai mult timp când crește numărul de secțiuni. Nu este recomandat să executați mai multe comenzi pentru crearea și reconstruirea indexului în același timp, deoarece există probleme de performanță și de memorie.

Atunci când o componentă SQL Server efectuează sortarea pentru a crea indexuri partiționate, mai întâi creează un tabel de sortare pentru fiecare secțiune. Apoi, fie în grupul de fișiere corespunzător din fiecare secțiune, fie în tempdb. Dacă este specificat parametrul index SORT_IN_TEMPDB, tabelele de sortare sunt construite. Toate tabelele de sortare necesită o cantitate minimă de RAM. Atunci când se construiește un index partiționat, aliniat la tabela de bază, tabelele de sortare sunt create unul câte unul, economisind dinamic din memorie. Cu toate acestea, atunci când creați un index nepartiționat partajat, tabelele sunt create în același timp. Ca rezultat, aveți nevoie de o cantitate suficientă de memorie RAM pentru a le procesa în paralel. Cu cât este mai mare numărul de secțiuni, cu atât este necesară mai multă memorie RAM. Pentru fiecare secțiune, dimensiunea tabelului de sortare este de cel puțin 40 de pagini, câte 8 kilobyte fiecare. De exemplu, pentru un index nepartizat partiționat, împărțit în 100 de secțiuni, veți avea nevoie de cantitatea de RAM pentru sortarea simultană a 4 000 de pagini (40 * 100). Dacă această cantitate de memorie este disponibilă, operația de creare va reuși, dar performanța poate suferi. Dacă această cantitate de memorie nu este disponibilă, operația de construire va eșua. Pentru un index aliniat partiționat împărțit în 100 de secțiuni, sunt necesare doar 40 de pagini pentru sortare, deoarece sortarea nu este efectuată simultan.

Ambele aliniate și nealiniate pentru indicii ar putea avea nevoie mai mult RAM în cazul în care SQL Server utilizează gradul de paralelism pentru a crea operare pe un calculator multiprocesor. Cu cât gradul de paralelism este mai mare, cu atât este nevoie de mai mult RAM. De exemplu, dacă SQL Server stabilește gradul de paralelism este 4, indicele partiționat nealiniate cu 100 sectiuni necesita o memorie la patru procesoare pot simultan un fel de 4000 de pagini, adică 16.000 de pagini. Dacă indexul partiționat este aliniat, cerințele RAM sunt reduse la 40 de pagini pentru fiecare dintre cele patru procesoare, adică 160 de pagini (4 * 40). Cu parametrul index MAXDOP, puteți reduce manual gradul de paralelism.

Comenzile DBCC

Cu mai multe secțiuni, execuția comenzilor DBCC poate dura mai mult pe măsură ce crește numărul de secțiuni.

Solicitările care utilizează funcția de eliminare a pieselor pot avea performanțe comparabile sau mai mari cu un număr mare de secțiuni. Întrebările care nu utilizează funcția de ștergere a secțiunilor pot dura mai mult cu creșterea numărului de secțiuni.

Să presupunem tabel are 100 de milioane de rânduri și coloane A. B și C. în exemplul din tabelul 1 este împărțit în 1000 secțiuni ale coloanei A. In exemplul din tabelul 2 este împărțit în secțiuni, în coloana 10,000 A. Tabelul Query cuprinde unde suma licitată filtrată prin coloană A. execută funcția de eliminare a secțiunilor și scanează o secțiune. Aceeași interogare poate fi executată mai repede în Exemplul 2, deoarece există mai puține linii de scanare în secțiune. O interogare care include o clauză WHERE cu un filtru în coloana B va scana toate secțiunile. În exemplul 1, această interogare poate fi executată mai repede decât în ​​exemplul 2, deoarece în acest caz există mai puține secțiuni pentru scanare.

Interogările care utilizează operatori, cum ar fi TOP sau MAX / MIN, altele decât cele care vizează împărțirea coloana coloanelor poate o performanță redusă atunci când partiționarea, deoarece toate secțiunile ar trebui să fie evaluate.







Articole similare

Pagina anterioară

Pagina următoare

Trimiteți-le prietenilor: