Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
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. Um eine langfristige Dauerhaftigkeit und ein Abschneiden des Transaktionsprotokolls zu ermöglichen, werden die für speicheroptimierte Tabellen ausgeführten Vorgänge in einer Reihe von Daten- und Änderungsdateien persistent gespeichert. 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 im Rahmen eines INSERT- oder UPDATE-Vorgangs 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 im Vergleich zu zufälliger E/A einen erheblich besseren E/A-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 ist eine entsprechende Änderungsdatei zugeordnet, die den gleichen Transaktionsbereich besitzt und die gelöschten Zeilen nachverfolgt, die von Transaktionen im Transaktionsbereich eingefügt wurden. 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). Genau wie bei Datendateien wird auf Änderungsdateien 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, werden in der Änderungsdatei nur die Verweisinformationen {inserting_tx_id, row_id, deleting_tx_id} gespeichert, und sie folgt dabei der Reihenfolge der ursprünglichen DELETE- oder UPDATE-Vorgänge im Transaktionsprotokoll.
Größe: Auf Computern mit einer Arbeitsspeicherkapazität über 16 GB beträgt die Größe jeder Änderungsdatei ungefähr 16 MB, und auf Computern mit einer Arbeitsspeicherkapazität bis 16 GB beträgt die Größe 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 Modus für große Prüfpunkte haben die Änderungsdateien eine Größe von 128 MB.
Auffüllen von Daten- und Deltadateien
Die Daten- und Änderungsdateien werden anhand der Datensätze des Transaktionsprotokolls aufgefüllt, die beim Commit von Transaktionen für speicheroptimierte Tabellen generiert wurden. Die Informationen über die eingefügten und gelöschten Zeilen werden an die entsprechenden Daten- und Änderungsdateien angehängt. Im Gegensatz zu datenträgerbasierte Tabellen, bei denen Daten-/Indexseiten in zufälligen E/A-Vorgängen nach einem Prüfpunkt geleert werden, wird die Persistenz von speicheroptimierten Tabellen in einem kontinuierlichen Hintergrundvorgang erreicht. Es wird auf mehrere Änderungsdateien zugegriffen, da alle Zeilen, die durch beliebige vorherige Transaktionen eingefügt wurden, durch eine Transaktion gelöscht oder aktualisiert werden können. Löschinformationen werden immer am Ende der Änderungsdatei 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
Durch diesen Thread werden Einfügungen und Löschungen in speicheroptimierte Datenzeilen an die entsprechenden Daten-/Änderungsdateipaare angefügt. 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 eines oder mehrere Daten-/Änderungsdateipaare zusammen und erstellt ein neues Daten-/Änderungsdateipaar.
Während der Wiederherstellung nach einem Systemabsturz
Wenn SQL Server neu gestartet wird oder die Datenbank wieder online geschaltet wird, werden die speicheroptimierten Daten unter Verwendung der Daten-/Änderungsdateipaare aufgefüllt. Die Änderungsdatei dient beim Lesen der Zeilen aus der entsprechenden Datendatei als Filter für die gelöschten Zeilen. Da alle Daten-/Änderungsdateipaare unabhängig sind, werden diese Dateien parallel geladen, um die Zeit zum Laden der Daten in den Arbeitsspeicher zu verkürzen. 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 mindestens einem Daten-/Änderungsdateipaar gespeichert (auch als Prüfpunktdateipaar oder CFP (Checkpoint File Pair) bezeichnet). Eingefügte Zeilen werden in Datendateien gespeichert, und in Änderungsdateien werden Verweise auf gelöschte Zeilen gespeichert. Während der Ausführung einer OLTP-Arbeitsauslastung werden beim Aktualisieren, Einfügen und Löschen von Zeilen durch DML-Vorgänge neue CFPs erstellt, um die neuen Zeilen persistent zu speichern, und der Verweis auf die gelöschten Zeilen wird an die Änderungsdateien angefügt.
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 Zusammenführungsanforderungen werden vom Offline-Prüfpunktthread 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:
| Angrenzende Quelldateien von CFPs (% vollständig) | Auswahl zusammenführen |
|---|---|
| CFP0 (30 %), CFP1 (50 %), CFP2 (50 %), CFP3 (90 %) | (CFP0, CFP1) CFP2 wird nicht ausgewählt, da die resultierende Datendatei größer als 100% der idealen Größe wird. |
| CFP0 (30 %), CFP1 (20 %), CFP2 (50 %), CFP3 (10 %) | (CFP0, CFP1, CFP2). Dateien werden von links nach rechts ausgewählt. CFP3 wird nicht ausgewählt, da die resultierende Datendatei größer als 100% der idealen Größe ist. |
| CFP0 (80 %), CFP1 (30 %), CFP2 (10 %), CFP3 (40 %) | (CFP1, CFP2, CFP3). Dateien werden von links nach rechts ausgewählt. CFP0 wird übersprungen, da die resultierende Datendatei in Kombination mit CFP1 größer als 100% der idealen Größe ist. |
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 ihre Zuordnung aufgehoben werden kann. Als Folge der Datenbank-Prüfpunkte und Protokollsicherungen durchlaufen die Dateien die Phasen, und am Ende werden die nicht mehr benötigten Dateien bereinigt. 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.