Welcome to Sign in | Help
in Search

Fragmentare disk

Last post 09-13-2010, 11:05 PM by sageata2002. 5 replies.
Sort Posts: Previous Next
  •  08-04-2010, 5:22 PM 8381

    Fragmentare disk

    Am un SQL Server 2008 care e pe o masina virtuala... Performanta s-a degradat destul de mult si am inceput sa ma uit de ce.
    Baza de date e de vreo 50 000 inregistrari (3 GB pe disk) si query pe ea sint simple fara joins sau asa. In principal se scrie mult si des in ea, vreo 6000 inserts pe zi. I-am dat si un shrink...
    Am observat ca hardisk e defragmentat la modu urit, practic totul defragmentat si cu erori din alea de depasit 15 ms la IO pe Temp...
    Dupa Defrag a inceput sa mearga mai bine, dar mai trebuie (pot) sa fac ceva in SQL? Un DBCC ceva Smile? Care din ele ?

    Multumesc!

     

    Filed under: , ,
  •  08-04-2010, 8:49 PM 8382 in reply to 8381

    Re: Fragmentare disk

    Defragmentatul e OK. E bine si daca poti opri serviciul SQL si defragmenta.
    Alte aplicatii exista pe masina? Antivirus? Virusi? :)
    Cand ai observat degradarea de performanta? Ce s-a intamplat imediat inainte?
    M-as uita in log-uri - de Windows (System, Application, Security) si de SQL.
    Vezi ce fel de "waits" ai pe masina:
    http://www.mssqltips.com/tip.asp?tip=1949
    http://www.mssqltips.com/tip.asp?tip=1853 (---> tempdb)
    Despre "waits" - aici:
    http://sqlcat.com/whitepapers/archive/2007/11/19/sql-server-2005-waits-and-queues.aspx
    As incerca sa vad care sunt cele mai lente query-uri. Vezi daca indexarea e OK.Poti face asta cu un server side trace in timpul orelor de varf dar si cu query-ul de aici
    http://www.sql-server-performance.com/articles/per/tsql_statement_performance_p1.aspx
    Statisticile sunt "up to date"?
    M-as uita in "activity monitor" (righ click pe server ---> Activity Monitor) la "recent expensive queries".
    Ce "spune" planul de executie al fiecarui query lent?
    E bine sa rulezi periodic (in functie de mediul de lucru) DBCC CHECKDB. E bine sa ai un backup "curat" la indemana.
    Daca exista un "baseline" al unor counteri din Perfmon, ruleaza din nou counter log-ul si vezi ce s-a schimbat in rau.
    Inca un whitepaper: http://technet.microsoft.com/en-us/library/cc966413.aspx.
    Raspunsul e foarte general, ca si intrebarea ta :)
  •  08-05-2010, 2:37 PM 8384 in reply to 8382

    Re: Fragmentare disk

    Multumesc!

    Dar, vad ca am fost clar ca de obicei.
    Baza de date are o tabela stil ID (indexat) col 1- 20. 90% de operare sint inserturi in ea. Restul sint Select ID, etc ORDER BY ID desc. E un soi de logging pentru un hard ciudat.
    In event viewer apar din astea "SQL Server has encountered x occurrence(s) of I/O requests taking longer than 15 seconds to complete on file ... tempdb" nu am pomenit de mesajul de eroare complet ca gogu m-a facut sa cred ca sint tare raspindite. Pe net raspunsurile sint generale rau, acces IO memorie si din astea, dar vorbim de o masina virtuala, si s-a avut grija de astea (sau s-a avut grija de the usual suspects).
    Alta manifestare, cind am vazut ca merge rau, cind incercai din SQL Manager sa rulezi un query, toate inserts ieseau pe timeout.
    CheckDB rulat, baseline de counteri nu e, dar sint in limitele sugerate la trubleshooting eroare cu 15 sec.
    Vorba aia ne-am uitat in locurile obisnuite avem imbunatiri da inca nu e nirvana. Si la fel nu stiu cum sa abordez defrag (SQL oprit nu prea e o optiune hard ala a bussines critical 24/7), in afara de defrag din OS.
    Si deci sintem in cautare de idei si sugestii.

    Multumesc!

     

     

  •  08-05-2010, 3:25 PM 8385 in reply to 8384

    Re: Fragmentare disk

    Cum stai cu fragmentarea indecsilor?
    http://technet.microsoft.com/en-us/library/ms189858.aspx
    Ruleaza scriptul din exemplul lor si vezi.
    In functie de rezultat, poate fi nevoie de "reorganize" sau "rebuild".
    M-as uita si la planul de executie al query-urilor lente. In SQL 2008 poti vedea mai repede daca lipseste un index - in partea de sus a planului de executie grafic ("missing index").
  •  08-13-2010, 9:50 AM 8393 in reply to 8384

    Re: Fragmentare disk

    Verifica gradul de fragmentare al indecsilor. Daca este ridicat(>50%) ruleaza un Rebuild pe toti indecsii. Daca este sub 50% ruleaza Reorganize+Update Statistics. Pentru Rebuild nu e necesar a rula Update statisctics, intrucat se face implicit. Daca dupa aceasta mentenanta(Rebuild sau Reorganize+Update Stats) fenomenul se repeta relativ repede, cauza este modul de creare al indecsilor. Pentru baze de date in care ponderea insert/update/delete e mare, trebui ca indecsii sa fie creati cu un 'fill factor' de 50-60%. Spatiul ocupat de baza de date va creste ceva, dar nu va mai apare fenomenul de 'Split', iar fragmentarea indecsilor va apare mult mai tarziu. By default la crearea unui index 'Fill factor'=100(sau 0 e acelasi lucru). Obligatoriu, planurile de mentenanta trebuie sa contina operatiuni de Rebuild si/sau Reorganize+Update Statistics o data pe zi sau macar saptamanal. Un 'Update statisctics' ar trebui rulat independent, zilnic. Indecsii puternic fragmentati, statisticile neactualizate pot favoriza decizia ca sql server sa fie nevoit sa isi refaca singur statistica(autoupdate statistics=on by default) in momentul in care se incearca rularea unui plan de executie...chiar gasit in cache. Deasemenea, sql-ul poate lua singur decizia de a nu folosi indecsii(daca acestia sunt puternic fragmentati si statisticile sunt prea vechi pentru a fi folosite) si a face un 'full scan' pe tabela ceea ce face sa creasca timpul de raspuns foarte tare-de unde si 'connection timeout'. Daca exista indecsi creati, acestia trebuie periodic intretinuti pentru a fi intradevar utili. Trebuie avut in vedere ca operatiunile de Rebuild si Reorganize sunt puternic consumatoare de fiser de log....adica acesta creste binisor. Daca 'Recovery Model' este in full, vor mai fi necesare ulterior operatiuni de shrink-uire a log-ului(backup log+shrink log repetat de cel putin doua ori)
    Defrag-ul din Windows(al S.O.) odata rulat, iti strica toate statisticile sql! Este bine a fi rulat, dar dupa aceea este obilgatoriu sa faci mentenanta sql, adica Rebuild/Reorganize+Update Stats urmat daca e cazul de shrink-uire
  •  09-13-2010, 11:05 PM 8430 in reply to 8384

    Re: Fragmentare disk

    Salut.

    Iti mai recomand o singura chestie, lasand la o parte ce au sugerat deja colegii mei: in secpol.msc, local policies, user rights assignments, ai grija ca serviciul tau de SQL sa aiba drept de "lock pages in memory" si "perform volume maintenance tasks". Asta evident, daca nu rulezi serviciul de SQL sub "local system account".
    Cat despre baza ta de date, daca ai un identity cu autoincrement (primary key, clustered index), si ai inserturi, jur ca nu vad de unde poti avea indecsi fragmentati:-)

    toate cele bune,
    calin
View as RSS news feed in XML
Powered by Community Server (Commercial Edition), by Telligent Systems