Leitfaden für die Architektur von Seiten und Datenbank-Shards

Gilt für: SQL Server Azure SQL DatabaseAzure SQL Managed InstanceAzure Synapse AnalyticsPlatform System (PDW)

Die Seite ist die grundlegende Einheit der Datenspeicherung in SQL Server. Ein Bereich ist eine Sammlung von acht physisch zusammenhängenden Seiten. Blöcke tragen zu einer effizienten Verwaltung von Seiten bei. In diesem Handbuch werden die Datenstrukturen beschrieben, die zum Verwalten von Seiten und Blöcken in allen Versionen von SQL Server verwendet werden. Kenntnisse der Architektur von Seiten und Blöcken sind Voraussetzung für das Entwerfen und Entwickeln von effizienten Datenbanken.

Seiten und Blöcke

Die grundlegende Einheit für die Datenspeicherung in SQL Server ist die Seite. Der einer Datendatei (MDF oder NDF) in einer Datenbank zugeordnete Speicherplatz wird logisch in Seiten unterteilt, die zusammenhängend von 0 bis n nummeriert sind. Datenträger-E/A-Operationen werden auf Seitenebene ausgeführt. Dies bedeutet, dass SQL Server ganze Datenseiten liest oder schreibt.

Blöcke sind Auflistungen von acht physisch zusammenhängenden Seiten; sie werden zum effizienten Verwalten der Seiten verwendet. Alle Seiten sind in Blöcke unterteilt.

Seiten

In einem regulären Buch wird der gesamte Inhalt auf Seiten geschrieben. Ähnlich wie bei einem Buch schreibt SQL Server alle Datenzeilen auf Seiten, und alle Datenseiten haben die gleiche Größe: 8 KB. In einem Buch enthalten die meisten Seiten die Daten - den Hauptinhalt des Buchs - und einige Seiten enthalten Metadaten zum Inhalt (z. B. das Inhaltsverzeichnis und den Index). Auch hier ist SQL Server nicht anders: Die meisten Seiten enthalten tatsächliche Datenzeilen, die von Benutzern gespeichert wurden; diese werden als Datenseiten und Text-/Bildseiten bezeichnet (für Sonderfälle). Die Indexseiten enthalten Indexverweise darüber, wo sich die Daten befinden. Schließlich gibt es Systemseiten , die verschiedene Metadaten zur Organisation der Daten speichern.

Jede Seite beginnt mit einem 96 Byte umfassenden Header, der zum Speichern von Systeminformationen zu der betreffenden Seite verwendet wird. Diese Informationen umfassen die Seitennummer, den Typ der Seite, den Umfang des freien Speicherplatzes auf der Seite und die ID der Zuordnungseinheit, die Besitzer der Seite ist.

Die folgende Tabelle zeigt die Seitentypen, die in Datendateien einer SQL Server-Datenbank verwendet werden.

Seitentyp Contents
Daten Datenzeilen mit allen Daten, außer text, ntext, image, nvarchar(max), varchar(max), varbinary(max), und xml-Daten , wenn Text in Zeile auf ON festgelegt ist.
Index Indexeinträge
Text/Bild Große Objektdatentypen: text, ntext, image, nvarchar(max), varchar(max), varbinary(max), und xml-Daten .

Spalten mit variabler Länge, wenn die Datenzeile 8 KB überschreitet: varchar, nvarchar, varbinary und sql_variant.
Global Allocation Map (GAM)

Shared Global Allocation Map (SGAM)
Informationen dazu, ob Blöcke zugeordnet sind.
Page Free Space (PFS) Informationen zur Seitenzuordnung sowie zum freien Speicherplatz, der auf Seiten verfügbar ist.
Indexzuordnungszuordnung (IAM) Informationen zu Blöcken, die von einer Tabelle oder einem Index pro Zuordnungseinheit verwendet werden.
Bulk Changed Map (BCM) Informationen zu Blöcken, die seit der letzten Ausführung der BACKUP LOG-Anweisung pro Zuordnungseinheit durch Massenvorgänge geändert wurden.
Differential Changed Map (DCM) Informationen zu Blöcken, die seit der letzten Ausführung der BACKUP DATABASE-Anweisung pro Zuordnungseinheit geändert wurden.

