Leitfaden zur Seiten- und Umfangsarchitektur

Gilt für:SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceAzure Synapse AnalyticsAnalytics Platform System (PDW)SQL-Datenbank in Microsoft Fabric

In diesem Leitfaden wird die Struktur von Seiten und Erweiterungen sowie die Organisation von Seiten und Erweiterungen in Datendateien beschrieben.

Eine Seite ist eine grundlegende Einheit der Datenspeicherung im Datenbankmodul. Der Speicherplatz, der einer Datendatei (MDF- oder NDF-Datei) in einer Datenbank zugeordnet wird, ist logisch in Seiten unterteilt, die fortlaufend von 0 bis n nummeriert sind. Festplatten-E/A-Vorgänge für Datendateien werden auf Seitenebene ausgeführt. Das Heißt, das Datenbankmodul liest oder schreibt ganze Datenseiten.

Ein Extens ist eine Sammlung von acht physisch zusammenhängenden Seiten, die zur effizienten Verwaltung von Seiten verwendet werden. Jede Seite gehört zu einem Umfang.

Transaktionsprotokolldateien (LDF) enthalten keine Seiten. Sie enthalten eine Reihe von Protokolldatensätzen, die keine feste Größe aufweisen.

Seiten

In einem normalen Buch ist der gesamte Inhalt auf Seiten geschrieben. Ähnlich wie bei einem Buch schreibt das Datenbankmodul alle Datenzeilen auf Seiten. Die Größe jeder Seite ist identisch: 8 KiB. In einem Buch enthalten die meisten Seiten die Daten oder den Hauptinhalt des Buchs. Einige Seiten enthalten Metadaten, die den Inhalt beschreiben, z. B. das Inhaltsverzeichnis und den Index.

Ebenso enthalten die meisten Seiten in der Datenbank tatsächliche Datenzeilen. Diese werden als Datenseiten bezeichnet. Text-/LOB-Seiten enthalten auch Daten, werden jedoch nur von Datentypen für Large Objects (LOB) verwendet. Indexseiten enthalten Indexstrukturen, mit denen Daten effizient gefunden werden können. Schließlich werden auf einer Vielzahl von Systemseiten die Metadaten gespeichert, die die Organisation und die Eigenschaften der Daten beschreiben.

In der folgenden Tabelle werden Seitentypen beschrieben.

Jede Seite beginnt mit einem 96 Byte umfassenden Header, der zum Speichern von Systeminformationen zu der betreffenden Seite verwendet wird. Diese Informationen umfassen die Seitenzahl, den Seitentyp und können andere Metadaten wie die Objekt-ID und die Index-ID des Objekts und den Index enthalten, der die Seite besitzt.

Eine Struktur, die als Slotarray bezeichnet wird, wird am Ende der Seite gespeichert. Jedes 2-Byte-Element im Slotarray entspricht einer Zeile, die auf der Seite gespeichert ist. Ein Slot-Array-Element speichert den Byte-Offset der Zeile relativ zum Anfang der Seite. Das Datenbankmodul verwendet diese Offsets, um Zeilen auf einer Seite zu suchen.

Wenn das Datenbankmodul eine Zeile zu einer leeren Seite hinzufügt, speichert es die Zeile unmittelbar nach der Kopfzeile. Das Slotarray-Element für die erste Zeile wird am Ende der Seite gespeichert. Wenn weitere Zeilen hinzugefügt werden, werden sie von Anfang bis Ende der Seite nacheinander gespeichert, während das Slotarray vom Ende bis zum Anfang der Seite wächst, wie im folgenden Diagramm dargestellt.

Wenn Zeilen auf einer Seite im Laufe der Zeit gelöscht oder aktualisiert werden, kann freier Speicherplatz unter den verbleibenden Zeilen angezeigt werden. Wenn eine neue Zeile hinzugefügt wird, wird sie möglicherweise in diesem freien Speicherplatz gespeichert, wenn der Speicherplatz ausreicht. Dies bedeutet, dass Zeilen auf einer Seite möglicherweise nicht physisch in einer bestimmten Reihenfolge gespeichert werden. Das Datenbankmodul behält jedoch die Einträge des Slotarrays in einer logischen Reihenfolge bei. Daher wird auch auf Zeilen auf einer Seite in einer logischen Reihenfolge zugegriffen, z. B. die durch den Schlüssel des BTree-Index definierte Reihenfolge, die die Seite besitzt.

Unterstützung von umfangreichen Zeilen

