Se recomand ca fi ierele ce compun filegroupul primary (fi ierele .

mdf) s nu fie folosite pentru g zduirea obiectelor asupra c rora sunt aduse modific ri n mod repetat (tabele, indec i, etc.). Minimiznd procesele de scriere asupra acestor fi iere (care totodat definesc i starea bazei de date), se reduce riscul coruperii acestora n cazul ntreruperilor neprev zute sau din cauza problemelor hardware. Fi ierele cu extensia .ndf (secondary database file) sunt folosite n cazul optimiz rilor i vor g zdui tabelele i indec ii bazei de date. Fi ierele .ndf pot fi g zduite pe discuri diferite mbun t ind astfel timpii de r spuns ai SGBD-ului. Transaction log files (.ldf) sunt cunoscute ca fiind fi ierele asupra c rora MSSQL efectueaz scrieri secven iale. Se recomand ca aceste fi iere s fie izolate de fi ierele filegroupurilor primary & secondary. Decizia de a distribui baza de date pe mai multe fi iere (.mdf, .ndf, .ldf) este dictat n principal de estim ri referitoare la dimensiunea bazei de date, frecven a interog rilor, frecven a opera iilor de actualizare, etc. Nu consider c este gre it a crea o baz de date compus doar din dou fi iere (.mdf i .ldf), dar sus in ideea c n etapa de design a bazei de date este bine a organiza tabelele i indec ii pe mai multe filegroupuri astfel nct s oferim posibilitatea administratorului serverului de baze de date s distribuie fi ierele pe mai multe discuri.

n prima versiune, baza de date COMANDA este alc tuit din dou fi iere (.mdf i .ldf).

n a doua versiune, baza de date COMANDA este compus din mai multe fi iere .mdf, .ndf, .ldf.

A adar, n a doua versiune, baza de date COMANDA este organizat pe mai multe fi iere, iar tabelele i indec ii sunt grupa i pe filegroupuri separate (n func ie de dinamica nregistr rilor). La o astfel de organizare se poate ajunge chiar i plecnd de la o baz de date (aflat n produc ie) distribuit doar pe dou fi iere (.mdf i .ldf), ns n prealabil administratorul SGBD-ului va trebui s efectueze o analiz a structurii bazei de date. Pan n acest punct am vrut s subliniez cteva aspecte legate de modul de organizare al fi ierelor bazelor de date. Mai departe am s demonstrez beneficiile parti ion rii tabelelor. Am s evit pe ct de mult teoria (poate fi g sit pe MSDN, SQL Server Books Online, Training Kit, etc.) i am s m axez pe un exemplu concret. Baza de date COMANDA (219.30 MB) este populat astfel: y y y y y Agent: 305 nregistr ri (0.023 MB); Client: 306 nregistr ri (0.023 MB); Produs: 17 nregistr ri (0.008 MB); Comanda: 500 000 nregistr ri (84.992 MB); LinieComanda: 2 426 916 nregistr ri (127.258 MB);

n cazul n care dori i s urma i exemplul, pute i desc rca o copie a bazei de date, sau pute i popula baza de date cu ajutorul MSSQLDataPartitioning_02.sql (presupune existen a celei de-a doua versiuni a bazei de date COMANDA).

nainte de a efectua parti ionarea tabelelor Comanda i LinieComanda, am verificat viteza de execu ie a dou interog ri SQL. Fraza SELECT-SQL Interval execu ie (secunde) Totalul vnz rilor produselor comercializate n 2009 13 Totalul vnz rilor produselor comandate n 2009 7 Parti ionarea permite distribu ia unui tabel, index, index view pe mai multe filegroupuri, mp r irea efectundu-se pe baza unor reguli stabilite de administratorul SGBD-ului. n forma actual , tabelele Comanda i LinieComanda sunt g zduite de filegroupul SECONDARY2.

Datorit num rului relativ mare de nregistr ri al tabelelor Comanda i LinieComanda, ne propunem s efectu m parti ionarea pe baza anului n care comenzile au fost create.