Hinweis

Protokolldateien enthalten keine Seiten. Sie enthalten eine Reihe von Protokolldatensätzen, die keine feste Größe haben.

Datenzeilen werden auf der Seite seriell gespeichert, beginnend unmittelbar nach der Kopfzeile. Eine Zeilenoffsettabelle beginnt am Ende der Seite, und jede Zeilenoffsettabelle enthält einen Eintrag für jede Zeile auf der Seite. Jeder Zeilenoffseteintrag speichert, wie weit das erste Byte der Zeile vom Anfang der Seite entfernt ist. Daher besteht die Funktion der Zeilenoffsettabelle darin, Zeilen auf einer Seite schnell SQL Server zu finden. Die Einträge in der Zeilenoffsettabelle befinden sich in umgekehrter Reihenfolge zur Reihenfolge der Zeilen auf der Seite.

Diagramm der Seite

Unterstützung für große Zeilen

Zeilen können sich nicht über Seiten erstrecken. Teile der Zeile können jedoch von der Seite der Zeile verschoben werden, sodass die Zeile sehr groß sein kann. Die maximale Datenmenge und der Aufwand, die in einer einzelnen Zeile auf einer Seite enthalten sind, beträgt 8.060 Byte. Dies schließt nicht die daten ein, die im Seitentyp text/image gespeichert sind.

Diese Einschränkung wird für Tabellen gelockert, die varchar-, nvarchar-, varbinary- oder sql_variant-Spalten enthalten. Wenn die Gesamtzeilengröße aller festen und variablen Spalten in einer Tabelle den Grenzwert von 8.060 Bytes übersteigt, verschiebt SQL Server eine oder mehrere Spalten variabler Länge dynamisch auf Seiten in der ROW_OVERFLOW_DATA-Zuordnungseinheit. Dabei wird mit der Spalte mit der größten Breite begonnen.

Dieser Vorgang wird immer ausgeführt, wenn die Gesamtgröße der Zeile durch einen Einfüge- oder Updatevorgang den Maximalwert von 8.060 Byte übersteigt. Wenn eine Spalte auf eine Seite in der ROW_OVERFLOW_DATA-Zuordnungseinheit verschoben wird, wird ein 24-Byte-Zeiger auf die ursprüngliche Seite in der IN_ROW_DATA-Zuordnungseinheit verwaltet. Falls eine nachfolgende Operation die Spaltengröße verringert, verschiebt SQL Server die Spalten dynamisch zurück auf die ursprüngliche Datenseite.

Überlegungen zum Zeilenüberlauf

