Fragensteller
Größe von Indizes über sys.allocation_units und sys.partitions Interpretation

Frage
-
Hallo zusammen,
Ich habe bei uns ein System geschrieben, dass die Größe aller Indizes einer Datenbank loggt. Das dahinterstehende Script wird regelmäßig ausgeführt und bei Veränderungen ein neuer Eintrag erstellt.
Um die Größe des Indizes zu ermitteln benutze ich die sys.allocation_units gejoint mit der sys.partitions und rechne dort die total und used pages * 8
Beim Überprüfen ist mir nun aufgefallen, dass es wenige Indizes gibt, bei denen die Zahl der UsedPages größer ist als die der TotalPages. Ich hatte das bisher so interpretiert das TotalPages die reservierte Anzahl angibt (verfügbare) und die Used Pages die aktuell belegten. Der markierte Eintrag hat, wenn man die Group By Clause weglässt nur einen InRowData Eintrag mit eben diesen 116 total und 119 used pages.. 98 datapages..
Bild siehe: s1.directupload_net/images/140530/t2s5hk8p.png ( "_" durch punkt ersetzen)
Was hab ich denn da nun?
Alle Antworten
-
Hallo,
Siehe MSDN sys.allocation_units (Transact-SQL) :
total_pages = Gesamtanzahl der Seiten, die von dieser Zuordnungseinheit zugeordnet oder reserviert wurden.
used_pages = Gesamtanzahl der tatsächlich verwendeten SeitenBei mir ist immer "total_pages" größer als "user_pages". Man kann die Seitenzahl auch über sys.dm_db_partition_stats (Transact-SQL) ermitteln, was liefert das als Ergebnis?
SELECT SCH.name AS SchemaName, OBJ.name AS ObjName, OBJ.type_desc AS ObjType, INDX.name AS IndexName, INDX.type_desc AS IndexType, PART.partition_number AS PartitionNumber, PART.rows AS PartitionRows, STAT.row_count AS StatRowCount, STAT.used_page_count * 8 AS UsedSizeKB, STAT.reserved_page_count * 8 AS RevervedSizeKB FROM sys.partitions AS PART INNER JOIN sys.dm_db_partition_stats AS STAT ON PART.partition_id = STAT.partition_id AND PART.partition_number = STAT.partition_number INNER JOIN sys.objects AS OBJ ON STAT.object_id = OBJ.object_id INNER JOIN sys.schemas AS SCH ON OBJ.schema_id = SCH.schema_id INNER JOIN sys.indexes AS INDX ON STAT.object_id = INDX.object_id AND STAT.index_id = INDX.index_id ORDER BY SCH.name, OBJ.name, INDX.name, PART.partition_number
Olaf Helper
[ Blog] [ Xing] [ MVP]- Bearbeitet Olaf HelperMVP Freitag, 30. Mai 2014 12:00
-
Hast Du mal versucht mit DBCC UPDATEUSAGE die Angaben zu den Indizes zu korrigieren?
DBCC UPDATEUSAGE (Transact-SQL)
http://msdn.microsoft.com/de-de/library/ms188414(v=sql.110).aspx
Meldet und behebt Ungenauigkeiten bei den Seiten- und Zeilenzahlen in den Katalogsichten. Diese Ungenauigkeiten können falsche Berichte über die Speicherplatzverwendung verursachen, die von der gespeicherten Systemprozedur sp_spaceused zurückgegeben werden.
Einen schönen Tag noch,
Christoph
--
Microsoft SQL Server MVP - http://www.insidesql.org/blogs/cmu -
Interessant wäre noch die Version und ServicePack-Stand!
Select @@Version;
Ich kann das z. B. bei einem Index auf SQL Server 2008 (10.0.5512.0) beobachten. Die Tabelle hat außerdem mehrere varchar(max) Felder.
Einen schönen Tag noch,
Christoph
--
Microsoft SQL Server MVP - http://www.insidesql.org/blogs/cmu -
-
Version und Edition stimmen ziemlich mit meiner Konfiguration überein.
DBCC UPDATEUSAGE bringt bei meiner Datenbank keine Änderung.
Das ist wohl eher an der doch recht veralteten Version festzumachen. Auf SQL Server 2012 habe ich so etwas noch nicht beachten können. Allerdings werde ich diese Datenbank morgen auf 2012 migrieren und dann schaue ich mal, wie es danach aussieht.
Einen schönen Tag noch,
Christoph
--
Microsoft SQL Server MVP - http://www.insidesql.org/blogs/cmu -
Hallo Daniel,
nach der Migration auf SQL Server 2012 sieht das ganze viel besser aus. Allerdings wurde nun auch mal wieder die Größe auf dem alten System korrigiert.Ich hoffe mal, dass der Zustand auf SQL Server 2012 stabil bleibt.
Einen schönen Tag noch,
Christoph
--
Microsoft SQL Server MVP - http://www.insidesql.org/blogs/cmu -
Hallo Christian,
Danke für deine Nachricht.
Hast du den 2008er irgendwie neugestartet?
Ein Teilsystem wird bei uns ebenfalls demnächst auf 2012 migriert, aber die Aussagekraft meiner Daten wäre mir schon wichtig. Sonst bringt mir das Loggen der Daten ja nichts :)
Aber vielen Dank!
Grüße
Daniel
-
Hallo Daniel,
ich hatte keinen Neustart gemacht. Erst das DBCC UPDATEUSAGE, danach waren die Werte noch nicht korrekt, dann lief noch zwei mal ein Reorg auf den Index und dann waren die Werte plötzlich auch auf dem 2008er korrekt.
Meine Tabelle hat ca. 5.000.000 Zeilen und belegt ca. 40 GB.Nach 5 Tagen mit SQL Server 2012 sind die Werte immer noch korrekt.
Einen schönen Tag noch,
Christoph
--
Microsoft SQL Server MVP - http://www.insidesql.org/blogs/cmu