Parti ionarea presupune: y y y Definirea unei func ii de par ionare prin intermediul c reia se definesc limitele de parti ionare; Definirea / stabilirea filegroupurilor folosite la parti ionare; Definirea schemei de parti ionare pe baza schemei de parti ionare vor fi specificate filegroupurile implicate n parti ionare precum i func ia de parti ionare pe baza c reia datele vor fi distribuite.

Avnd n vedere c n baza de date avem comenzi din anii 2008, 2009, 2010, vom crea o func ie de parti ionare ale c rei limite vor defini trei parti ii, parti ii ce vor fi mapate pe trei filegrupuri. Una, mai multe, sau chiar toate parti iile pot fi mapate pe un singur filegroup. n acest exemplu am decis ca fiecare parti ie s fie g zduit pe filegroupuri separate. Parti ionarea tabelei Comanda n cazul parti ion rii tabelei Comanda se va crea o func ie de parti ionare cu limitele incluse n parti ia din dreapta. Parti ionarea tabelei se va face n func ie de data la care comanda a fost creat (tip de date DATETIME2). MSSQLDataPartitioning_05.sql

Pe baza acestei func ii de parti ionare vom putea parti iona comenzile (nregistr rile) per ani. Deci conform acestei func ii: Parti ia num rul Minimum Maximum 1 0001-01-01 00:00.0000000 2008-12-31 23:59:59.9999999 2 2009-01-01 00:00.0000000 2009-12-31 23:59:59.9999999 3 2010-01-01 00:00.0000000 9999-12-31 23:59:59.9999999 sys.partition_range_values, sys.partition_functions, sys.partition_parameters, sys.types MSSQLDataPartitioning_06.sql

nainte de a crea schema de parti ionare (a defini cum anume se va face efectiv parti ionarea) este necesar a crea filegroupurile. Avnd n vedere c vor fi trei parti ii, am decis crearea a trei filegroupuri. MSSQLDataPartitioning_07.sql

sys.filegroups, sys.database_files MSSQLDataPartitioning_08.sql

Cre m schema de parti ionare. MSSQLDataPartitioning_09.sql

Deoarece tabela Comanda deja con ine nregistr ri va fi necesar recrearea indexului clustered pentru ca parti ionarea s se realizeze efectiv. nainte de a recrea indexul, haide i s vedem care este structura actual . MSSQLDataPartitioning_10.sql

A adar, tabela Comanda este nc g zduit de fi ierele ce compun filegroupul SECONDARY2. Dac ne uit m i la dimensiunea pe disc a fi ierelor COMANDA_SECONDARY3_DATA1.ndf, COMANDA_SECONDARY4_DATA1.ndf, COMANDA_SECONDARY5_DATA1.ndf vom observa c acestea au r mas la dimensiunea specificat n momentul cre rii lor (512 KB).

Dac vom recrea indexul clustered va trebui s avem urm toarea distribu ie. MSSQLDataPartitioning_11.sql

Deci conform rezultatului ob inut putem afirma c tabela Comenzi va fi parti ionat astfel: Parti ia num rul 1 2 3 Minimum 0001-01-01 00:00.0000000 2009-01-01 00:00.0000000 2010-01-01 00:00.0000000 Maximum 2008-12-31 23:59:59.9999999 2009-12-31 23:59:59.9999999 9999-12-31 23:59:59.9999999 Detalii 25000 de nregistr ri (ultima comand din an: 25000) 375000 de nregistr ri (ultima comand din an: 400000) 100000 de nregistr ri (ultima comand din an: 500000)

tergerea indexului clustered PK_Comanda. MSSQLDataPartitioning_12.sql