Eine Zeile darf sich nicht auf mehreren Seiten befinden und kann überlaufen, wenn die kombinierte Größe von Datentypfeldern mit variabler Länge den Grenzwert von 8060 Byte überschreitet. Zur Veranschaulichung kann eine Tabelle mit zwei Spalten erstellt werden: eine varchar(7000) und eine andere varchar (2000). Einzeln überschreitet keine Spalte 8060 Bytes, aber in Kombination können sie dies tun, wenn die gesamte Breite jeder Spalte gefüllt ist. SQL Server können die Varchar(7000)-Spalte mit variabler Länge dynamisch auf Seiten in der ROW_OVERFLOW_DATA-Zuordnungseinheit verschieben. Wenn Sie varchar-, nvarchar-, varbinary- oder sql_variant- oder CLR-Spalten mit mehr als 8.060 Byte pro Zeile kombinieren, sollten Sie Folgendes berücksichtigen:

  • Das Verschieben großer Datensätze zu einer anderen Seite geschieht dynamisch, wenn die Datensätze im Ergebnis von Updatevorgängen verlängert wurden. Updatevorgänge, die zu einer Verkürzung von Datensätzen führen, können hingegen bewirken, dass Datensätze wieder zurück zur ursprünglichen Seite in der IN_ROW_DATA-Zuordnungseinheit verschoben werden.

    Abfragen und andere Auswahlvorgänge, wie z. B. Sortierungen oder Joins von großen Datensätzen mit Daten, bei denen Zeilenüberlauf vorkommt, bewirken eine Herabsetzung der Verarbeitungsgeschwindigkeit, weil diese Datensätze nicht asynchron, sondern synchron verarbeitet werden.

    Wenn Sie eine Tabelle mit mehreren Spalten vom Typ varchar, nvarchar, varbinary oder sql_variant oder CLR entwerfen, sollten Sie daher den Prozentsatz der Zeilen berücksichtigen, die wahrscheinlich überfließen werden, und die Häufigkeit, mit der diese Überlaufdaten wahrscheinlich abgefragt werden. Wenn es wahrscheinlich häufig zu Abfragen von vielen Zeilen mit überlaufenden Daten kommt, sollten Sie eine Normalisierung der Tabelle in Betracht ziehen, damit einige Spalten in eine andere Tabelle verschoben werden. Diese können dann in einer asynchronen JOIN-Operation abgefragt werden.

  • Die Länge einzelner Spalten muss weiterhin innerhalb des Grenzwerts von 8.000 Bytes für spalten vom typ varchar, nvarchar, varbinary oder sql_variant und CLR liegen. Lediglich ihre kombinierten Längen dürfen das Zeilenlimit von 8.060 Byte einer Tabelle überschreiten.

  • Die Summe der anderen Datentypspalten, einschließlich char - und nchar-Daten , muss innerhalb des Zeilengrenzwerts von 8.060 Byte liegen. Große Objektdaten sind ebenfalls vom 8.060-Byte-Zeilenlimit ausgenommen.

  • Der Indexschlüssel eines gruppierten Index kann keine Spalten des Datentyps varchar enthalten, bei denen Daten in der Zuordnungseinheit ROW_OVERFLOW_DATA vorhanden sind. Wird ein gruppierter Index für eine varchar-Spalte erstellt, bei der in der Zuordnungseinheit IN_ROW_DATA Daten vorhanden sind, erzeugen alle nachfolgenden Einfügungen und Updates der Spalte einen Fehler, bei der diese Daten aus der Zeile entfernt werden. Weitere Informationen zu Zuordnungseinheiten finden Sie unter Indexarchitektur und Entwurfshandbuch.

  • Sie können Spalten, die Daten mit Zeilenüberlauf enthalten, als Schlüssel- oder Nichtschlüsselspalten eines nicht gruppierten Index einbeziehen.

  • Die Datensatzgrößenbeschränkung für Tabellen, die Sparsespalten verwenden, beträgt 8.018 Byte. Wenn die konvertierten Daten zusammen mit den vorhandenen Datensatzdaten 8.018 Byte überschreiten, wird MSSQLSERVER ERROR 576 zurückgegeben. Wenn Spalten zwischen Sparse- und Ungleichwerttypen konvertiert werden, behält die Datenbank-Engine eine Kopie der aktuellen Datensatzdaten bei. Dies verdoppelt vorübergehend den Speicher, der für den Datensatz erforderlich ist.

  • Zum Abrufen von Informationen zu Tabellen oder Indizes, die ggf. Daten mit Zeilenüberlauf enthalten, verwenden Sie die dynamische Verwaltungsfunktion sys.dm_db_index_physical_stats.

Extents

Blöcke sind die Grundeinheit, in der Speicherplatz verwaltet wird. Ein Block umfasst acht zusammenhängende Seiten, also 64 KB. Dies bedeutet, dass SQL Server Datenbanken 16 Blöcke pro Megabyte aufweisen.

