Haltbarkeit für speicheroptimierte Tabellen

Gilt für:SQL Server

In-Memory-OLTP bietet vollständige Dauerhaftigkeit für speicheroptimierte Tabellen. Wenn eine Transaktion, die eine speicheroptimierte Tabelle geändert hat, abgeschlossen wird, garantiert SQL Server (vergleichbar mit datenträgerbasierten Tabellen), dass die Änderungen dauerhaft sind (sie überstehen einen Neustart der Datenbank), sofern der zugrunde liegende Speicher verfügbar ist. Die Dauerhaftigkeit basiert auf zwei Hauptmechanismen: der Transaktionsprotokollierung und der dauerhaften Speicherung von Datenänderungen auf einem Datenträger.

Ausführliche Informationen zu größenbeschränkungen für dauerhafte Tabellen finden Sie unter Schätzen der Speicheranforderungen für Memory-Optimized Tabellen.

Transaktionsprotokoll

Alle Änderungen, die an datenträgerbasierten oder dauerhaften speicheroptimierten Tabellen vorgenommen werden, werden in einem oder mehreren Transaktionsprotokoll-Datensätzen erfasst. Wenn für eine Transaktion ein Commit ausgeführt wird, werden die mit der Transaktion verknüpften Protokolldatensätze von SQL Server auf den Datenträger geschrieben, bevor der Anwendung oder Benutzersitzung mitgeteilt wird, dass der Commit für die Transaktion abgeschlossen wurde. So wird sichergestellt, dass die von der Transaktion vorgenommenen Änderungen dauerhaft sind. Das Transaktionsprotokoll für speicheroptimierte Tabellen ist vollständig in den Protokolldatenstrom integriert, der auch von datenträgerbasierten Tabellen verwendet wird. Diese Integration ermöglicht es, dass bestehende Transaktionsprotokollsicherungs-, Wiederherstellungs- und Wiederherstellungsvorgänge weiterhin ohne zusätzliche Schritte funktionieren. Da In-Memory OLTP jedoch den Transaktionsdurchsatz Ihrer Workload erheblich erhöhen kann, kann die Protokoll-E/A zu einem Leistungsengpass werden. Um den erhöhten Durchsatz nachhaltig bewältigen zu können, müssen Sie sicherstellen, dass das Protokoll-E/A-Subsystem die höhere Last verarbeiten kann.

Daten- und Deltadateien

Die Daten in speicheroptimierten Tabellen werden als Freiform-Datenzeilen in einer In-Memory-Heap-Datenstruktur gespeichert, die durch mindestens einen Index im Arbeitsspeicher verknüpft sind. Datenzeilen weisen im Gegensatz zu datenträgerbasierten Tabellen keine Seitenstrukturen auf. Für die langfristige Persistenz und um die Kürzung des Transaktionsprotokolls zu ermöglichen, werden Vorgänge auf speicheroptimierten Tabellen in einem Satz von Daten- und Delta-Dateien persistiert. Diese Dateien werden mithilfe eines asynchronen Hintergrundprozesses auf Basis des Transaktionsprotokolls generiert. Die Daten- und Änderungsdateien sind in einem oder mehreren Containern enthalten (und nutzen denselben Mechanismus wie für FILESTREAM-Daten). Diese Container sind Teil einer speicheroptimierten Dateigruppe.

Daten werden in diese Dateien streng sequenziell geschrieben. Dadurch wird die Datenträgerlatenz für herkömmliche Medien minimiert. Sie können mehrere Container auf verschiedenen Datenträgern verwenden, um die E/A-Aktivität zu verteilen. Daten- und Deltadateien in mehreren Containern auf unterschiedlichen Datenträgern erhöhen die Leistung der Wiederherstellung der Datenbank, wenn Daten von den Daten- und Deltadateien auf dem Datenträger in den Speicher gelesen werden.

Benutzertransaktionen greifen nicht direkt auf Daten und Deltadateien zu. Alle Datenlese- und -schreibvorgänge verwenden speicherinterne bzw. In-Memory-Datenstrukturen.