Una din condi iile unei chei primare este aceea de a nu con ine valori nule printre valorile sale. Conform comenzii DDL de creare a tabelei Comanda, indexul clustered era realizat pe baza valorilor atributului ce definea cheia primar (atributul CodComanda). n momentul n care se parti ioneaz o tabel , indexul clustered obligatoriu va avea n componen atributul pe baza c ruia se va face parti ionarea. Implicit un index clustered are o singur parti ie. Atunci cnd o tabel este mp r it pe mai multe parti ii, indexul clustered este la rndul s u parti ionat, fiecare parti ie avnd structura B-tree pentru datele din respectiva parti ie. n cazul nostru, atributul pe baza c ruia se efectueaz parti ionarea este DataComanda deci, indexul de tip clustered va trebui s aib n componen i acest atribut. Totu i, cheia primar trebuie s identifice n mod unic o nregistrare dintr-o tabel , iar atributul CodComanda este ideal n cazul tabelei Comanda (n plus de asta, ntre tabela Comanda i tabela LinieComanda este stabilit rela ia 1 - n). Deci, va trebui s redefinim cheia primar - dar de data aceasta vom avea grij ca indexul cheii primare s fie nonclustered. Indexul cheii primare l vom g zdui n filegroupul SECONDARY 2 (indexul nu va putea fi parti ionat deoarece nu are n componen a sa atributul DataComanda).

MSSQLDataPartitioning_13.sql

Indexul realizat n urma redefinirii cheii primare va avea o selectivitate ridicat - deci, n cazul opera iilor SELECT-SQL, SGBD-ul va prefera s se foloseasc de acest index (n special n cazul jonc iunilor cu tabela copil LinieComanda). Avnd n vedere c acest index nu l putem parti iona pe mai multe parti ii, se recomand g zduirea lui ntr-un filegroup dedicat (filegroup ale c rui fi iere s fie g zduite pe discuri cu performan e ridicate n privin a opera iunilor scriere/citire). Pentru acest exemplu am decis g zduirea lui n filegroupul SECONDARY2 (deoarece tabelele Comanda i LinieComanda vor fi parti ionate i vor "face loc", permi nd astfel s transform m filegroupul SECONDARY 2 ntr-un filegroup dedicat indec ilor). Urm torul pas const n crearea indexului clustered, moment n care va avea loc i mutarea datelor din filegroupul SECONDARY2 n filegroupurile schemei de parti ionare PartitionComanda (deci procesul de recreare a indexului va fi ceva mai costisitor n privin a consumului de resurse).

MSSQLDataPartitioning_14.sql

Am s fac o mic discu ie pe baza acestui index. Este evident de ce anume am ales atributul DataComanda n componen a indexului clustered, dar oare o combina ie de atribute (care s includ i atributul CodComanda) nu ar fi mai avantajoas ? R spuns: Depinde! Depinde foarte mult de scopul tabelei parti ionate, de tipul de opera ii care se execut asupra datelor respectivei tabele, de frecven a lor, etc. Indec ii mbun t esc considerabil accesul la date (SELECT-SQL), dar dac e s c dem n extrema cre rii multor indec i, eventual indexarea pe baza unui num r mare de atribute, etc., cu siguran vom reduce performan ele opera iunilor INSERT, UPDATE, DELETE, BULK INSERT, BCP. S presupunem c am fi ales combina ia de atribute CodComanda, DataComanda. MSSQLDataPartitioning_15.sql

Cel pu in pe baza frazelor SELECT SQL ale c ror performan a fost testat n cadrul acestui post, cu siguran acest index nu ar aduce niciun fel de imbun t iri interog rilor, asta deoarece indexul nonclustered PK_Comanda creat n urma redefinirii cheii primare va avea o selectivitate mai ridicat dect IDX_Comanda. Redefinim constrngerea referen ial FK_LinieComanda_Comanda (care am fost nevoi i s o tergem nainte de a redefini indexul clustered al tabelei Comanda). MSSQLDataPartitioning_16.sql

Vizualiz m modul n care tabela Comanda a fost parti ionat . MSSQLDataPartitioning_10.sql