SQL Server verfügt über zwei Arten von Blöcken:

  • Einheitliche Blöcke befinden sich im Besitz eines einzigen Objekts; alle acht Seiten in dem Block können nur vom besitzenden Objekt verwendet werden.
  • Gemischte Blöcke werden für bis zu acht Objekte freigegeben. Jede der acht Seiten im Block kann im Besitz eines anderen Objekts sein.

Diagramm mit einheitlichen und gemischten Blöcken.

Bis einschließlich SQL Server 2014 (12.x) weist die Datenbank-Engine Tabellen mit kleinen Datenmengen keine ganzen Blöcke zu. Für eine neue Tabelle oder einen neuen Index werden normalerweise Seiten aus gemischten Blöcken zugewiesen. Wenn eine Tabelle oder ein Index so groß geworden ist, dass sie bzw. er acht Seiten umfasst, werden bei nachfolgenden Zuweisungen einheitliche Blöcke zugewiesen. Wenn Sie einen Index für eine vorhandene Tabelle erstellen, die über genügend Zeilen verfügt, um acht Seiten im Index zu generieren, erfolgen alle Zuweisungen für den Index in Form von einheitlichen Blöcken.

Ab SQL Server 2016 (13.x) wird standardmäßig für die meisten Zuordnungen in einer Benutzerdatenbank tempdb einheitliche Blöcke verwendet, mit Ausnahme von Zuordnungen, die zu den ersten acht Seiten einer IAM-Kette gehören. Zuordnungen für masterDatenbanken, msdb, und model behalten weiterhin das vorherige Verhalten bei.

Hinweis

In SQL Server können Sie bis einschließlich SQL Server 2014 (12.x) ablaufverfolgungsflag (TF) 1118 verwenden, um die Standardzuordnung so zu ändern, dass immer einheitliche Blöcke verwendet werden. Weitere Informationen zu diesem Ablaufverfolgungsflag finden Sie unter DBCC TRACEON – Trace Flags.

Ab SQL Server 2016 (13.x) wird die von TF 1118 bereitgestellte Funktionalität automatisch für tempdb und alle Benutzerdatenbanken aktiviert. Bei Benutzerdatenbanken wird dieses Verhalten durch die SET MIXED_PAGE_ALLOCATION Option von ALTER DATABASEgesteuert, wobei der Standardwert auf OFF festgelegt ist, und TF 1118 hat keine Auswirkung. Weitere Informationen finden Sie unter ALTER DATABASE SET-Optionen (Transact-SQL).

Ab SQL Server 2012 (11.x) kann die Systemfunktion sys.dm_db_database_page_allocations Informationen zur Seitenzuordnung für eine Datenbank, eine Tabelle, einen Index und eine Partition melden.

Wichtig

Die Systemfunktion sys.dm_db_database_page_allocations ist nicht dokumentiert kann jederzeit geändert werden. Kompatibilität wird nicht sichergestellt.

Ab SQL Server 2019 (15.x) ist die Systemfunktion sys.dm_db_page_info verfügbar und gibt Informationen zu einer Seite in einer Datenbank zurück. Die -Funktion gibt eine Zeile zurück, die die Kopfzeileninformationen der Seite enthält, einschließlich , object_idindex_idund partition_id. Dank dieser Funktion ist die Verwendung von DBCC PAGE in den meisten Fällen nicht mehr erforderlich.

Verwalten von Zuweisungen von Blöcken und freiem Speicherplatz