Um große Zeilen zu unterstützen, die nicht auf eine einzelne Seite passen, kann der Teil der Zeile, der nicht passt, auf anderen Seiten gespeichert werden. Die maximale Größe von Daten und Mehraufwand, die in einer einzelnen Zeile auf einer Seite enthalten sein kann, beträgt 8.060 Byte.

Die 8,060-Byte-Einschränkung gilt nicht für Daten in Spalten, die LOB-Datentypen verwenden. Standardmäßig werden die Daten für solche Spalten in Zeile gespeichert, wenn genügend Speicherplatz vorhanden ist. Andernfalls enthält die Zeile einen 16-Byte-Zeiger auf einen separaten Baum von Text-/LOB-Seiten, die die LOB-Daten in einer LOB_DATA Zuordnungseinheit speichern. Die large value types out of rowTabellenoption steuert dieses Verhalten.

Die 8.060-Byte-Einschränkung wird für Tabellen und Indizes, die variable Längenspalten enthalten, aufgehoben, wenn diese die Datentypen varchar, nvarchar, varbinary, sql_variant oder benutzerdefinierte CLR-Typen verwenden. Wenn die Gesamtzeilengröße aller Spalten mit fester und variabler Länge in einem Heap oder Index die Einschränkung von 8.060 Byte überschreitet, verschiebt das Datenbankmodul dynamisch eine oder mehrere Spalten mit variabler Länge auf Seiten in einer ROW_OVERFLOW_DATA Zuordnungseinheit, beginnend mit der breitesten Spalte.

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 einer ROW_OVERFLOW_DATA Zuordnungseinheit verschoben wird, wird ein 24-Byte-Zeiger auf der ursprünglichen Seite in einer IN_ROW_DATA Zuordnungseinheit beibehalten. Wenn durch einen nachfolgenden Vorgang die Zeilengröße reduziert wird, verschiebt das Datenbankmodul die Spalten dynamisch zurück zur ursprünglichen Datenseite.

Beispielsweise kann eine Tabelle mit zwei Spalten erstellt werden: eine varchar(7000) und eine andere varchar(2000). Einzeln überschreitet keine Spalte 8.060 Byte, aber kombiniert würden sie dies tun, wenn die gesamte Breite jeder Spalte gefüllt ist. In diesem Fall verschiebt das Datenbankmodul die variable Längenspalte varchar(7000) dynamisch von der ursprünglichen Seite auf die Seiten in einer ROW_OVERFLOW_DATA Zuordnungseinheit.

Wenn eine Tabelle oder ein Index varchar-, nvarchar-, varbinary-, sql_variant- oder CLR-Benutzerdefinierte Typspalten aufweist, die 8.060 Byte pro Zeile überschreiten können, beachten Sie Folgendes:

• Das Dynamische Verschieben großer Zeilen auf eine andere Seite erfolgt, wenn Zeilen basierend auf Aktualisierungsvorgängen verlängert werden. Aktualisierungsvorgänge, die Zeilen verkürzen, können dazu führen, dass sie in einer IN_ROW_DATA Zuordnungseinheit zurück zur ursprünglichen Seite verschoben werden.

  Diese Datenverschiebung führt zu einer zusätzlichen Datenträger-E/A. Abfrageverarbeitungsvorgänge wie Sortierungen oder Verknüpfungen für große Datensätze, die Zeilenüberlaufdaten enthalten, können langsamer sein.

  Berücksichtigen Sie daher beim Entwerfen einer Tabelle mit mehreren Varchar-, nvarchar-, varbinary-, sql_variant- oder CLR-Benutzerdefinierten Typspalten den Prozentsatz der Zeilen, die wahrscheinlich überlaufen werden, und die Häufigkeit, mit der diese Überlaufdaten wahrscheinlich abgefragt werden. Um eine langsamere Leistung zu vermeiden, normalisieren Sie die Tabelle, um einige dieser Spalten in eine andere Tabelle zu verschieben, um die Wahrscheinlichkeit der Verwendung von Zeilenüberlaufspeicher zu verringern oder zu vermeiden.

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

• Die Summe der Längen anderer Datentypspalten, z. B. char, nchar und int-Daten, muss weiterhin innerhalb des Zeilenlimits von 8.060 Byte liegen. Spalten, die die LOB-Datentypen wie varchar(max), nvarchar(max) und varbinary(max) verwenden, sind jedoch vom Grenzwert von 8.060 Byte-Zeilen ausgenommen.

