[SQL Server] Harddisk gebruik van database opvragen *

[Jaspertje]

Morge allemaal,

Het probleem is, dat ik graag wil weten hoeveel MB/Gb mijn SQL Server inneemt op de server. Dan bedoel ik niet de Applicatie zelf maar de records in de database. En dit moet ook online te zien zijn. Ik heb geen flauw idee of het mogelijk is. Ik kom veel artikelen tegen over geheugen gebruik van de SQL Server en veel met de profiler. Maar dat gaat allemaal niet over wat ik wil, of kan ik niet gebruiken.

Mijn vraag is dus: Is het mogelijk om de grootte van een aantal records uit te lezen met SQL ism Delphi of ASP? en zo ja, waar heb je dat gevonden zodat ik er ook eens naar kan kijken..

offtopic:
Ik weet niet helemaal of dit beter in PW past of in SW/WOS.. maar hier kom ik meer dus vandaar in PW geplaats

[gorgi_19]

De grootte kan je in ieder geval opvragen in Enterprise Manager, properties van een database en dan staat de grootte in het tabblad General.

Online: geen idee.. Je kan eens kijken in BO naar sp_helpdb.

[ Voor 12% gewijzigd door gorgi_19 op 16-12-2003 11:32 ]

[whoami]

Als je weet hoeveel records je hebt zitten in een tabel, en welke datatypes de velden in die records hebben, dan kan je wel een redelijke schatting maken.

grootte tabel = aantal_records * ( aantal bytes veld1 + aantal bytes veld2 + .... )

Als je met varchar velden werkt, dan zal je moeten gaan schatten, aangezien de resterende ruimte in een varchar veld niet opgeslagen wordt.