Die SQL Server-Datenstrukturen, die Blockzuordnungen verwalten und freien Speicherplatz nachverfolgen, weisen eine relativ einfache Struktur auf. Das hat folgende Vorteile:

  • Die Informationen zum freien Speicherplatz sind dicht gepackt, sodass nur relativ wenig Seiten benötigt werden, um diese Informationen aufzunehmen.

    Dies erhöht die Geschwindigkeit, indem die Anzahl der Datenträgerlesevorgänge reduziert wird, die zum Abrufen von Zuordnungsinformationen erforderlich sind. Hierdurch wird auch die Wahrscheinlichkeit erhöht, dass die Zuordnungsseiten im Arbeitsspeicher verbleiben und somit keine weiteren Lesevorgänge erforderlich sind.

  • Die meisten Zuordnungsinformationen sind nicht miteinander verkettet. Hierdurch wird die Verwaltung der Zuordnungsinformationen vereinfacht.

    Das Zuordnen oder Aufheben der Zuordnung der einzelnen Seiten kann sehr schnell erfolgen. So wird die Anzahl der Konflikte zwischen gleichzeitig ausgeführten Tasks reduziert, die Seiten zuordnen oder die Zuordnung von Seiten aufheben müssen.

Verwalten von Bereichszuordnungen

SQL Server verwendet zwei Arten von Zuordnungstabellen, um die Zuordnung von Blöcken zu erfassen:

  • Global Allocation Map (GAM)

    GAM-Seiten zeichnen auf, welche Blöcke zugeordnet wurden. Jede GAM erfasst 64.000 Blöcke, was fast 4 GB an Daten entspricht. Gam verfügt über 1 Bit für jede Blöcke in dem Intervall, das es abdeckt. Wenn das Bit ist 1, ist die Blöcke frei. Wenn das Bit ist 0, wird die Blöcke zugeordnet.

  • Shared Global Allocation Map (SGAM)

    SGAM-Seiten zeichnen auf, welche Blöcke zurzeit als gemischte Blöcke verwendet werden und über mindestens eine nicht verwendete Seite verfügen. Jede SGAM erfasst 64.000 Blöcke, was fast 4 GB an Daten entspricht. Das SGAM verfügt über 1 Bit für jede Blöcke im Intervall, das er abdeckt. Wenn das Bit ist 1, wird die Blöcke als gemischte Blöcke verwendet und verfügt über eine freie Seite. Wenn das Bit ist 0, wird die Vergrößerung nicht als gemischte Erweiterung verwendet, oder es handelt sich um eine gemischte Vergrößerung, und alle zugehörigen Seiten werden verwendet.

Für jeden Block wird auf der Grundlage der aktuellen Verwendung eines der folgenden Bitmuster in der GAM oder der SGAM festgelegt.

Aktuelle Blockverwendung GAM-Biteinstellung SGAM-Biteinstellung
Frei, wird nicht verwendet 1 0
Einheitlicher Block oder vollständig belegter gemischter Block 0 0
Gemischter Block mit freien Seiten 0 1

Dies führt zu einfachen Algorithmen für die Blockverwaltung.

  • Um einen einheitlichen Umfang zuzuordnen, durchsucht die Datenbank-Engine die GAM nach einem 1 Bit und legt ihn auf fest 0.
  • Um einen gemischten Umfang mit freien Seiten zu finden, durchsucht die Datenbank-Engine das SGAM nach einem 1 Gewissen.
  • Um einen gemischten Bereich zuzuordnen, durchsucht die Datenbank-Engine das GAM nach einem 1 Bit, legt es auf 0fest und legt dann auch das entsprechende Bit im SGAM auf fest 1.
  • Zum Aufheben der Zuordnung eines Blöckes stellt die Datenbank-Engine sicher, dass das GAM-Bit auf 1und das SGAM-Bit auf 0festgelegt ist.

Die Algorithmen, die intern von der Datenbank-Engine verwendet werden, sind komplexer als die in diesem Artikel beschriebenen, da die Datenbank-Engine Daten gleichmäßig in einer Datenbank verteilt. Aber auch die wirklich verwendeten Algorithmen konnten vereinfacht werden, da nunmehr keine verketteten Blockzuordnungsinformationen verwaltet werden müssen.

Nachverfolgen des freien Speicherplatzes