• Der Indexschlüssel eines gruppierten Indexes darf keine Varcharspalten enthalten, die Daten in einer ROW_OVERFLOW_DATA Zuordnungseinheit enthalten. Wenn ein gruppierter Index in einer Varchar-Spalte erstellt wird und sich alle vorhandenen Daten in einer IN_ROW_DATA Zuordnungseinheit befinden, aber eine nachfolgende INSERT oder UPDATE Anweisung die Daten außerhalb der Zeile verschiebt, schlägt die Anweisung fehl. Weitere Informationen finden Sie in der Indexarchitektur und im Entwurfshandbuch.

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

• Die Zeilengrößenbeschränkung für Tabellen, die geringe Spalten verwenden, beträgt 8.018 Byte. Wenn die konvertierten Daten plus vorhandene Daten 8.018 Byte überschreiten, wird fehler 576 während der Konvertierung zwischen sparse- und nichtsparse-Spalten zurückgegeben. Wenn Spalten zwischen Sparse- und Nichtsparsetypen konvertiert werden, behält das Datenbankmodul eine Kopie der aktuellen Zeilendaten bei. Dadurch wird der für die Zeile erforderliche Speicher vorübergehend verdoppelt.

• 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. Ein Index oder eine Partition enthält Zeilenüberlaufdaten, wenn die Funktion Zeilen zurückgibt, in denen sich die alloc_unit_type_desc Spalte befindet ROW_OVERFLOW_DATA und die page_count Spalte größer als 0 ist.

Extents

Ein Umfang ist eine Sammlung von acht physisch zusammenhängenden Seiten. Die Größe jedes Speicherbereichs beträgt 64 KiB.

Es gibt zwei Arten von Erweiterungen:

• Einheitliche Extents gehören einem einzelnen Objekt, z. B. einer einzelnen Tabelle; alle acht Seiten können nur von dem zugehörigen 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.

Bis zu und einschließlich SQL Server 2014 (12.x) weist das Datenbankmodul keine einheitlichen Ausmaße für Tabellen mit kleinen Datenmengen zu. Ein neuer Heap oder Index weist Seiten aus gemischten Ausmaßen zu. Wenn der Heap oder Index zu dem Punkt wächst, an dem er acht Seiten verwendet, wechselt er für alle nachfolgenden Zuordnungen zu einheitlichen Extents. 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) verwendet das Datenbankmodul einheitliche Ausmaße für Zuordnungen in einer Benutzerdatenbank und in tempdb, mit Ausnahme von Zuordnungen, die zu den ersten acht Seiten einer IAM-Kette gehören. Zuordnungen in den master, msdb und model Datenbanken behalten weiterhin ihr vorheriges Verhalten bei.

Bis einschließlich SQL Server 2014 (12.x), können Sie das Ablaufverfolgungsflag (TF) 1118 verwenden, um die Standardzuordnung so zu ändern, dass immer einheitliche Erweiterungen verwendet werden. Weitere Informationen zu diesem Trace-Flag finden Sie unter Trace-Flag 1118.

Ab SQL Server 2016 (13.x) hat TF 1118 keine Auswirkung. Die Funktionalität, die von TF 1118 zuvor bereitgestellt wurde, ist jetzt automatisch für alle Benutzerdatenbanken und für tempdb aktiviert. Bei Benutzerdatenbanken kann dieses Verhalten durch die MIXED_PAGE_ALLOCATION Datenbankoption gesteuert werden. Der Standardwert lautet OFF, was bedeutet, dass einheitliche Ausmaße verwendet werden. Weitere Informationen finden Sie unter ALTER DATABASE SET-Optionen.

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.

Ab SQL Server 2019 (15.x) gibt die sys.dm_db_page_info Systemfunktion Informationen zu einer Seite in einer Datenbank zurück. Die Funktion gibt eine Zeile zurück, die Seitenkopfdaten enthält, einschließlich objekt-ID, Index-ID und Partitions-ID. In vielen Fällen kann diese Funktion als unterstützte Alternative für den nicht unterstützten DBCC PAGE Befehl verwendet werden.

Systemseiten

Jede Datendatei enthält eine kleine Anzahl spezieller Systemseiten, die die Metadaten nachverfolgen, die Umfang und Seiten beschreiben. Systemseiten verfolgen z. B., welche Ausmaße in einer Datendatei zugeordnet werden, und wie viel Freier Speicherplatz seiten haben. In diesem Abschnitt werden diese Systemseiten beschrieben.

GAM- und SGAM-Seiten

