Avatar billede emkay Nybegynder
21. november 2006 - 15:08 Der er 4 kommentarer og
2 løsninger

Størrelse på DB - en masse brugte MB jeg ikke kender til?

Halløw

Vi har en database hvor vi har adgang til at have 250 MB liggende. Jeg har så lavet en side, der tæller sammen på alle tabellerne, for at finde ud af hvad der fylder mest og hvor meget vi bruger osv.
Siden kan ses her:
http://www.ungerneonline.dk/admin/dbsize_snapshot.html

Alle tallene bliver hentet via den Stored Procedure, der hedder sp_spaceused. Dokumentation til den kan findes her: http://msdn2.microsoft.com/en-us/library/ms188776.aspx

Nu er mit spørgsmål bare hvorfor "Size of the current database in megabytes" på 212.94 MB ikke passer med den sammentælling jeg får når jeg lægger størrelsen af alle tabellerne sammen (39.240 KB)??

Det passer hvis man trækker de 172.02 MB fra, men hvad er disse 172 MB? Som jeg ser det er det ikke noget vi bruger til noget, da det jo ikke er indhold i nogen af tabellerne, så betaler vi egentlig for 172 MB vi ikke har brug for eller hvad? For hvis vi egentlig kun bruger lige knap 40 MB kunne vi jo sagtens nedgradere størrelsen fra 250 til 100 MB og stadig have lang tid til den er fyldt op.

Håber nogen kan hjælpe :o)

På forhånd tak

M
Avatar billede teepee Nybegynder
21. november 2006 - 16:00 #1
For det første kører databasen med en fillfactor, så der gøres plads til flere informationer i hver række ved updates. Denne kan f.eks. stå på 90%, så der er lidt ekstra plads i hver række. Dette gør at data ikke altid skal flyttes til andre blokke ved updates. Dernæst allokres typisk en klump af data ad gangen, således at man ikke bare tager den plads man skal bruger hvergang der indsættes en række. Det ville være for besværligt. Hvis du sletter en masse data kan du ikke regne med at denne plads fjernes fra databsen, altså kan sletninger medføre meget tomt plads i basen. Jeg vil dog sige at det kan ikke være rigitgt at du skal betale for tom plads, da din administrator kan automatisere at tom plads fjernes.
Avatar billede janus_007 Nybegynder
21. november 2006 - 20:41 #2
Hej emkay
Kan du ikke poste den procedure du har lavet for at finde alle tabellerne og indsættelse af disse i outputtet? Det kan måske være der fejlen skal findes også...

Du skriver:
Size of the current database in megabytes. database_size includes both data and log files: 212.94 MB

Space in the database that has not been reserved for database objects: 172.02 MB

Hvor kommer disse tal fra?

har du lavet EXEC sp_spaceused @updateusage = 'true'

Jeg kunne godt tænke mig at hvad sp_spaceused spytter retur?

teepee -> Du har lidt ret i det du skriver, dog vil en fillfactor blive medregnet i indexsize. SQLServer 2000 reserverer extents, en extent ad gangen og sådan en fidus fylder 64KByte. Såvidt jeg husker foretager SQL2000 selv en oprydning af used space  når objektet bruger mindre end 128 extents = 128 * 64kb = 8192kb
Avatar billede emkay Nybegynder
22. november 2006 - 09:40 #3
>>teepee
Det lyder jo som om det kunne være en forklaring. Men det med at min administrator kan automatisere at al tom plads fjernes er de ikke helt enige i. Før jeg skrev indlægget i går snakkede jeg med dem og de gjorde udtryk for at det ikke var deres problem hvad vi havde liggende i databasen. Jeg forsøgte at forklare dem at jeg ikke anede hvad de 172 MB var og om de ikke kunne rydde op eller noget, men det eneste jeg fik ud af det var at log-filerne skrumpede med en enkelt MB.. Er der noget specielt man kan sige til dem, der måske kan hjælpe dem eller noget?

>>janus_007
Begge tallene bliver hentet via sp_spaceused. 212.94 er den der hedder "database_size" og 172.02 er den der hedder "unallocated space". Jeg har hentet beskrivelserne fra MS's dokumentation her: http://msdn2.microsoft.com/en-us/library/ms188776.aspx

http://www.ungerneonline.dk/admin/dbsize_snapshot.html har jeg nu lavet en textbox med den kode jeg bruger til at få alle tallene frem.
Avatar billede teepee Nybegynder
22. november 2006 - 11:08 #4
SQL server har det med at bruge rigeligt med plads, og under normale omstændighder er det ikke et problem. men når du ligefrem skal betale for pladsen, så burde din leverandørmåske overveje at opmåle pladsen på en anden måde, hvis ikke at de kan fjerne ubrugt plads. Du vil aldrig få fjernet alt, men hvis du rent faktisk bruger under 1/5 af pladsen så er det frådseri med pladsen. Det kan dog være at de ikke kan gøre den mindre pga. størrelsen af basen i sig selv er ret lille. Den neste måde er i så fald at backe up, droppe og restore basen igen, men det er for besværligt. Du skal dog stå fast på at det ikke er dig der bruger pladsen ;-)
Avatar billede emkay Nybegynder
22. november 2006 - 14:51 #5
Hmm.. De bliver ved med at sige at vi skal truncate vores tabeller.. Men betyder det ikke at vi sletter ALT i dem og ikke kun det overhead der er lavet?
Avatar billede janus_007 Nybegynder
22. november 2006 - 21:57 #6
Jo man kan sq ikke truncate en tabel uden at indholdet forsvinder, sikke en gang sludder at fyre af.
Hvis du også skal betale for transactionslog størrelsen og de siger at de kun kan skrumpe den en enkelt mb er det fordi deres administrator er en klovn :-)

Jeg giver teepee ret i du skal holde på at det er deres problem og ikke dit at frigøre pladsen. Ellers må du bede om en detaljeret opgørelse over hvad der optager pladsen og så tage det derfra med dem, det lyder lidt underligt det her :-)

Det er naturligvis klart at hvis der står i kontrakten at du skal betale for den allokerede plads og ikke den aktive plads, vil de have ret i deres krav!
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