PFS-Seiten (Page Free Space) zeichnen den Zuordnungsstatus der einzelnen Seiten auf, ob eine einzelne Seite zugeordnet wurde und die Menge des freien Speicherplatzes für die einzelnen Seiten. Der PFS verfügt über 1 Byte für jede Seite und zeichnet auf, ob die Seite zugeordnet ist, und wenn ja, ob sie leer, 1 bis 50 Prozent voll, 51 bis 80 Prozent voll, 81 bis 95 Prozent oder 96 bis 100 Prozent voll ist.

Nachdem ein Block einem Objekt zugeordnet wurde, verwendet die Datenbank-Engine die PFS-Seiten, um aufzuzeichnen, welche Seiten in dem jeweiligen Block zugeordnet und welche Seiten frei sind. Diese Informationen werden verwendet, wenn die Datenbank-Engine eine neue Seite zuordnen muss. Der freie Speicherplatz auf einer Seite wird nur für Heap- und Text-/Bildseiten beibehalten. Diese Information wird verwendet, wenn die Datenbank-Engine eine Seite mit verfügbarem freien Speicherplatz sucht, um eine neu eingefügte Zeile aufzunehmen. Indizes erfordern nicht, dass der freie Seitenspeicherplatz nachverfolgt wird, da der Punkt, an dem eine neue Zeile eingefügt werden soll, durch die Indexschlüsselwerte festgelegt wird.

In der Datendatei wird für jeden zusätzlichen Bereich, der nachverfolgt wird, eine neue PFS-, GAM- oder SGAM-Seite hinzugefügt. Nach der ersten PFS-Seite folgt also alle 8.088 Seiten eine neue PFS-Seite. So stellen also die Seiten mit Seiten-ID 1, Seiten-ID 8088 und Seiten-ID 16176 PFS-Seiten dar.

Nach der ersten GAM-Seite folgt jeweils im Abstand von 64.000 Blöcken eine neue GAM-Seite, die die nächsten 64.000 Blöcke nachverfolgt. Dementsprechend folgt nach der ersten SGAM-Seite im Abstand von 64.000 Blöcken jeweils eine neue SGAM-Seite.

Folgende Abbildung veranschaulicht die Abfolge der Seiten, die von der Datenbank-Engine für das Zuordnen und Verwalten von Blöcken verwendet werden.

Diagramm, das die Seitenfolge für die Verwaltung von Blöcken zeigt.

Verwalten des von Objekten verwendeten Speicherplatzes

Eine IAM-Seite (Index Allocation Map) ordnet die Blöcke in einem 4-GB-Teil einer Datenbankdatei zu, die von einer Zuordnungseinheit verwendet wird. Eine Zuordnungseinheit entspricht einem von drei möglichen Typen:

  • IN_ROW_DATA

    Enthält eine Partition eines Heap oder eines Index.

  • LOB_DATA

    Enthält LOB-Datentypen (Large Object), z. B. xml, varbinary(max) und varchar(max).

  • ROW_OVERFLOW_DATA

    Enthält Daten mit variabler Länge, die in varchar-, nvarchar-, varbinary- oder sql_variant Spalten gespeichert sind, die die Zeilengrößenbeschränkung von 8.060 Byte überschreiten.

Jede Partition eines Heap oder Index enthält mindestens eine IN_ROW_DATA-Zuordnungseinheit. Sie kann je nach dem Heap- oder Indexschema auch eine LOB_DATA- oder ROW_OVERFLOW_DATA-Zuordnungseinheit enthalten.