Das Datenbankmodul verwendet zwei Arten von Zuordnungskarten, um die Zuordnung von Extents aufzuzeichnen.

• Global Allocation Map (GAM)

  GAM-Seiten erfassen, welche Extents zugewiesen wurden. Jede GAM-Seite behandelt ein Intervall von ca. 64.000 Ausmaßen oder etwa 4 Gigabyte (GiB) von Daten, die als GAM-Intervall bezeichnet werden. Die GAM-Seite hat 1 Bit für jede Erweiterung in dem von ihr abgedeckten Intervall. Hat das Bit den Wert 1, ist der Block frei; hat das Bit den Wert 0, ist der Block 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-Seite deckt auch ein Intervall von ungefähr 64.000 Seiten oder etwa 4 GiB Daten ab. Die SGAM verfügt über ein Bit für jeden Block in dem von ihr abgedeckten Intervall. Wenn das Bit den Wert 1 hat, wird der Block als gemischter Block verwendet und verfügt über eine freie Seite. Wenn das Bit lautet 0, wird der Umfang nicht als gemischtes Ausmaß verwendet oder ist ein gemischtes Ausmaß, in dem alle Seiten verwendet werden.

In jedem Umfang werden die folgenden Bitmuster auf den GAM- und SGAM-Seiten basierend auf der aktuellen Verwendung festgelegt.

Um Extents zu verwalten, verwendet die Datenbank-Engine die folgenden konzeptionellen Algorithmen:

• Um ein einheitliches Ausmaß zuzuweisen, durchsucht das Datenbankmodul die GAM-Seite nach einem 1 Bit und setzt es auf 0.
• Um einen gemischten Bereich mit freien Seiten zu finden, durchsucht das Datenbankmodul die SGAM-Seite nach einem 1-Bit.
• Um ein gemischtes Extent zuzuweisen, durchsucht das Datenbankmodul die GAM-Seite nach einem 1 Bit, setzt es auf 0 und setzt dann auch das entsprechende Bit auf der SGAM-Seite auf 1.
• Um einen Abschnitt freizugeben, stellt das Datenbankmodul sicher, dass das Bit auf der GAM-Seite auf 1 gesetzt ist und das Bit auf der SGAM-Seite auf 0.

Proportionale Füllzuordnung

Die Datenbank-Engine ordnet Blöcke auf der Basis der verfügbaren Blöcke in der Dateigruppe zu und verwendet dazu einen proportionalen Zuordnungsalgorithmus. Wenn in einer Dateigruppe mit zwei Dateien beispielsweise doppelter Freier Speicherplatz vorhanden ist, werden zwei Seiten aus dieser Datei für jede Seite zugewiesen, die der anderen Datei zugeordnet ist. Dies bedeutet, dass alle Dateien in einer Dateigruppe mit einem ähnlichen Prozentsatz des verwendeten Speicherplatzes enden, wenn die Zuordnungen fortgesetzt werden.

Weitere Informationen finden Sie unter Datei- und Dateigruppenfüllstrategie.

PFS-Seiten

Seiten mit freiem Speicherplatz (PFS) zeichnen den Zuordnungsstatus jeder Seite und die Menge des freien Speicherplatzes auf jeder Seite auf. Eine PFS-Seite hat 1 Byte für jede Seite, die sie nachverfolgt. Das Byte zeichnet auf, ob die Seite zugeordnet ist, und wenn ja, ob es leer ist, 1 bis 50 Prozent voll, 51 bis 80 Prozent voll, 81 bis 95 Prozent voll oder 96 bis 100 Prozent voll.

Nachdem einem Objekt ein Umfang zugewiesen wurde, verwendet das Datenbankmodul PFS-Seiten, um nachzuverfolgen, welche Seiten im Umfang Daten haben oder frei sind. Diese Informationen werden verwendet, wenn das Datenbankmodul eine neue Seite zuweist. Der freie Speicherplatz auf einer Seite wird nur für Heap- und Text-/LOB-Seiten verwaltet. Diese Informationen werden verwendet, wenn das Datenbankmodul eine Seite mit genügend freiem Speicherplatz finden muss, um eine neu eingefügte Zeile zu speichern.

BTree-Indizes erfordern keine Nachverfolgung von seitenfreiem Speicherplatz, da der Punkt, an dem eine neue Zeile eingefügt werden soll, immer durch die Indexschlüsselwerte bestimmt wird. Wenn eine Seite in einem BTree-Index nicht über genügend freien Speicherplatz verfügt, wird eine neue Seite hinzugefügt, und ungefähr die Hälfte der ursprünglichen Seitendaten wird auf die neue Seite verschoben.

