none
Größe von Indizes über sys.allocation_units und sys.partitions Interpretation RRS feed

  • 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?

    Freitag, 30. Mai 2014 09:40

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 Seiten

    Bei 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]


    Freitag, 30. Mai 2014 11:59
  • 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

    Freitag, 30. Mai 2014 12:21
  • 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

    Freitag, 30. Mai 2014 12:36
  • Microsoft SQL Server 2008 (SP3) - 10.0.5835.0 (X64)  

    sys.dm_db_partition_stats liefert das selbe ergebnis

    DBCC UpdateUsage läuft grade nicht, weil auf der besagten Datenbank anderer Prozesse laufen


    • Bearbeitet Crumar Freitag, 30. Mai 2014 13:08
    Freitag, 30. Mai 2014 13:07
  • 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

    Montag, 2. Juni 2014 07:46
  • Hallo Christoph,

    würde mich freuen wenn du deine Ergebnisse nach der Migration posten würdest.

    Habe auf unserem Dev System einmal die DBCC UpdateUsage laufen lassen, ebenfalls keine Verbesserung.

    Grüße,

    Daniel

    Montag, 2. Juni 2014 13:34
  • 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

    Dienstag, 3. Juni 2014 12:19
  • 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

    Donnerstag, 5. Juni 2014 15:12
  • 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

    Freitag, 6. Juni 2014 06:11