Eine IAM-Seite deckt einen 4-GB-Bereich in einer Datei ab und besitzt dieselbe Erfassung wie eine GAM- oder SGAM-Seite. Wenn die Zuordnungseinheit Blöcke mehrerer Dateien oder mehrere 4-GB-Bereiche einer Datei enthält, werden mehrere IAM-Seiten zu einer IAM-Kette verknüpft. Deshalb hat jede Zuordnungseinheit mindestens eine IAM-Seite für jede Datei, aus der sie Blöcke enthält. Es kann auch mehrere IAM-Seiten für eine Datei geben, wenn der Bereich der Blöcke aus der Datei, die für die Zuordnungseinheit zugeordnet ist, den Bereich übersteigt, den eine einzelne IAM-Seite aufzeichnen kann.

Diagramm, das die Verteilung von IAM-Seiten zeigt.

IAM-Seiten werden je nach Bedarf für jede Zuordnungseinheit zugeordnet und nach dem Zufallsprinzip in der Datei verteilt. Die Systemsicht sys.system_internals_allocation_units zeigt auf die erste IAM-Seite für eine Zuordnungseinheit. Alle IAM-Seiten für diese Zuordnungseinheit sind in einer IAM-Kette miteinander verknüpft.

Wichtig

Die Systemsicht sys.system_internals_allocation_units ist nur zur internen Verwendung bestimmt und kann geändert werden. Kompatibilität wird nicht sichergestellt. Diese Sicht ist in Azure SQL-Datenbanknicht verfügbar.

Diagramm, das IAM-Seiten zeigt, die in einer Kette pro Zuordnungseinheit verknüpft sind.

Eine IAM-Seite verfügt über einen Header, der den Anfangsblock des Bereichs von Blöcken kennzeichnet, die von der IAM-Seite beschrieben werden. Die IAM-Seite verfügt darüber hinaus über ein großes Bitmuster, in dem jedes Bit einen Block darstellt. Das erste Bit in dem Bitmuster stellt den ersten Block im Bereich dar, das zweite Bit stellt den zweiten Block dar usw. Wenn ein Bit ist, wird 0der Umfang, den es darstellt, nicht der Zuordnungseinheit zugeordnet, die das IAM besitzt. Wenn das Bit ist 1, wird der Umfang, den es darstellt, der Zuordnungseinheit zugeordnet, die die IAM-Seite besitzt.

Wenn die Datenbank-Engine eine neue Zeile einfügen muss und auf der aktuellen Seite kein Leerzeichen verfügbar ist, verwendet sie die IAM- und PFS-Seiten, um eine Seite zu finden, die zugeordnet werden soll, oder für einen Heap oder eine Text-/Bildseite eine Seite mit genügend Platz für die Zeile. Die Datenbank-Engine verwendet IAM-Seiten, um die Blöcke zu suchen, die für die Zuordnungseinheit zugeordnet sind. Für jeden Block durchsucht die Datenbank-Engine die PFS-Seiten, um herauszufinden, ob eine geeignete Seite vorhanden ist. Jede IAM- und PFS-Seite deckt viele Datenseiten ab, sodass es nur wenige IAM- und PFS-Seiten in einer Datenbank gibt. Dies bedeutet, dass sich die IAM- und PFS-Seiten normalerweise im Arbeitsspeicher des SQL Server-Pufferpools befinden, sodass sie schnell durchsucht werden können. Für Indizes wird die Einfügemarke für eine neue Zeile durch den Indexschlüssel festgelegt. Wenn jedoch eine neue Seite benötigt wird, wird der zuvor beschriebene Vorgang durchgeführt.

Datenbank-Engine weist eine neue Erweiterung einer Zuordnungseinheit nur dann zu, wenn eine Seite in einem vorhandenen Bereich nicht schnell gefunden werden kann, auf der genügend Platz vorhanden ist, um die eingefügte Zeile aufzunehmen.

Proportionale Füllzuordnung

Die Datenbank-Engine weist Erweiterungen aus den in der Dateigruppe verfügbaren Ausdehnungen mithilfe eines Algorithmus für die proportionale Füllzuordnung zu. Wenn eine Datei in derselben Dateigruppe mit zwei Dateien doppelt so viel freien Speicherplatz wie die andere hat, werden zwei Seiten aus der Datei mit dem verfügbaren Speicherplatz für jede Seite zugeordnet, die aus der anderen Datei zugewiesen wird. Dies bedeutet, dass der Anteil des verwendeten Speicherplatzes in allen Dateien einer Dateigruppe ähnlich groß sein sollte.

