Welcome to Sign in | Help
in Search

Sfaturi "Best practices" pt trecere de la 1 file per filegroup la mai multe

Last post 04-10-2010, 3:23 AM by alexban. 4 replies.
Sort Posts: Previous Next
  •  04-08-2010, 2:01 PM 8177

    Huh? [:^)] Sfaturi "Best practices" pt trecere de la 1 file per filegroup la mai multe

    Salut,
    am sa încerc sa descriu cam ce vreau sa realizez și sper să ma fac inteles.

    Am un server SQL Enterprise Edition 64 bit cu o baza care în acest moment are 120GB intr-un singur fisier .mdf. Pentru ca aceasta baza de date "sta" pe un storage conectat prin fc si am la dispozitie pana la 24 discuri SAS de 15krpm pt ea si mai ales pentru ca estimez o creștere intre 70% si 100% / an as vrea sa împart cât mai bine IO-urile pe cât mai multe discuri. M-am gândit că ar exista 2 variante care le-aş putea încerca:

    1. sa adaug la filegroup-ul default inca n files (pentru tempdb stiu ca se recomanda cate un file per procesor logic) si sa sper ca SQL va uniformiza cumva fisierele să ajungă de dimensiuni egale. Binenteles, fiecare disc virtual (array raid) va fi format din aceleasi nr de discuri fizice si va avea aceiasi dimensiune. Sincer sa fiu nu-mi dau seama cum as putea realiza asa ceva. Am sperat ca daca imi creez o baza noua cu layout-ul care-l doresc și dau restore la un backup totul va fi asa cum vreau eu dar din păcate nu a mers.

    2. sa adaug la filegroup-ul default încă n files și să mut MANUAL tabelele care consider eu ca sunt mai mari/accesate

    Pentru ca nu cunosc foarte bine structura datelor din baza de date (e pt Microsoft Dynamics AX) as incerca (cel putin pt inceput) varianta 1. Intrebarea principala e daca mai adaug cateva files (.ndf) la filegroup-il principal, SQL Server va scrie in aceste noi files pana le va uniformiza ca dimensiune cu fisierul intial (.mdf) sau va scrie in mod round robin si voi avea fisierul .mdf imens pe langa ndf-uri? Daca da, care e cea mai buna metoda sa le uniformizez ca dimensiune? Mai aveți sfaturi gen "best practices" de care ar trebui să țin cont?

    Alexban
    Filed under: ,
  •  04-08-2010, 3:38 PM 8179 in reply to 8178

    Re: Sfaturi "Best practices" pt trecere de la 1 file per filegroup la mai multe

    merci pt RTFM! celele legate de storage le-am citit si paracitit; am facut sute daca nu mii de teste cu SQLIO.
    desi speram o "mura" sunt constient ca trebuie sa inteleg ce fac asa ca o sa-mi fac timp si ma pun pe citit.
    Daca totusi cineva e binevoitor cu cateva hint-uri nu m-ar deranja deloc :)

    merci,
    Alexban
  •  04-10-2010, 1:20 AM 8184 in reply to 8177

    Re: Sfaturi "Best practices" pt trecere de la 1 file per filegroup la mai multe

    Cind ai N file-uri intr-un filegroup SQL va distribui *alocarile* in mod balansat astfel incit fiecare file sa fie la fel de incarcat, proportional. Deci daca ai un file de 30GB care e full 33%, unul de 20GB  care e full 100% si unul de 10GB care e gol si *aloci* 100 de extent-uri (adica cite 8 pagini), ele vor fi alocate proportional cu *spatiul gol* in fiecare file: 67 de alocatii se duce la primul file (care are 20GB liberi) si 33 de alocatii se duc la al treilea (care are 10GB liber).

    Daca creezi o baza de date initiala cu N fieisere egale goale, atunci in mod normal ele se for 'umple' egal in timp.

    De retinut ca 'balansarea' se intimpla doar cind pagini sint *alocate*, deci daca pur si simplu adaugi fisiere nu se va intimpla nimic, initital. In timp se vor umple si balansa, dar initial nu vei vedea nici un efect.

    Ce poti face este:

    1) pui toate 24 de discuri in RAID 10 (12 raid 0 + 12 raid 0 si raid 1 intre cele doua), prezinti la SQL un singur volum si muti MDF-ul pe el. IO va fi stripped intre 12 discuri, si raid 1 it-i va da redundanta. 

    2) pui toate 24 de discuri in RAID10   (cite 2 in raid 1, si un raid 0 peste cele 12 perechi). Similar cu 1), dar este mai usor sa inlocuiesti un disk care face kaboom. Copiezi MDF-ul de 120 Gb pe acest volum, done.

    3) Daca vrei totusi sa imparti I/O-ul prin multiple-files poti sa adaugi un nou filegroup DATA, cu N file-uri egale. Apoi copiezi toate tabelele in DATA (ALTER TABLE ... MOVE TO ...). Apoi shrink PRIMARY filegroup, rezultatul este ca toate datele au fost mutate in alt fielgroup si sa-u balansat intre cele N files.

    4) muti tabelele individual, in functie de ce I/O te astepti.

    Cel mai usor este 1) sau 2). Pentru 4) trebuie sa intelegi bine aplicatia, si sa urmaresti statsitici per rowset (sys.dm_db_index_physical_stats, sys.dm_db_index_usage_stats). 3) este relativ simplu, dar resultatul este la fel ca 1) sau 2), doar ca trebuie/poti controla mai precis ce fisier se duce pe ce volum.

    In principiu mai poti face si sa adaugi N file-uri la PRIMARY si apoi sa faci ALTER INDEX ... ALL ... REBUILD la toate tabele, astfel incit sa se distribuie pe toate fisierele, dar n-as recomanda asta.

    Mai sint si alti factori care pot sa influenteze decizia:

     - vrei sa poti sa faci piece-meal restore? http://msdn.microsoft.com/en-us/library/ms177425.aspx. Trebuie filegroup-uri separate.
     - vrei sa folosesti partitioning si un sliding-window? http://msdn.microsoft.com/en-us/library/aa964122%28SQL.90%29.aspx. *Probabil* ca ai nevoie de filegrou-uri (nu e neaparat nevoie).
     - o sa adaugi o solutie de high-availability, gen Mirroring? gindeste-te cum reproduci in stand-by configuratia fizica din principal (aceleasi volume, aceleasi file path-uri etc)


    http://rusanu.com
  •  04-10-2010, 3:23 AM 8185 in reply to 8184

    Re: Sfaturi "Best practices" pt trecere de la 1 file per filegroup la mai multe

    In primul rand multumesc frumos pt acest raspuns "mura in gura"

    La ce-a de a 2-a varianta m-am gandit si eu (prima e practic un RAID 01) dar am vazut in documentatia storage-ului ca se recomanda ca maxim 12 discuri sa fie asignate per controller. Chiar am vazut niste teste in care se arata ca daca sporesti nr de discuri in raid 10 peste  10-12, cresterile de IOPS sunt destul de mici si e mult mai rentabil sa faci 2 array-uri.
    M-am mai gandit si ca in viitor s-ar putea sa nu mai fie suficiente 20 discuri in RAID 10 (4 vreau sa le folosesc in RAID 10 pt log) si atunci va trebui sa mai adaug niste discuri de pe alt storage dar am realizat ca daca nu aloc de acum fisiere suficiente (ma gandeam la 4) voi avea aceiasi problema ca acum.
    Varianta 2 m-ar avantaja si prin prisma faptului ca vreau sa folosesc functiile storage-ului de snapshot sau volume copy (pot creea foarte rapid un duplicat al bazei de date (snapshot-ul este instantaneu) pt a fi utilizat drept baza de test) si cu cat am mai putine volume cu atat este mai simplu.
    Saptamana viitoare ar trebui sa primesc noul storage (identic cu cel actual) si voi putea face linistit teste cu SQLIO ca sa ma decid daca merg pe varianta 2 sau 3.

    O zi buna,
    Alex
View as RSS news feed in XML
Powered by Community Server (Commercial Edition), by Telligent Systems