Die Datendatei

Eine Datendatei enthält Zeilen aus einer oder mehreren speicheroptimierten Tabellen, die von mehreren Transaktionen als Teil INSERT oder UPDATE Vorgänge eingefügt wurden. Beispielsweise können eine Zeile aus der speicheroptimierten Tabelle T1 und die nächste Zeile aus der speicheroptimierten Tabelle T2 stammen. Die Zeilen werden an die Datendatei in der Transaktionsreihenfolge im Transaktionsprotokoll angefügt, sodass sequenzieller Datenzugriff gewährleistet wird. Dies ermöglicht einen im Vergleich zu wahlfreiem I/O um eine Größenordnung höheren I/O-Durchsatz.

Sobald die Datendatei voll ist, werden die Zeilen, die durch neue Transaktionen eingefügt werden, in einer weiteren Datendatei gespeichert. Im Laufe der Zeit werden die Zeilen aus dauerhaften speicheroptimierten Tabellen in einer von mehreren Datendateien gespeichert, und jede Datendatei, die Zeilen enthält, bilden einen nicht zusammenhängenden, aber zusammenhängenden Bereich von Transaktionen. Beispielsweise enthält eine Datendatei, deren Zeitstempel für den Transaktionscommit im Bereich (100, 200) liegt, alle Zeilen, die von Transaktionen mit einem Commitzeitstempel größer als 100 und kleiner oder gleich 200 eingefügt wurden. Der Commit-Zeitstempel ist eine monoton steigende Zahl, die einer Transaktion zugewiesen ist, wenn sie bereit ist, einen Commit durchzuführen. Jede Transaktion besitzt einen eindeutigen Commitzeitstempel.

Wenn eine Zeile gelöscht oder aktualisiert wird, wird die Zeile nicht entfernt oder in der Datendatei geändert, aber die gelöschten Zeilen werden in einem anderen Dateityp nachverfolgt: die Delta-Datei. Updatevorgänge werden für jede einzelne Zeile als Tupel von Lösch- und Einfügevorgängen verarbeitet. Dadurch werden zufällige E/A-Vorgänge für die Datendatei verhindert.

Größe: Auf Computern mit einer Arbeitsspeicherkapazität über 16 GB beträgt die Größe jeder Datendatei ungefähr 128 MB, und auf Computern mit einer Arbeitsspeicherkapazität bis 16 GB beträgt die Größe 16 MB. In SQL Server 2016 (13.x) kann der Modus für große Prüfpunkte verwendet werden, wenn SQL Server das Speichersubsystem für ausreichend schnell hält. Im Modus für große Prüfpunkte haben die Datendateien eine Größe von 1 GB. So wird für Arbeitsauslastungen mit hohem Durchsatz eine höhere Effizienz im Speichersubsystem möglich.

Die Delta-Datei

Jeder Datendatei wird eine Delta-Datei mit demselben Transaktionsbereich zugeordnet, die die von Transaktionen in diesem Transaktionsbereich gelöschten Zeilen erfasst. Diese Daten- und Delta-Datei wird als Prüfpunktdateipaar (Checkpoint File Pair, CFP) bezeichnet und ist die Einheit für Zuordnung und Deallocation sowie die Einheit für Zusammenführungsvorgänge. Beispielsweise speichert eine Delta-Datei, die dem Transaktionsbereich (100, 200) entspricht, gelöschte Zeilen, die von Transaktionen im Bereich eingefügt wurden (100, 200). Wie Datendateien wird auf die Delta-Datei sequenziell zugegriffen.

Wenn eine Zeile gelöscht wird, wird die Zeile nicht aus der Datendatei entfernt, aber ein Verweis auf die Zeile wird an die Delta-Datei angefügt, die dem Transaktionsbereich zugeordnet ist, in den diese Datenzeile eingefügt wurde. Da die zu löschende Zeile bereits in der Datendatei vorhanden ist, speichert die Delta-Datei nur die Verweisinformationen {inserting_tx_id, row_id, deleting_tx_id}, und diese folgen der Reihenfolge im Transaktionsprotokoll der ursprünglich auslösenden Lösch- oder Aktualisierungsvorgänge.

