Tak neoman. Jeg søger altid i Google først. Første link var et jeg har besøgt og læst. Jeg synes ikke det står særligt klart nogle af stederne - det jeg har fået ud af det var:
Hvis du laver en shrink vil du kun fåor shrinket din filegroup, den bedste måde du kan gøre det på er at nedlægge dine indexes og oprette dem igen. Husk at starte med at oprette det clustered index først.
Jeg kan se indexsize er meget lille, har du fjernet nogle indexes?
Må jeg spørge hvorfor du vil forhindre det sker igen?
Hej Janus. Tak for tippet. Jeg vil overveje at benytte din metode med at fjerne og genoprette indexes (og så køre shrink?)
Jeg vil forhindre det sker igen, fordi jeg kun kan lave den slags operationer mellem 01:00 og 04:00 søndag morgen og der gider jeg ikke være på arbejde :)
Okay.. men årsagen til at MSSQL allokerer diskspace på den måde er pga. fragmenteringen. Dvs. du får rent faktisk en hurtigere tabel/ database ved at allokere diskplads fra starten.
Det værste man kan er at sætte autoshrink på databasen! Prøv evt. at bruge windows defragmenteringstool, find .mdf-filen og se hvor mange fragmenter den er på? Optimalt burde den være i 1 fragment, 2 eller 3 eller 4 kan også gå, men hvis du ser noget omkring 50-100 eller derover så skal du nok overveje at få det fixet pga. performance og voldsomme headmoves / seektime hver gang :-)
Jeg arbejder selv på en arbejdsplads med meget begrænset tid til den slags vedligeholdelse, så jeg kan sagtens følge dig hehe... Jeg har dog altid bare sagt at der mangler diskplads, netop pga. at MSSQL skal have plads for at performe godt + det altid er godt med ekstra plads in case of emergency, fyldt transactionlogs osv.
DB-Backuppen er på 18 fragmenter, men mdf-filen er ikke med i rapporten, så jeg går ud fra den er 2 eller under.
Hvis du mener 1,3 GB brugt og 6 GB fri i en tabel er sundt for databasen, vil jeg bare lade den blive på det og rutte med pladsen. Ingen pris er for høj for en velfungerende database. Men jeg så det bare ikke som noget sundhedstegn at den har SÅ store mængder ubrugt plads.
Ja det mener jeg er sundt, det er bedst at lade db'en styre sin egen fragmentering og det gøres bedst ved at give den noget plads. Jo flere fragmenter jo langsommere læsning, hver fragment svarer til en seektime. Jeg formoder du har formateret harddiskene med 64kb, så vil hver blok læses med 64kb, en page fylder ca. 8kb og der læses en extent ud af gangen. dvs worstcase og nu siger vi der er rigtigt mange fragmenter vil en extent kræve en seek... bliver pludselig voldsomt meget for at få nogle records frem. Nu er det kun transactionloggen der læses sekvential og hvor tit læses den ? - men det er bare lige for at ridse tingene lidt op.
Jeg arbejder til dagligt med terabyte-databaser og der skal nu ikke være meget rod i filsystemet førend det kan mærkes på performance :-)
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.