GAM- und PFS-Intervalle

Eine neue PFS-, GAM- oder SGAM-Seite wird in der Datendatei für jeden zusätzlichen Bereich hinzugefügt, den er nachverfolgt.

Es gibt eine neue PFS-Seite 8.088 Seiten nach der ersten PFS-Seite und zusätzliche PFS-Seiten in nachfolgenden 8.088 Seitenintervallen. In einer Datendatei ist seiten-ID 1 eine PFS-Seite, Die Seiten-ID 8088 ist eine PFS-Seite, die Seiten-ID 16176 ist eine PFS-Seite usw.

Ebenso gibt es ein Paar GAM- und SGAM-Seiten, die bei den Seiten 2 bzw. 3 beginnen und sich für jedes GAM-Intervall von ca. 64.000 Erweiterungen oder 4 GiB wiederholen.

Das folgende Diagramm zeigt das erste Vorkommen von PFS-, GAM- und SGAM-Seiten am Anfang einer Datendatei nach der Dateikopfseite. Während die Datei wächst, werden neue PFS-, GAM- und SGAM-Seiten in ihren jeweiligen Intervallen angezeigt.

IAM-Seiten

Eine Index Allocation Map (IAM)-Seite verweist auf die Extents, die von einer Zuordnungseinheit in einem GAM-Intervall verwendet werden. Eine Zuordnungseinheit ist einer Partition eines Heaps oder Index zugeordnet und kann einer von drei Typen sein:

• IN_ROW_DATA

  Enthält Datenseiten, die keine LOBs sind, oder Teile von LOB-Daten, die möglicherweise in eine Zeile passen.

• LOB_DATA

  Enthält LOB-Datenseiten, die von Datentypen wie varchar(max), nvarchar(max), varbinary(max), xml und json verwendet werden.

• ROW_OVERFLOW_DATA

  Enthält LOB-Datenseiten für Datentypen mit variabler Länge wie varchar, nvarchar, varbinary oder sql_variant, wenn die Daten die Zeilengrößenbeschränkung von 8.060 Byte überschreiten.

Jede Partition eines Heaps oder Indexes enthält immer mindestens eine IN_ROW_DATA Zuordnungseinheit. Es kann auch LOB_DATA und ROW_OVERFLOW_DATA Zuweisungseinheiten enthalten, je nach den Datentypen und den Zeilengrößen, die in der Partition vorhanden sind.

Ähnlich wie bei einer GAM- oder SGAM-Seite deckt eine IAM-Seite ein 4-GiB-Intervall in einer Datei ab. Wenn die Zuordnungseinheit Ausdehnungen aus mehreren Dateien oder mehr als einem 4-GiB-Intervall einer Datei enthält, werden mehrere IAM-Seiten in einer IAM-Kette verknüpft. Daher verfügt jede Zuordnungseinheit über mindestens eine IAM-Seite für jede Datei, in der sie Ausdehnungen hat. Es kann auch mehr als eine IAM-Seite in einer Datei geben, wenn der Bereich der Zuweisungseinheit in der Datei den Bereich überschreitet, den eine einzelne IAM-Seite aufzeichnen kann. Eine IAM-Seite in einer Datei kann Erweiterungen in dieser Datei und in jeder anderen Datei derselben Datenbank verfolgen.

Im Gegensatz zu PFS-, GAM- und SGAM-Seiten, die in festen Intervallen wiederholt werden, werden die IAM-Seiten nach Bedarf für jede Zuordnungseinheit zugewiesen. 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.

Eine IAM-Seite verfügt über eine Kopfzeile, die den Anfangsumfang des Bereichs der von dieser Seite zugeordneten Bereiche angibt. Eine IAM-Seite verfügt auch über eine Bitmap, in der jedes Bit einen Bereich 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 0, wird der Umfang, den es darstellt, nicht der Zuordnungseinheit zugeordnet, die die IAM-Seite besitzt. Wenn das Bit den Wert 1 hat, ist der Block, den es darstellt, für die Zuordnungseinheit zugeordnet, die die IAM-Seite besitzt.

Wenn das Datenbankmodul eine neue Zeile einfügen muss und auf der aktuellen Seite kein Speicherplatz verfügbar ist, verwendet es die IAM- und PFS-Seiten, um eine Seite zu finden und die Zeile zuzuweisen. Bei Heap- oder Text-/LOB-Seiten verwendet er auf ähnliche Weise die IAM- und PFS-Seiten, um eine Seite mit ausreichend Platz für die Zeile zu finden. Das Datenbankmodul verwendet IAM-Seiten, um die für die Zuordnungseinheit zugeordneten Ausmaße zu ermitteln. Für jeden Bereich durchsucht sie die PFS-Seiten, um zu prüfen, ob eine Seite genutzt werden kann.