Größe: Jede Delta-Datei ist auf Computern mit mehr als 16 GB Arbeitsspeicher ungefähr 16 MB groß und auf Computern mit 16 GB oder weniger Arbeitsspeicher 1 MB. Ab SQL Server 2016 (13.x) kann der Modus für große Prüfpunkte verwendet werden, wenn SQL Server das Speichersubsystem für ausreichend schnell hält. Im großen Checkpoint-Modus haben Delta-Dateien eine Größe von 128 MB.

Auffüllen von Daten- und Deltadateien

Daten- und Delta-Datei werden auf Grundlage der Transaktionsprotokolldatensätze gefüllt, die von bestätigten Transaktionen für speicheroptimierte Tabellen erzeugt werden, und hängen Informationen zu den eingefügten und gelöschten Zeilen an die entsprechenden Daten- und Delta-Dateien an. Im Gegensatz zu datenträgerbasierten Tabellen, bei denen Daten-/Indexseiten durch zufällige E/A-Vorgänge auf den Datenträger geschrieben werden, wenn ein Prüfpunkt ausgeführt wird, erfolgt die Persistenz der speicheroptimierten Tabellen als kontinuierlicher Hintergrundvorgang. Es wird auf mehrere Delta-Dateien zugegriffen, da eine Transaktion jede Zeile löschen oder aktualisieren kann, die von einer vorherigen Transaktion eingefügt wurde. Löschinformationen werden immer am Ende der Delta-Datei angefügt. Beispielsweise fügt eine Transaktion mit einem Commit-Zeitstempel von 600 eine neue Zeile ein und löscht Zeilen, die von Transaktionen mit einem Commit-Zeitstempel von 150, 250 und 450 eingefügt wurden, wie in der folgenden Abbildung dargestellt. Alle vier Datei-E/A-Vorgänge (drei für gelöschte Zeilen und eine für die neu eingefügten Zeilen) sind Anfügevorgänge, die nur an die entsprechenden Delta- und Datendateien gerichtet sind.

Zugreifen auf Daten und Delta-Dateien

Auf Daten- und Delta-Dateipaare wird zugegriffen, wenn die folgenden Ereignisse auftreten.

Mitarbeiter für Offline-Kontrollpunkte

Dieser Thread fügt Einfüge- und Löschvorgänge für speicheroptimierte Datenzeilen an die entsprechenden Daten- und Delta-Dateipaare an. SQL Server 2014 (12.x) verfügt über einen Offline-Checkpoint-Worker. SQL Server 2016 (13.x) und höhere Versionen verfügen über mehrere Prüfpunktmitarbeiter.

Zusammenführungsvorgang

Der Vorgang führt ein oder mehrere Paare aus Daten- und Änderungsdateien zusammen und erstellt ein neues Paar aus Daten- und Änderungsdatei.

Während der Wiederherstellung nach einem Absturz

Wenn SQL Server neu gestartet oder die Datenbank wieder online gebracht wird, werden die speicheroptimierten Daten anhand der Daten- und Deltadateipaare wiederhergestellt. Die Delta-Datei dient beim Lesen der Zeilen aus der zugehörigen Datendatei als Filter für die gelöschten Zeilen. Da jedes Daten- und Deltadateipaar unabhängig ist, werden diese Dateien parallel geladen, um die Zeit zu verkürzen, die zum Laden der Daten in den Arbeitsspeicher benötigt wird. Sobald die Daten in den Arbeitsspeicher geladen wurden, wendet das In-Memory OLTP-Modul die aktiven Transaktionsprotokolleinträge an, die noch nicht von den Prüfpunktdateien abgedeckt sind, damit die speicheroptimierten Daten abgeschlossen sind.

Während des Wiederherstellungsvorgangs

