SQL Server Closeup #3: Strukturen zur Speicherung von Daten – Speicherplatzverwaltung

Mit diesem Teil der "SQL Server Closeup" Serie schließe ich den Theorieteil der Strukturen zur Speicherung von Daten in der SQL Server Storage Engine ab.

Heutiges Thema soll die Speicherplatzverwaltung, also das Allocation System, sein.

Was sind Extents

Extents sind ein logisches Konstrukt, dass 8 aufeinanderfolgende Pages gruppiert. Dies soll dazu dienen die Speicherverwaltung effizienter zu machen, indem auf den Speicherübersichtseiten (Allocation Bitmaps und Bytemaps), welche in regelmäßigen Intervallen angelegt werden, die Informationen pro Extent und nicht pro Page gespeichert werden.

Eine Altlast vom SQL Server 7.0 (Wo der Speicher noch teuer war) ist, dass die ersten 8 Pages verschiedener Objekte (Tabelle, Index, etc.) gemeinsam in einem Extent gespeichert werden. Diese Extents werden als Mixed Extents bezeichnet.
Nachdem zu einem Objekt 8 Pages existieren, werden nur noch spezielle Extents erzeugt, die ausschließlich für dieses Objekt verwendet werden. Diese Extents werden als Uniform Extents oder auch als Dedicated Extents bezeichnet.

Es werden jeweils 8 Pages pro Extent reserviert. Die zugehörigen Pages werden nur bei Bedarf erzeugt und anschließend dem Extent zugeordnet.

 

Was sind PFS Pages

PFS steht für Page Free Space und ist die einzige Allocation Bytemap der Storage Engine.

Eine PFS Page wird in einem Intervall von 64 MB angelegt und enthält ein Byte pro Page des darauf folgenden Intervalls.

Unter anderem speichern PFS Pages folgende Informationen über die zu verwaltenden Pages:

• Ist die Page bereits "Allocated" – wird sie also bereits verwendet? (hierfür wird 1 Bit verwendet)
• Freier Speicherplatz für Heaps und Text Pages, da hier der SQL Server frei entscheiden kann wo ein Record gespeichert werden soll. (hierfür werden 3 Bits verwendet)
• Ist diese Page eine IAM Page? Dazu später mehr… (hierfür wird 1 Bit verwendet)
• Hat diese Seite Ghosted Records? (hierfür wird 1 Bit verwendet)
• Gehört diese Page zu einem Mixed Extent? (hierfür wird 1 Bit verwendet)

 

Allocation Bitmaps zum Speicherplatzverwaltung von Extents

Der SQL Server verwendet zwei spezielle Page Arten, um Extents zu verwalten.

Global Allocation Map (GAM Page)

Auf einer GAM Page wird festgehalten, welche Extents bereits in Verwendung sind.
Eine GAM Page enthält ein Bit für jeden Extent, die sie verwaltet. Wenn das Bit auf 0 gesetzt ist, ist der Extent in Verwendung, bei einer 1 ist er frei.
Nach dem Page Header und ein wenig Overhead, stehen auf einer GAM Page 8.000 Bytes bzw. 64.000 Bits zur Extent-Verwaltung zur Verfügung. Somit kann eine GAM Page einen Intervall von ca. 4 GB abdecken.
Die erste GAM Page einer Datei trägt die Page ID 1:3

Shared Global Allocation Map (SGAM Page)

Auf einer SGAM Page wird festgehalten, welche Extents im Mixed Extent Modus betrieben werden und mindestens eine freie Page haben.
Eine SGAM Page enthält ein Bit für jeden Extent, die sie verwaltet. Wenn das Bit auf 0 gesetzt ist, ist der Extent ein Uniform Extent oder er hat keine freie Page mehr, bei einer 1 handelt es sich um einen Mixed Extent mit mind. einer freien Page.
Genau wie bei den GAM Pages deckt eine SGAM Page einen Intervall von ca. 4 GB ab.
Die erste SGAM Page einer Datei trägt die Page ID 1:4

Wenn also die Storage Engine eine neue Page anlegen möchte, sucht sie als erstes auf den SGAM Pages nach einem Mixed Extent mit einer freien Page. Wenn sie dort keinen Extent findet, durchsucht sie die GAM Pages, um einen freien Extent zu finden. Wenn dieser gefunden ist, wird dieser auf der GAM Page als Verwendet markiert sowie auf der SGAM Page als Verfügbar.

 