Nachverfolgen geänderter Erweiterungen

SQL Server verwendet zwei interne Datenstrukturen, um Durch Massenkopiervorgänge geänderte Ausdehnungen und Erweiterungen nachzuverfolgen, die seit der letzten vollständigen Sicherung geändert wurden. Diese Datenstrukturen beschleunigen differenzielle Sicherungen erheblich. Sie beschleunigen außerdem das Protokollieren von Massenkopiervorgängen, wenn eine Datenbank das Modell der massenprotokollierten Wiederherstellung verwendet. Wie die GAM- und SGAM-Seiten sind diese Strukturen Bitmaps, in denen jedes Bit einen einzelnen Bereich darstellt.

  • Differential Changed Map (DCM)

    DCM protokolliert die Blöcke, die seit der letzten Ausführung der BACKUP DATABASE-Anweisung geändert wurden. Wenn das Bit für einen Umfang ist 1, wurde der Ausdehnung seit der letzten BACKUP DATABASE Anweisung geändert. Wenn das Bit ist 0, wurde der Umfang nicht geändert.

    Differenzielle Sicherungen lesen nur die DCM-Seiten, um zu ermitteln, welche Blöcke geändert wurden. Dadurch wird die Anzahl an Seiten, die eine differenzielle Sicherung scannen muss, erheblich verringert. Die Dauer, die eine differenzielle Sicherung ausführt, ist proportional zur Anzahl der Erweiterungen, die seit der letzten BACKUP DATABASE Anweisung geändert wurden, und nicht der Gesamtgröße der Datenbank.

  • Bulk Changed Map (BCM)

    Dadurch werden die Ausdehnungen nachverfolgt, die von massenprotokollierten Vorgängen seit der letzten BACKUP LOG Anweisung geändert wurden. Wenn das Bit für einen Umfang ist 1, wurde der Umfang nach der letzten BACKUP LOG Anweisung durch einen Massenprotokollierungsvorgang geändert. Wenn das Bit ist 0, wurde die Ausdehnung nicht durch Massenprotokollierungsvorgänge geändert.

    BCM-Seiten treten in allen Datenbanken auf, sind jedoch nur dann relevant, wenn die Datenbank das Modell der massenprotokollierten Wiederherstellung verwendet. Wenn bei diesem Wiederherstellungsmodell eine BACKUP LOG-Anweisung ausgeführt wird, scannt der Sicherungsvorgang die BCM-Seiten nach Blöcken, die geändert wurden. Diese Blöcke werden dann in die Protokollsicherung eingeschlossen. Dadurch werden die Massenprotokollierungsvorgänge wiederhergestellt, wenn die Datenbank aus einer Datenbanksicherung und einer Sequenz von Transaktionsprotokollsicherungen wiederhergestellt wird. BCM-Seiten sind in einer Datenbank, die das einfache Wiederherstellungsmodell verwendet, nicht relevant, da keine Massenprotokollierungsvorgänge protokolliert werden. Sie sind in einer Datenbank, die das vollständige Wiederherstellungsmodell verwendet, nicht relevant, da dieses Wiederherstellungsmodell Massenprotokollierungsvorgänge als vollständig protokollierte Vorgänge behandelt.

Der Abstand zwischen DCM-Seiten und BCM-Seiten ist derselbe Abstand wie zwischen GAM- und SGAM-Seiten; 64.000 Blöcke. Die DCM- und BCM-Seiten befinden sich wie folgt hinter den Seiten GAM und SGAM in einer physischen Datei:

Diagramm, das die Intervallverteilung von Sonderseiten zeigt.

Weitere Informationen