Die In-Memory OLTP-Prüfpunktdateien werden aus der Datenbanksicherung erstellt. Anschließend wird mindestens eine Transaktionsprotokollsicherung angewendet. Wie bei der Absturzwiederherstellung lädt die In-Memory OLTP-Engine Daten parallel in den Arbeitsspeicher, um die Auswirkungen auf die Wiederherstellungszeit zu minimieren.

Zusammenführen von Daten und Deltadateien

Die Daten für speicheroptimierte Tabellen werden in einem oder mehreren Daten- und Deltadateipaaren gespeichert (auch Prüfpunktdateipaar oder CFP [Checkpoint File Pair] genannt). Datendateien speichern eingefügte Zeilen, und Delta-Dateien verweisen auf gelöschte Zeilen. Während der Ausführung eines OLTP-Workloads werden, wenn die DML-Vorgänge Zeilen aktualisieren, einfügen und löschen, neue CFPs erstellt, um die neuen Zeilen dauerhaft zu speichern, und die Verweise auf gelöschte Zeilen werden an Delta-Dateien angehängt.

Im Laufe der Zeit wachsen bei DML-Vorgängen die Anzahl der Daten und Delta-Dateien, was zu einer erhöhten Speicherplatzauslastung und einer erhöhten Wiederherstellungszeit führt.

Um diese Ineffizienzen zu verhindern, werden die älteren geschlossenen Daten und Delta-Dateien zusammengeführt, basierend auf einer weiter unten in diesem Artikel beschriebenen Zusammenführungsrichtlinie, sodass das Speicherarray komprimiert wird, um dieselbe Datenmenge mit einer reduzierten Anzahl von Dateien darzustellen.

Der Zusammenführungsvorgang verwendet als Eingabe ein oder mehrere benachbarte geschlossene Prüfpunkte-Dateipaare von Daten- und Deltadateien (als Zusammenführungsquelle bezeichnet), basierend auf einer intern definierten Zusammenführungsrichtlinie, und erzeugt ein resultierendes CFP, das als Zusammenführungsziel bezeichnet wird. Die Einträge in jeder Delta-Datei der Quell-CFPs werden verwendet, um Zeilen aus der entsprechenden Datendatei zu filtern, um die nicht benötigten Datenzeilen zu entfernen. Die verbleibenden Zeilen in den Quell-CFPs werden zu einem Ziel-CFP zusammengefasst. Nach Abschluss der Zusammenführung ersetzt das resultierende Ziel-CFP die Quell-CFPs (Zusammenführungsquellen). Die Zusammenführungsquellen-CFPs durchlaufen eine Übergangsphase, bevor sie aus dem Speicher entfernt werden.

Im folgenden Beispiel verfügt die speicheroptimierte Tabellendateigruppe über vier Daten- und Delta-Dateipaare zum Zeitstempel 500, die Daten aus vorherigen Transaktionen enthalten. Beispielsweise entsprechen die ersten Zeilen in der Datendatei Transaktionen mit einem Zeitstempel, der größer als 100 und kleiner oder gleich 200 ist, alternativ ausgedrückt als (100, 200). Die zweite und dritte Datendatei werden nach Berücksichtigung der als gelöscht gekennzeichneten Zeilen zu weniger als 50 % gefüllt angezeigt. Der Zusammenführungsvorgang kombiniert diese beiden CFPs und erstellt ein neues CFP mit Transaktionen, deren Zeitstempel größer als 200 und kleiner oder gleich 400 ist. Dies entspricht dem kombinierten Bereich dieser beiden CFPs. Es wird ein weiteres CFP mit dem Bereich (500, 600) angezeigt, und eine nicht leere Änderungsdatei für den Transaktionsbereich (200, 400) gibt an, dass der Zusammenführungsvorgang parallel zur Transaktionsaktivität erfolgen kann, einschließlich des Löschens mehrerer Zeilen aus den Quell-CFPs.

