Avatar billede gyxi Nybegynder
28. juni 2007 - 10:42 Der er 7 kommentarer og
1 løsning

Meget unused space i tabel

Jeg har anvendt sp_spaceused på en tabel og resultatet er skræmmende:

Rows    Reserved    Data          Index size  Unused
34523  7472184 KB  1304384 KB    2152 KB      6165648 KB

Ret mig hvis jeg tager fejl, men ovenstående viser jeg har en tabel som fylder 7,5 GB og jeg anvender kun 1,3 GB. Resten er "Unused".

Jeg har ikke slettet store mængder data i tabellen.

1. Hvordan får jeg frigjort de 6 GB?
2. Hvordan forhindrer jeg det sker igen?
Avatar billede neoman Novice
28. juni 2007 - 22:58 #1
smid "unused space ms sql" ind i google - de første 2-3 links har vist en løsning på dit problem
Avatar billede gyxi Nybegynder
29. juni 2007 - 08:58 #2
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:

- Kør DBCC DBREINDEX
- Shrink

Er det korrekt?
Avatar billede janus_007 Nybegynder
02. juli 2007 - 02:02 #3
Hey

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?
Avatar billede gyxi Nybegynder
02. juli 2007 - 08:27 #4
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 :)
Avatar billede janus_007 Nybegynder
02. juli 2007 - 22:01 #5
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.
Avatar billede gyxi Nybegynder
02. juli 2007 - 22:26 #6
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.
Avatar billede janus_007 Nybegynder
13. juli 2007 - 00:20 #7
Sorry for mit sene svar.. ferie *S*

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 :-)
Avatar billede gyxi Nybegynder
13. juli 2007 - 09:02 #8
Mange tak for kyndig vejledning!
Avatar billede Ny bruger Nybegynder

Din løsning...

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.

Loading billede Opret Preview
Kategori
Computerworld tilbyder specialiserede kurser i database-management

Log ind eller opret profil

Hov!

For at kunne deltage på Computerworld Eksperten skal du være logget ind.

Det er heldigvis nemt at oprette en bruger: Det tager to minutter og du kan vælge at bruge enten e-mail, Facebook eller Google som login.

Du kan også logge ind via nedenstående tjenester