Als je weet welke files je DB gebruikt (primary data files (*.mdf), secundary data files (*.ndf) en logfiles (*.ldf), kan je ook de grootte van die files gaan uitlezen.

[ Voor 19% gewijzigd door whoami op 16-12-2003 11:33 ]

[VisionMaster]

Ja ... dit kan je alleen vinden bij de info. van je database.
Want zulke functies zijn (uiteraard) niet opgenomen in de standaard SQL functies.

Ik zie het een beetje als een "show tables" commando die je kan versturen naar de database. Dit kan je via de SQL Command/Query regel doen en je krijgt een standaard ResultSet terug met je info.
Zulke administrative info kan je ook krijgen uit je database. Je moet alleen de juiste internal tables aanspreken met de gewenste velden.
Je gewenste info staat niet in iedere simpele FAQ (naar mijn idee).
suc6

[curry684]

SQL Server definieert een enorme stapel constantes waar je dit soort velden uit kunt lezen, ik meen voor dit soort groottes wel iets tegengekomen te zijn in de Guru's Guide to T-SQL... zal vanavond eens kijken als ik er aan denk

[VisionMaster]

whoami schreef op 16 december 2003 @ 11:32:
Als je weet hoeveel records je hebt zitten in een tabel, en welke datatypes de velden in die records hebben, dan kan je wel een redelijke schatting maken.

grootte tabel = aantal_records * ( aantal bytes veld1 + aantal bytes veld2 + .... )

Als je met varchar velden werkt, dan zal je moeten gaan schatten, aangezien de resterende ruimte in een varchar veld niet opgeslagen wordt.

Dit is een hele slechte benadering imho, omdat database BLOB (and family), VARCHAR (and family) en nog een zwik andere type comprimeert
Op deze manier zou je ten eerste een best wel pittige berekening hebben die (bij meer dan 10 goed gevulde tabellen) toch wel eventjes duurt => lijkt me niet gewenst. En ten tweede komt je benadering neer op je maximum beschikbare capaciteit in de gebruikte record, dat bij BLOB velden dus 2 gigabyte aan potentiele omvang kan bedragen

[curry684]

VisionMaster schreef op 16 december 2003 @ 11:32:
Ja ... dit kan je alleen vinden bij de info. van je database.
Want zulke functies zijn (uiteraard) niet opgenomen in de standaard SQL functies.
[...]
Zulke administrative info kan je ook krijgen uit je database. Je moet alleen de juiste internal tables aanspreken met de gewenste velden.

Echter, als je weet dat je tegen SQLServer aanpraat kun je gebruik maken van de volledige TransactSQL set die stukken rijker is dan ANSI-SQL92. Gebruik van internal tables wordt in principe altijd afgeraden daar die rustig in de volgende SQL Server niet meer kunnen werken, en dan zou je dus in de T-SQL met een case op @@VERSION moeten gaan werken om de goede resultaten te retourneren (nul future-compatibility dus).

[gorgi_19]

VisionMaster schreef op 16 december 2003 @ 11:32:
Ja ... dit kan je alleen vinden bij de info. van je database.
Want zulke functies zijn (uiteraard) niet opgenomen in de standaard SQL functies.

net getest, en ik vind dat sp_helpdb toch wel een redelijke benadering geeft van de databasegrootte..

[whoami]

Ik zit net te denken:
Volgens mij kan je nooit de exacte grootte van de databank weten, aangezien je een aantal MB/GB space gaat gaan alloceren die Sql Server mag gebruiken.
Als die ruimte opgebruikt is, gaat ie automatisch z'n beschikbare ruimte gaan vergroten met het percentage of het aantal MB dat je opgegeven hebt bij de creatie van je DB.

[Jaspertje]

ik zal sp_helpdb eens gaan bekijken..

Wat whoami zegt klopt idd, je reserveert altijd ruimte voor de SQL Server.. Maar ik denk dat het probleem wat ik heb niet opgelost kan worden op een zuivere manier, selecteerd eerst records kijk dan hoe groot dat samen is.

Mocht ik iets vinden, dan laat ik het weten.

[Jaspertje]

Net gevonden:

exec sp_spaceused

http://msdn.microsoft.com...lref/ts_sp_fa-fz_7e7n.asp

[EfBe]

VisionMaster schreef op 16 december 2003 @ 11:36:
Dit is een hele slechte benadering imho, omdat database BLOB (and family), VARCHAR (and family) en nog een zwik andere type comprimeert

Waar haal jij de wijsheid vandaan dat SqlServer data comprimeert? Ik kan daar niets over terugvinden. Varchar fields worden in-line geplaatst, image/ntext fields worden op aparte pages (van 4KB) geplaatst. Nergens staat dat die gecomprimeerd worden.

Op deze manier zou je ten eerste een best wel pittige berekening hebben die (bij meer dan 10 goed gevulde tabellen) toch wel eventjes duurt => lijkt me niet gewenst. En ten tweede komt je benadering neer op je maximum beschikbare capaciteit in de gebruikte record, dat bij BLOB velden dus 2 gigabyte aan potentiele omvang kan bedragen

Nee. een image/text field kan 2GB bedragen. Omdat deze niet in-line worden opgeslagen kan je record dus een veelvoud daarvan bedragen in theorie. Let wel, we praten hier over SqlServer, niet over Oracle.

[VisionMaster]

EfBe schreef op 16 december 2003 @ 11:53:
[...]
Waar haal jij de wijsheid vandaan dat SqlServer data comprimeert? Ik kan daar niets over terugvinden. Varchar fields worden in-line geplaatst, image/ntext fields worden op aparte pages (van 4KB) geplaatst. Nergens staat dat die gecomprimeerd worden.
[...]
Nee. een image/text field kan 2GB bedragen. Omdat deze niet in-line worden opgeslagen kan je record dus een veelvoud daarvan bedragen in theorie. Let wel, we praten hier over SqlServer, niet over Oracle.

Uhm ... VARCHAR is dacht ik een type dat zich automagisch comprimeerd (houdt in.... =>) , dat je dus 256 characters opgeeft als maximum en dat er maar 128 worden gebruikt, dus er worden maar 128 chars (plus/min pre-post fixed chars zoals \0) worden opgeslagen op je disk. Misschien was auto-trimming duidelijker
De berekening zoals hierboven werd vermeld ging dus of alle records af (erg precies) of gaat de database definities af => erg groffe benadering.
Dus als je in een BLOB een jpg van 100kb laad dan gaat je DB toch niet gelijk 2GB reserveren en vastzetten op je disk?
Dit heeft weinig met SQLServer, dan wel Oracle verschillen te maken.
Als je bijvoorbeeld (naar mijn weten) een CHAR veld opgeheeft van 100 chars, dan zal de DB deze niet trimmen bij gebruik van minder CHAR vanuit je invoer.

Comprimeren was misschien een dubbel zinnig/fout woord om te gebruiken, maar naar mijn weten meer in de richting van het verschijnsel dat ik wil aan duiden dan trimming, omdat de data wordt getrimmed en niet je fielddefinitie of gebruik (<= imho).

Deze BLOB fields worden dan op de disk in stukkie van 4kb gehakt. Maa r dan zou je eigenlijk moeten berekenen hoe groot ieder veld is geworden en hoe deze verdeeld zijn over de 4kb blocks.
De berekening wordt dan langer. Ik zou de internal functie gebruiken. Dat maakt je leven gemakkelijker, omdat naar mijn weten ook in de uitgebreide command set dus dit soort administrative zaken niet zijn opgenomen.

[ Voor 21% gewijzigd door VisionMaster op 16-12-2003 12:23 ]

[gorgi_19]

Jaspertje schreef op 16 december 2003 @ 11:50:
Net gevonden:

exec sp_spaceused

http://msdn.microsoft.com...lref/ts_sp_fa-fz_7e7n.asp

Oeh.. Die is idd wel heel erg leuk om te gebruiken...

Alleen jammer dat deze een varchar teruggeeft en geen float, integer, of wat dan ook voor de waarden..

[VisionMaster]

gorgi_19 schreef op 16 december 2003 @ 12:21:
[...]

Oeh.. Die is idd wel heel erg leuk om te gebruiken...

Alleen jammer dat deze een varchar teruggeeft en geeft float, integer, of wat dan ook voor de waarden..

Dat kan veranderen
Misschien is gelijk een varchar voor de TS wel makkelijker displayen ergens

[ Voor 15% gewijzigd door VisionMaster op 16-12-2003 12:25 ]

[curry684]

whoami schreef op 16 december 2003 @ 11:44:
Ik zit net te denken:
Volgens mij kan je nooit de exacte grootte van de databank weten, aangezien je een aantal MB/GB space gaat gaan alloceren die Sql Server mag gebruiken.
Als die ruimte opgebruikt is, gaat ie automatisch z'n beschikbare ruimte gaan vergroten met het percentage of het aantal MB dat je opgegeven hebt bij de creatie van je DB.

Volgens mij moet jij niet denken zo vroeg op de ochtend Hij moet naast de 'allocated space' toch ook de 'used space' realtime weten om te kunnen afleiden wanneer hij een grow moet uitvoeren? Ergo de formaatdata moet gewoon realtime beschikbaar zijn, en is via die stored procedure die Jaspertje al gevonden heeft uit te lezen.

[whoami]

curry684 schreef op 16 december 2003 @ 12:25:
[...]

Volgens mij moet jij niet denken zo vroeg op de ochtend Hij moet naast de 'allocated space' toch ook de 'used space' realtime weten om te kunnen afleiden wanneer hij een grow moet uitvoeren? Ergo de formaatdata moet gewoon realtime beschikbaar zijn, en is via die stored procedure die Jaspertje al gevonden heeft uit te lezen.

Hmmm, idd. Goed gedacht.

[EfBe]

VisionMaster schreef op 16 december 2003 @ 12:18:
Uhm ... VARCHAR is dacht ik een type dat zich automagisch comprimeerd (houdt in.... =>) , dat je dus 256 characters opgeeft als maximum en dat er maar 128 worden gebruikt, dus er worden maar 128 chars (plus/min pre-post fixed chars zoals \0) worden opgeslagen op je disk. Misschien was auto-trimming duidelijker

Oh bedoel je dat, ja hij slaat alleen wat je er inzet op (bij (n)var* fields). Comprimeren is wat anders.

De berekening zoals hierboven werd vermeld ging dus of alle records af (erg precies) of gaat de database definities af => erg groffe benadering.
Dus als je in een BLOB een jpg van 100kb laad dan gaat je DB toch niet gelijk 2GB
reserveren en vastzetten op je disk?

Nee, 25 pages van 4KB.

Dit heeft weinig met SQLServer, dan wel Oracle verschillen te maken.

Oracle slaat de boel anders op dan sqlserver dacht ik (verschilt per versie), details zijn me ontschoten. Yukon overigens gebruikt weer een ander systeem, daar heb je geen 8KB record en losse blob pages, maar simpelweg een bak data en dat is je record.

[mindcrash]

gorgi_19 schreef op 16 december 2003 @ 12:21:
[...]

Oeh.. Die is idd wel heel erg leuk om te gebruiken...

Alleen jammer dat deze een varchar teruggeeft en geen float, integer, of wat dan ook voor de waarden..

Moet geen enkel probleem zijn als je een beetje creatief programmeert

Volgens mij is dit een perfecte target voor een reguliere expressie... ofzo

[ Voor 11% gewijzigd door mindcrash op 16-12-2003 13:24 ]

[gorgi_19]

mindcrash schreef op 16 december 2003 @ 13:23:
[...]


Moet geen enkel probleem zijn als je een beetje creatief programmeert

Volgens mij is dit een perfecte target voor een reguliere expressie... ofzo

't is op zich ook geen probleem om het op te lossen; alleen even uitkijken met localization. Ik zeg alleen dat het jammer is; moet ik er zelf weer een 'hack' omheen verzinnen..

[ Voor 12% gewijzigd door gorgi_19 op 16-12-2003 13:26 ]

[VisionMaster]

EfBe schreef op 16 december 2003 @ 12:43:
[...]
Oh bedoel je dat, ja hij slaat alleen wat je er inzet op (bij (n)var* fields). Comprimeren is wat anders.
[...]
Nee, 25 pages van 4KB.
[...]
Oracle slaat de boel anders op dan sqlserver dacht ik (verschilt per versie), details zijn me ontschoten. Yukon overigens gebruikt weer een ander systeem, daar heb je geen 8KB record en losse blob pages, maar simpelweg een bak data en dat is je record.

Ja dat dus, sorry voor de onduidelijkheid,
Uhm, ja precies, 25 pages,
Ja ok, maar je dat vind ik erg implementatie afhankelijk per database en dat is een beetje offtopic, want iedere DB heeft zijn eigen opslag methode, das wel aardig bekent

[_Thanatos_]

ik wil geen wise-ass zijn, maar is dit niet wat je zoekt, TS?

SQL:

declare @dbsize bigint
declare @logsize bigint
declare @bytesperpage int
declare @reserved bigint

select @dbsize = sum(convert(bigint, [size])) 
   from dbo.sysfiles where (status & 64 = 0)
select @logsize = sum(convert(bigint, [size])) 
   from dbo.sysfiles where (status & 64 <> 0)
select @bytesperpage = [low] 
   from master.dbo.spt_values where number = 1 and type = 'E'
select @reserved = sum(convert(bigint, reserved)) 
   from sysindexes where indid in (0, 1, 255)

select database_name = db_name(), 
   data_size = @dbsize * @bytesperpage, 
   log_size = @logsize * @bytesperpage,
   unallocated_space = (@dbsize - @reserved) * @bytesperpage

[whoami]

Waarom zo moeilijk doen _Thanatos_, als Sql Server blijkbaar al een SP heeft die het gewenste resultaat ophaalt?

[Jaspertje]

_Thanatos_ schreef op 17 december 2003 @ 03:53:
ik wil geen wise-ass zijn, maar is dit niet wat je zoekt, TS?

SQL:

declare @dbsize bigint
declare @logsize bigint
declare @bytesperpage int
declare @reserved bigint

select @dbsize = sum(convert(bigint, [size])) 
   from dbo.sysfiles where (status & 64 = 0)
select @logsize = sum(convert(bigint, [size])) 
   from dbo.sysfiles where (status & 64 <> 0)
select @bytesperpage = [low] 
   from master.dbo.spt_values where number = 1 and type = 'E'
select @reserved = sum(convert(bigint, reserved)) 
   from sysindexes where indid in (0, 1, 255)

select database_name = db_name(), 
   data_size = @dbsize * @bytesperpage, 
   log_size = @logsize * @bytesperpage,
   unallocated_space = (@dbsize - @reserved) * @bytesperpage

Inderdaad al gezegd door whoami, waarom zo moeilijk doen als er sp's zijn die exact hetzelfde teruggeven, zoek eens naar sp_helpdb en sp_spaceused..

Maar wel bedankt voor de moeite uitteraard..

[ Voor 5% gewijzigd door Jaspertje op 17-12-2003 09:30 ]

[_Thanatos_]

Alleen, mijn oplossing geeft netjes de grootte in bytes terug. De sp maakt er een string van die lijkt alsof ie speciaal voor de enterprise manager bestaat

btw, zo moeilijk was mijn oplossing niet, kijk maar eens wat er in sp_spaceused staat. Ongeveer mijn oplossing, maar dan naar MB's geconverteerd

[ Voor 35% gewijzigd door _Thanatos_ op 17-12-2003 15:56 ]

[Annie]

Nog een optie: sp_helpfile

@_Thanatos_: klein probleem met jouw oplossing is natuurlijk dat je rechtstreeks op de system-tables bezig bent.