Defragmentering fysisk disk vs. databaser

Ja det gør du, men hvor ofte du bør gøre det afhænger af hvor mange bevægelser du har ind og ud af databaserne. Problemet ligger i at nogle af de nødvendige defragmenteringer kræver at databasen tages offline, eller de belaster serveren sådan at tilgang til databasen nærmest dør. Du bør derfor designe din vedligeholdelse således at du defragmentere ofte nok til at basen kører problemløst og sjældent nok til at denne vedligeholdelse ikke genere brugerne.
Generelt skal du overveje følgende:
Jo mere fragmenteret diske og baser er, jo længere tid tager det at defrage
jo mere fragmenteret diske og baser er jo større er sandsyneligheden for at noget går galt.

Om den indbyggede defragmentering er god nok af hvilke baser vi taler om. Du skal huske at der er andre applikationer en SQL der bruger databaser, f.eks. anvender exchange jet databaser og disse bør defragges. En del af MS applikationerne har defrag utils liggende i resource kittene og disse er udemærkede. Jeg bruger selv kun de medfølgende, dvs. dem der findes i de enkelte programmer samt i resource kit.

Du bør bestemt defrage på logisk niveay, det er faktisk ofte mere vigtigt end på fysisk niveau. Husk at på en dedikeret databaseserver vil der ofte være meget lidt bevægelse på det fysiske niveau andet end at databasen bliver større fordi der er bevægelser på det logiske niveau. Den logiske rækkefølge er defrag logisk først, herefter defragges fysisk. Defrag logisk ofte (relativt) og defrag fysisk sjældent (relativt)

Den bedste måde er det bedste komprommis du kan opnå. Jeg genemføre min vedligeholdelse i faste intervaller med nogle defrag ugentligt, andre månedligt og andre igen kun en gang om året, lav det bedste komrpomis efter hvor meget dine baser bevæger sig.

Husk at der er anden vedligeholdelse end defrag, ofte kan du også konsistens og integritets kontrollere dine baser, Kik i de forskellige resource kits og søg på maintanance i http://www.microsoft.com/technet for at finde beskrivelser afhvordan dette gennemføres og læg derefter en fastplan

til seriøs brug kører du vel med fast støtrrelse på dine database filer

så hvis de er lavet contigious så forbliver de contigious

databasen skal naturligvis være lukket helt ned når du defragmenterer

så vidt jeg ved er standard windows defragger ikke i stand til at lave
en fil contigious

men sysinternals har en lille gratis utility som kan gøre det

at hold databaserne internt contigious er er kunst

det kræver at du har mange database filer og en smart fordeling af data på dem

jeg har engang overtaget en database (ikke SQLServer men princippet må
være det samme) som var opdelt på ca. 90 filer

du kan naturligvis defragmentere ved at dumpe og loade data

Du kan finde ud af om du behøver at defragmentere dine datafiler ved at klikke på det/ de pågældende diskdrev og vælge properties -> tools -> defragment now og vælge at se report. Hvis dine datafiler er splittet op i for mange filer bør du nok overveje en defrag... Du kan som sagt vælge at lukke databasen ned og så defragge den pågældende datafile en anden måde er at defragge det tilgængelige space du har. Når det så er sket så opretter du en ny database og vælger at allokere tilpas meget diskspace til datafilen og transactionfilen, herefter kopierer du hele db'en evt. vha DTS eller lign. Du skal vide at når du først engang har allokeret diskspace til en datafil skal du aldrig defragge den, man ser tit at folk uden nogen forstand på databaser opretter en database på 1MB og sætter den til autogrowth 10% - hvilket er det dummeste man overhovedet kan gøre :-) Jeg stod engang overfor en database som var defragget i små 5000 enheder, ikke særligt optimalt haha.

Mht. DBSHOWCONTIG ja her er det jo også vigtigt at dine indexes er up2date, herved mener jeg at der jo som oftest forekommer pagesplits i indexet, du skal huske at køre en reindexing på dine databaser engang imellem. Jeg har altid sat søndagen af til den slags, men forsøg at passe det ind der hvor adgangen er begrænset.

Noget helt andet som du måske burde overveje for performance var en ændring af dit RAID. Raid5 er god til læsning men ikke så god til skrivning. Og bruge Raid5 til transactionslog er ikke det fedeste, brug evt. Raid1 eller måske Raid0+1 (1+0). Vær endvidere opmærksom på at transactionslogskrivning er sekventiel og dataskrivning og læsning er random... Dvs. små søgetider til datafiler og hurtig skrivning til transactionslog. Hvis din disktime nogle gange peaker på 100% burde du måske overveje at par spindler mere - nu kender jeg jo ikke jeres budget og hvor mange diske der i forvejen sidder i jeres Raid.

Håber det gav dig lidt bedre indsigt.

også et svar fra mig