Bei BTree-Indizes wird der Einfügepunkt einer neuen Zeile durch den Indexschlüssel bestimmt, aber wenn eine neue Seite benötigt wird, kommt der zuvor beschriebene Prozess zum Tragen.

Das Datenbankmodul weist einer Allokationseinheit eine neue Erweiterungseinheit zu, wenn in einer vorhandenen Erweiterungseinheit nicht schnell eine Seite mit ausreichend Platz gefunden werden kann, um die einzufügende Zeile aufzunehmen.

DCM- und BCM-Seiten

Das Datenbankmodul verwendet zwei Arten von Systemseiten, um Erweiterungen, die seit der letzten vollständigen Sicherung geändert wurden, und Erweiterungen, die durch Massenkopiervorgänge geändert wurden, nachzuverfolgen.

Differential Changed Map (DCM)-Seiten beschleunigen differenzielle Sicherungen. Die Massenänderungszuordnung (Bulk Changed Map, BCM) beschleunigt Massenkopievorgänge, wenn eine Datenbank das Massenprotokollierungsmodell verwendet. Ähnlich wie bei den GAM-Seiten und den SGAM-Seiten handelt es sich bei diesen Strukturen um Bitmuster, wobei jedes Bit einen einzelnen Block darstellt.

• DCM-Seiten

  Diese Seiten verfolgen die Ausmaße, die seit der letzten vollständigen Datenbanksicherung geändert wurden. Wenn das Bit für ein Ausmaß ist 1, wurde das Ausmaß geändert. Falls das Bit den Wert 0 aufweist, wurde der Block nicht geändert.

  Differenzielle Sicherungen lesen die DCM-Seiten, um zu ermitteln, welche Bereiche geändert wurden. Dadurch wird die Anzahl der Seiten reduziert, die eine differenzielle Sicherung lesen und schreiben muss. Die Dauer, die eine differenzielle Sicherung benötigt, ist proportional zur Anzahl der Seit der letzten vollständigen Datenbanksicherung geänderten Ausmaße und nicht der Gesamtgröße der Datenbank.

• BCM-Seiten

  Auf diesen Seiten werden die Ausmaße nachverfolgt, die seit der letzten Sicherung des Transaktionsprotokolls durch Massenprotokollvorgänge geändert wurden. Wenn das Bit für ein Ausmaß ist 1, wurde das Ausmaß geändert. Falls das Bit den Wert 0 aufweist, wurde der Block nicht geändert.

  Obwohl BCM-Seiten in allen Datenbanken angezeigt werden, sind sie nur relevant, wenn die Datenbank das Massenwiederherstellungsmodell verwendet. In diesem Wiederherstellungsmodell überprüft der Sicherungsvorgang bei der Ausführung einer Transaktionsprotokollsicherung BCM-Seiten nach Bereichen, die geändert wurden. Sie umfasst diese Bereiche in der Protokollsicherung, um die Wiederherstellung zu ermöglichen, wenn die Datenbank aus einer Datenbanksicherung wiederhergestellt wird und eine Sequenz von Transaktionsprotokollsicherungen vorliegt.

  BCM-Seiten sind in einer Datenbank, die das einfache Wiederherstellungsmodell verwendet, nicht relevant, da massenprotokollierte Vorgänge nicht vollständig protokolliert werden. Sie sind auch nicht relevant in einer Datenbank, die das vollständige Wiederherstellungsmodell verwendet, da dieses Wiederherstellungsmodell massenprotokollierte Vorgänge als vollständig protokolliert behandelt.

Die DCM- und BCM-Seiten werden in den gleichen GAM-Intervallen von ca. 4 GiB gespeichert wie die GAM- und SGAM-Seiten. Die DCM- und BCM-Seiten folgen den GAM- und SGAM-Seiten in einer physischen Datei.

Zugehöriger Inhalt

• Grundlagen zu SQL Server-E/A
• sys.allocation_units (Transact-SQL)
• Heaps (Tabellen ohne gruppierte Indizes)
• sys.dm_db_page_info (Transact-SQL)
• Lesen von Datenseiten im Datenbankmodul
• Schreiben von Seiten im Datenbankmodul