Allocation Bitmaps für die Datensicherung

Für das Thema Backup gibt es ähnliche Allocation Bitmaps.

Differential Changed Map (DCM Page bzw. DIFF Map)

Auf einer DCM Page wird festgehalten, welche Extents sich seit dem letzten Full Backup verändert haben.
Wenn Differential Backups durchgeführt werden sollen, durchsucht die Storage Engine alle DCM Pages nach Veränderungen und sichert anschließend die gefundenen Extents.
Genau wie bei den GAM Pages deckt eine DCM Page einen Intervall von ca. 4 GB ab.

Bulk Changed Map (BCM Page) bzw. Minimally Logged Map (ML Map)

Auf einer BCM Page wird festgehalten, welche Extents seit dem letzten T-Log Backup neu hinzugekommen sind.
Bei dem nächsten T-Log Backup werden nach dem sichern des T-Logs alle BCM Pages durchsucht und anschließend die gefundenen Extents gesichert. Somit kann ein T-Log Backup auch Pages enthalten.
Genau wie bei den GAM Pages deckt eine BCM Page einen Intervall von ca. 4 GB ab.

 

Was sind IAM Pages

Um eine Verbindung zwischen Objekten (Tabelle, Index, Partition) und Extents zu schaffen, werden IAM Pages verwendet.

Index Allocation Map (IAM Page)

Eine IAM Page zeigt an in welchen Extents, eines 4 GB Intervalls, Teile des zu verwaltenden Objektes gespeichert werden.
Eine IAM Page besteht aus einem Header, einem Single-Page-Slot-Array und einer Allocation Bitmap.

Der IAM Page Header enthält u.a. folgende Informationen:

• Den zugehörigen GAM Intervall inkl. Datei, da IAM Pages nicht unbedingt in der gleichen Datei gespeichert werden.
• Die Sequenz ID und Verbindungen innerhalb einer IAM Chain.
  Eine IAM Chain ist eine Verkettung zusammengehöriger IAM Pages.
  Jedes mal, wenn eine neue IAM Page angelegt werden muss, werden Pointer zur vorherigen und nachfolgenen IAM Page vermerkt.

Das Single-Page-Slot-Array wird nur bei der ersten IAM Page eines Objektes gefüllt und enthält Pointer zu den 8 Pages des zugehörigen Mixed Extents.

Die Allocation Bitmap enthält ein Bit für jeden Extent des Intervalls. Wenn das Bit auf 1 gesetzt ist, enthält das Extent Teile des Objektes, ansonsten ist das Bit auf 0 gesetzt.

IAM Page Chains seit dem SQL Server 2005

Durch die Features Row-Overflow, Included Columns (bei einem Non-Clustered Index) und Partitioning war es nötigt, dass das IAM System umgeschrieben wurde.
Vor dem SQL Server 2005 wurde nur eine IAM Chain pro Tabelle pro Index erzeugt.
Seit dem SQL Server 2005 ist es möglich, dass eine Tabelle plus Index mehrere IAM Chains haben kann (Eine für jede neue Speicherart und jede Partition).

Da der Begriff IAM sich nun nicht mehr nur auf Indizes bezieht, wurde er in Allocation Units umbenannt.
Bei vielen SQL Befehlen wird allerdings immer noch der Begriff IAM angezeigt.

Es gibt 3 Arten von Allocation Units:

• IN_ROW_DATA Allocation Unit – Für Pages die Data und Index Records enthalten.
• LOB_DATA Allocation Unit – Für Pages die Text Records für "normale" LOB Daten enthalten.
• ROW_OVERFLOW_DATA Allocation Unit – Für Pages die Text Records enthalten, die off-row gespeichert wurden.

Bei der Verwendung von undokumentierten Befehlen, können auch die internen Namen auftauchen:

• HoBt – Heap-or-B-Tree
• LOB – Large Object
• SLOB – Small-LOB

Kommende Themen

In den kommenden Postings werde ich Beispiele mit teilweise undokumentierten Befehlen sowie Freeware Tools zeigen, die einen genaueren Blick unter die Haube der SQL Server Storage Engine werfen.

---

Quellen: SQLskills.com und Microsoft® SQL Server® 2008 Internals (ISBN-10: 0735626243)