In einem Hintergrundthread werden alle geschlossenen CFPs mithilfe einer Zusammenführungsrichtlinie ausgewertet und dann eine oder mehrere Zusammenführungsanforderungen für die qualifizierenden CFPs initiiert. Diese Merge-Requests werden vom Offline-Checkpoint-Thread verarbeitet. Die Auswertung der Zusammenführungsrichtlinie erfolgt in regelmäßigen Abständen sowie beim Schließen eines Prüfpunkts.

SQL Server-Zusammenführungsrichtlinie

SQL Server implementiert die folgende Zusammenführungsrichtlinie:

• Eine Zusammenführung wird geplant, wenn zwei oder mehr aufeinander folgende CFPs konsolidiert werden können, nachdem gelöschte Zeilen berücksichtigt wurden, sodass die resultierenden Zeilen in eine CFP der Zielgröße passen können. Die Zielgröße von Daten- und Deltadateien entspricht der ursprünglichen Größenanpassung, wie zuvor beschrieben.

• Ein einzelnes CFP kann mit sich selbst zusammengeführt werden, wenn die Datendatei das Doppelte der Zielgröße überschreitet und mehr als die Hälfte der Zeilen gelöscht sind. Eine Datendatei kann größer als die Zielgröße werden, wenn beispielsweise eine einzelne Transaktion oder mehrere gleichzeitige Transaktionen eingefügt oder eine große Datenmenge aktualisiert werden, wodurch die Datendatei über die Zielgröße hinaus wächst, da eine Transaktion nicht mehrere CFPs umfassen kann.

Hier sind einige Beispiele, die zeigen, dass die CFPs unter der Zusammenführungsrichtlinie zusammengeführt werden:

Nicht alle CFPs mit verfügbarem Speicherplatz kommen für die Zusammenführung infrage. Wenn zum Beispiel zwei benachbarte CFPs zu 60% voll sind, qualifizieren sie sich nicht für eine Zusammenführung, und jede dieser CFPs haben 40% Speicher ungenutzt. Im schlimmsten Fall sind alle CFPs 50% voll, eine Speicherauslastung von nur 50%. Obwohl die gelöschten Zeilen möglicherweise im Speicher gespeichert sind, weil sich die CFPs nicht für eine Zusammenführung qualifizieren, wurden die gelöschten Zeilen möglicherweise bereits vom Arbeitsspeicher entfernt durch die Garbage Collection. Die Verwaltung des Speichers und des Arbeitsspeichers erfolgt unabhängig von der Garbage Collection. Der Speicher, der von aktiven CFPs verwendet wird (nicht alle CFPs werden aktualisiert) kann bis zu zwei mal größer sein als die Größe dauerhafter Tabellen im Arbeitsspeicher.

Lebenszyklus einer GFP

CFPs durchlaufen mehrere Zustände, bevor sie freigegeben werden können. Datenbankprüfpunkte und Protokollsicherungen müssen stattfinden, damit die Dateien die Phasen durchlaufen können und letztlich nicht mehr benötigte Dateien entfernt werden. Eine Beschreibung dieser Phasen finden Sie unter sys.dm_db_xtp_checkpoint_files.

Sie können manuell erzwingen, dass ein Prüfpunkt mit anschließender Protokollsicherung die Garbage Collection beschleunigt. In Produktionsszenarien lassen die automatischen Prüfpunkte und Protokollsicherungen, die als Teil der Sicherungsstrategie durchgeführt werden, die CFPs nahtlos durch diese Phasen laufen, ohne dass ein manueller Eingriff notwendig ist. Der Effekt des Garbage Collection-Prozesses besteht darin, dass Datenbanken mit speicheroptimierten Tabellen im Vergleich zu ihrer Größe im Arbeitsspeicher möglicherweise eine größere Speichergröße aufweisen. Wenn Prüfpunkt- und Protokollsicherungen nicht auftreten, wächst der Speicherbedarf der Prüfpunktdateien weiterhin.

Verwandte Inhalte

• Erstellen und Verwalten von Speicher für speicheroptimierte Objekte