Parti ionarea tabelei LinieComanda Inten ionat am ales aceast structur a tabelelor bazei de date - pentru u urin a exemplific rii i n elegerii, abordarea unor aspecte particulare, precum i discutarea cazurilor generale. Pn n acest punct am reu it de am parti ionat tabela Comanda (tabela p rinte tabelei LinieComanda). Logic ar fi s efectu m i parti ionarea tabelei LinieComanda astfel nct s respect m regula impus de la bun nceput (reorganizarea nregistr rilor per ani), ns atributele tabelei LinieComanda nu au n componen un atribut de leg tur cu Comanda.DataComanda. Totu i, dac ne uit m mai atent asupra modului de organizare a nregistr rilor din tabela LinieComanda, putem spune c nregistr rile sunt ordonate ascendent pe baza atributului LinieComanda.CodComanda - acest lucru se datoreaz faptului c ordinea de inserare a nregistr rilor din tabela LinieComanda coincide cu ordinea n care au fost inserate nregistr rile n tabela Comanda. Dac e s privim din punct de vedere tranzac ional, o comand (sub form de nregistr ri ale unei baze de date) ar fi compus : y y dintr-o nregistrare n tabela Comanda (nregistrare identificat prin CodComanda - valoare atribuit secven ial de SGBD); una sau mai multe nregistr ri n tabela LinieComanda (nregistr ri identificate prin combina ia de atribute CodComanda, CodProdus).

ntre DataComanda i CodComanda exist o rela ie dat de faptul c nregistr rile asociate comenzilor sunt introduse n ordine cronologic , iar atributul CodComanda este incrementat la fiecare nregistrare ad ugat .

Altfel spus, pe baza atributului DataComanda pot calcula ultima comand din an. Bingo! Pe baza ultimei comenzi din an voi putea defini func ia i schema pe baza c reia voi putea parti iona tabela LinieComanda.

MSSQLDataPartitioning_17.sql

Deci conform rezultatului ob inut putem afirma c tabela LinieComanda va fi parti ionat astfel: Parti ia num rul 1 2 3 Minimum 25000 9223372036854775808 25001 400001 Maximum Detalii

121427 de nregistr ri (corespunz toare comenzilor din 2008) 1819069 de nregistr ri (corespunz toare comenzilor din 400000 2009) 486420 de nregistr ri (corespunz toare comenzilor din 9223372036854775807 2010)

MSSQLDataPartitioning_18.sql

Vizualiz m modul n care tabela LinieComanda a fost parti ionat . MSSQLDataPartitioning_19.sql

Dup ce am efectuat parti ionarea celor dou tabele (Comanda i LinieComanda), am verificat din nou viteza de execu ie a celor dou interog ri SQL. Interval execu ie (secunde) Inainte de parti ionare Dupa parti ionare Totalul vnz rilor produselor comercializate n 2009 13 4 Totalul vnz rilor produselor comandate n 2009 7 3 Fraza SELECT-SQL Grafic, organizarea fi ierelor i tabelelor bazei de date COMANDA ar putea fi prezentat astfel:

10

Pentru a nu crea confuzie filegroupul SECONDARY2 g zduie te indexul PK_Comanda, dar n imaginea al turat este prezentat doar organizarea fi ierelor i tabelelor bazei de date COMANDA.

Extinderea schemei de parti ionare (exemplul 1) Schema de parti ionare poate fi modificat ulterior. n cele ce urmeaz am s prezint un prim exemplu de extindere a schemei de parti ionare. S prespunem c ne afl m n anul 2011 i dorim s cre m nc un filegroup pentru a stoca nregistr rile anului calendaristic 2011. MSSQLDataPartitioning_20.sql

11

S list m noile modific ri aduse parti iei PartitionComanda. MSSQLDataPartitioning_21.sql

ns nu este suficient doar a modifica schema de parti ionare. Pentru a salva nregistr rile din 2011 n filegroupul SECONDARY6, trebuie s modific m i func ia de parti ionare. MSSQLDataPartitioning_22.sql

List m noile modific ri aduse parti iei PartitionComanda. MSSQLDataPartitioning_21.sql

12

Conform listing-ului putem spune c noua parti ionare va ar ta astfel: Parti ia num rul Minimum Maximum 1 0001-01-01 00:00.0000000 2008-12-31 23:59:59.9999999 2 2009-01-01 00:00.0000000 2009-12-31 23:59:59.9999999 3 2010-01-01 00:00.0000000 2010-12-31 23:59:59.9999999 4 2011-01-01 00:00.0000000 9999-12-31 23:59:59.9999999 Trebuie s aducem modific ri i parti iei PartitionLinieComanda astfel nct nregistr rile asociate comenzilor din 2011 s fie salvate n filegroupul SECONDARY6. Lund n calcul c "ne afl m" n anul 2011 i avnd n vedere modul n care datele sunt salvate n tabela LinieComanda, putem calcula care este ultima comand din anul 2010, iar n func ie de valoarea ob inut se va modifica func ia de parti ionare PartitionLinieComandaByCodComanda. MSSQLDataPartitioning_23.sql

Deci, toate comenzile ale c ror CodComanda este mai mare de 500000 vor apar ine comenzilor create ncepnd cu anul 2011. MSSQLDataPartitioning_24.sql

13

S list m noile modific ri aduse schemei i func iei de parti ionare. MSSQLDataPartitioning_25.sql

Test m modific rile ad ugnd ceva nregistr ri pentru anul 2011. MSSQLDataPartitioning_26.sql

14

Verific m dac am efectuat parti ionarea a a cum ne-am propus. MSSQLDataPartitioning_27.sql

Extinderea schemei de parti ionare (exemplul 2) Din cauza num rului mare de comenzi nregistrate n perioada anului 2009, se ia decizia de a extinde schema de parti ionare (comenzile anului 2009 s fie distribuite pe dou parti ii).

MSSQLDataPartitioning_28.sql

15

Verific m dac am efectuat parti ionarea a a cum ne-am propus. MSSQLDataPartitioning_27.sql

Restrngerea schemei de parti ionare Se ia decizia de a unifica toate comenzile nregistrare n perioada anului 2009 ntr-o singur parti ie (a anula modific rile aduse n exemplul 2) MSSQLDataPartitioning_29.sql

16

Verific m dac am efectuat parti ionarea a a cum ne-am propus. MSSQLDataPartitioning_27.sql

Renun area la parti ionare Se ia decizia de a renun a la parti ionare i de a aduce datele la forma ini ial (mutarea tabelelor n filegroupul SECONDARY2). MSSQLDataPartitioning_30.sql

Recomand ri y y nainte de a efectua parti ionarea asigura i-v c ave i copii de siguran . nainte de a efectua parti ionarea trece i baza de date n SINGLE_USER (la final, dup parti ionare, trece i baza de date n modul MULTI_USER). Avnd baza de date n modul SINGLE_USER vom fi siguri c doar o singur conexiune poate fi ini iat cu respectiva baza de date (evident, respectiva conexiune va fi cea folosit de administratorul SGBD-ului i va fi folosit la parti ionare). Dac trebuie s defini i mai multe func ii de parti ionare, ncerca i s defini i toate func iile doar cu limit la stnga, sau doar cu limit la dreapta. Recomand acest lucru din simplul motiv c de foarte multe ori suntem nevoi i s parti ion m pe acelea i filegroupuri att tabele p rinte ct i tabele copil (asemeni exemplului nostru), iar atunci cnd schema este extins , s putem p stra sincronizarea (ex: nregistr rile tabelei Comanda din 2008 i nregistr rile LinieComanda din 2008 n acela i filegroup, nregistr rile tabelei Comanda din 2009 i nregistr rile LinieComanda din 2009 n acela i filegroup, etc.). Parti iona i tabelele cu un num r foarte mare de nregistr ri (sau cele care ve i ti c vor avea multe nregistr ri). Analiza i interog rile nainte de a ncepe parti ionarea. O solu ie ar fi analiza cache-ului. Dac v a tepta i la modific ri repetate asupra atributului pe baza c ruia s-a definit schema de parti ionare, se recomand alegerea unor intervale mai mari de parti ionare (intervale care s nu determine mutarea efectiv a datelor dintr-un filegroup n altul).

y y y

17