Haltbarkeit für Memory-Optimized Tabellen

In-Memory OLTP bietet volle Haltbarkeit für speicheroptimierte Tabellen. Wenn eine Transaktion, die eine speicheroptimierte Tabelle geändert hat, festgeschrieben wird, garantiert SQL Server, ähnlich wie bei datenträgerbasierten Tabellen, dass die Änderungen dauerhaft sind (einen Datenbankneustart überleben), vorausgesetzt, der zugrunde liegende Speicher ist verfügbar. Es gibt zwei wichtige Komponenten der Haltbarkeit: Transaktionsprotokollierung und beibehaltene Datenänderungen am Datenträgerspeicher.

Transaktionsprotokoll

Alle Änderungen, die an datenträgerbasierten Tabellen oder dauerhaften speicheroptimierten Tabellen vorgenommen wurden, werden in einem oder mehreren Transaktionsprotokolldatensätzen erfasst. Wenn eine Transaktion festgeschrieben wird, schreibt SQL Server die der Transaktion zugeordneten Protokolldatensätze auf den Datenträger, bevor an die Anwendung oder Benutzersitzung kommuniziert wird, dass die Transaktion durchgeführt wurde. Dadurch wird sichergestellt, dass Änderungen, die von der Transaktion vorgenommen werden, dauerhaft sind. Das Transaktionsprotokoll für speicheroptimierte Tabellen ist vollständig in denselben Protokolldatenstrom integriert, der von datenträgerbasierten Tabellen verwendet wird. Diese Integration ermöglicht es, dass vorhandene Transaktionsprotokollsicherungs-, Wiederherstellungs- und Wiederherstellungsvorgänge ohne zusätzliche Schritte weiterhin problemlos funktionieren. Da In-Memory OLTP jedoch den Transaktionsdurchsatz Ihrer Workload erheblich erhöhen kann, müssen Sie sicherstellen, dass der Transaktionsprotokollspeicher entsprechend konfiguriert ist, um die erhöhten E/A-Anforderungen zu erfüllen.

Daten- und Delta-Dateien

Die Daten in speicheroptimierten Tabellen werden als Freiformdatenzeilen gespeichert, die über einen oder mehrere In-Memory-Indizes im Arbeitsspeicher verknüpft sind. Es gibt keine Seitenstrukturen für Datenzeilen, z. B. für datenträgerbasierte Tabellen. Wenn die Anwendung bereit ist, die Transaktion zu übernehmen, generiert das In-Memory OLTP die Protokolldatensätze für die Transaktion. Die Persistenz von speicheroptimierten Tabellen erfolgt mit einer Reihe von Daten- und Deltadateien mithilfe eines Hintergrundthreads. Die Daten und Delta-Dateien befinden sich in einem oder mehreren Containern (mit demselben Mechanismus, der für FILESTREAM-Daten verwendet wird). Diese Container werden einem neuen Dateigruppentyp zugeordnet, der als speicheroptimierte Dateigruppe bezeichnet wird.

Daten werden in diese Dateien streng sequenziell geschrieben, wodurch die Datenträgerlatenz für sich drehende Medien minimiert wird. 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 Wiederherstellungsleistung, wenn Informationen aus den Daten- und Deltadateien auf dem Datenträger in den Arbeitsspeicher geladen werden.

Eine Anwendung greift nicht direkt auf Daten und Deltadateien zu. Alle Datenlese- und Schreibvorgänge nutzen speicherinterne Daten.

Die Datendatei

Eine Datendatei enthält Zeilen aus einer oder mehreren speicheroptimierten Tabellen, die von mehreren Transaktionen als Teil von INSERT- oder UPDATE-Vorgängen eingefügt wurden. Beispielsweise kann eine Zeile aus der speicheroptimierten Tabelle T1 stammen, und die nächste Zeile kann aus der speicheroptimierten Tabelle T2 stammen. Die Zeilen werden an die Datendatei in der Reihenfolge der Transaktionen im Transaktionsprotokoll angefügt, wodurch der Datenzugriff sequenziell erfolgt. Dies ermöglicht einen um eine Größenordnung besseren E/A-Durchsatz im Vergleich zu zufälligen E/A. Jede Datendatei beträgt ungefähr 128 MB für Computer mit mehr als 16 GB Arbeitsspeicher und 16 MB für Computer mit weniger als oder gleich 16 GB. Sobald die Datendatei voll ist, werden die zeilen, die von neuen Transaktionen eingefügt wurden, in einer anderen Datendatei gespeichert. Im Laufe der Zeit werden die Zeilen aus dauerhaften speicheroptimierten Tabellen in einer von mehreren Datendateien und jeder Datendatei gespeichert, die Zeilen aus einem nicht zusammenhängenden, aber zusammenhängenden Bereich von Transaktionen enthält. Beispielsweise enthält eine Datendatei mit Transaktions-Commit-Zeitstempel im Bereich von (100, 200) alle Zeilen, die von Transaktionen eingefügt wurden, die einen Commit-Zeitstempel größer als 100 und kleiner als oder gleich 200 haben. Der Commit-Zeitstempel ist eine monoton zunehmende Zahl, die einer Transaktion zugewiesen ist, wenn sie bereit ist, einen Commit durchzuführen. Jede Transaktion verfügt über einen eindeutigen Commit-Zeitstempel.

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. Aktualisierungsvorgänge werden als Tupel von Lösch- und Einfügeoperationen für jede Zeile verarbeitet. Dadurch werden zufällige Eingabe-/Ausgabeoperationen in der Datendatei eliminiert.

Die Delta-Datei

Jede Datendatei wird mit einer Delta-Datei gekoppelt, die denselben Transaktionsbereich aufweist und die gelöschten Zeilen nachverfolgt, die durch Transaktionen im Transaktionsbereich gelöscht oder eingefügt wurden. Diese Daten- und Delta-Datei wird als Prüfpunktdateipaar (Checkpoint File Pair, CFP) bezeichnet, und es handelt sich um 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 (100, 200) eingefügt wurden. Wie Datendateien wird sequenziell auf die Delta-Datei 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 Referenzinformationen {inserting_tx_id, row_id, deleting_tx_id } und folgt der Transaktionsprotokollreihenfolge der ursprünglichen Lösch- oder Aktualisierungsvorgänge.

Auffüllen von Daten- und Delta-Dateien

Daten- und Delta-Datei werden von einem Hintergrundthread mit dem Namen "Offlineprüfpunkt" aufgefüllt. Dieser Thread liest die Transaktionsprotokolldatensätze, die von zugesicherten Transaktionen in speicheroptimierten Tabellen generiert werden, und fügt Informationen zu den eingefügten und gelöschten Zeilen an geeignete Daten- und Deltadateien an. Im Gegensatz zu datenträgerbasierten Tabellen, in denen Daten-/Indexseiten beim Abschluss des Prüfpunkts mit zufälliger E/A geleert werden, ist die Persistenz der speicheroptimierten Tabelle ein fortlaufender Hintergrundvorgang. Auf mehrere Delta-Dateien wird 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 abbildung unten dargestellt. Alle vier Datei-E/A-Vorgänge (drei für gelöschte Zeilen und 1 für die neu eingefügten Zeilen) sind Nur-Anfügevorgänge an die entsprechenden Delta- und Datendateien.

Zugreifen auf Daten und Delta-Dateien

Auf Daten- und Delta-Dateipaare wird zugegriffen, wenn folgendes auftritt.

Offlineprüfpunkt-Thread Dieser Thread fügt Einträge und Löschvorgänge in speicheroptimierten Datenzeilen in die entsprechenden Daten- und Delta-Dateipaare ein.

Zusammenführungsvorgang Der Vorgang führt ein oder mehrere Daten- und Delta-Dateipaare zusammen und erstellt ein neues Daten- und Delta-Dateipaar.

Während der Datenbankcrash-Wiederherstellung, wenn SQL Server neu gestartet oder die Datenbank wieder online gestellt wird, werden die speicheroptimierten Daten anhand der Daten- und Delta-Dateipaaren wiederhergestellt. Die Delta-Datei fungiert als Filter für die gelöschten Zeilen beim Lesen der Zeilen aus der entsprechenden Datendatei. Da jedes Daten- und Delta-Dateipaar unabhängig ist, werden diese Dateien parallel geladen, um die Zeit zu reduzieren, die zum Auffüllen von Daten in den Arbeitsspeicher benötigt wird. Nachdem 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 wurden, damit die speicheroptimierten Daten abgeschlossen sind.

Während des Wiederherstellungsvorgangs werden die In-Memory OLTP-Prüfpunktdateien aus der Datenbanksicherung erstellt und dann eine oder mehrere Transaktionsprotokollsicherungen 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 Delta-Dateien

Die Daten für speicheroptimierte Tabellen werden in einem oder mehreren Daten- und Delta-Dateipaaren (auch als Prüfpunktdateipaar oder CFP bezeichnet) gespeichert. In Datendateien werden eingefügte Zeilen gespeichert, und Delta-Dateien verweisen auf gelöschte Zeilen. Während der Ausführung einer OLTP-Workload werden neue CFPs erstellt, wenn DML-Operationen Zeilen aktualisieren, einfügen oder löschen, um die neuen Zeilen zu speichern. Der Verweis auf die gelöschten Zeilen wird an die Delta-Dateien angefügt.

Die Metadaten aller zuvor geschlossenen und derzeit aktiven CFPs werden in einer internen Arraystruktur gespeichert, die als Speicherarray bezeichnet wird. Es handelt sich um ein Array mit endlicher Größe (8.192 Einträge) von CFPs. Die Einträge im Speicherarray werden nach Transaktionsbereich sortiert. Die CFPs im Speicherarray (zusammen mit dem Tail des Protokolls) stellen den gesamten Zustand auf dem Datenträger dar, der zum Wiederherstellen einer Datenbank mit speicheroptimierten Tabellen erforderlich ist.

Im Laufe der Zeit, mit DML-Vorgängen, wächst die Anzahl der CFPs, wodurch die Kapazitätsgrenze des Speicherarrays erreicht wird, was die folgenden Herausforderungen verursacht:

• Gelöschte Zeilen. Gelöschte Zeilen verbleiben in der Datendatei, werden aber in der entsprechenden Delta-Datei als gelöscht markiert. Diese Zeilen sind nicht mehr erforderlich und werden aus dem Speicher entfernt. Wenn gelöschte Zeilen nicht aus CFPs entfernt wurden, würden sie unnötig Speicherplatz verwenden und die Wiederherstellungszeit langsamer machen.

• Speicherarray ist voll. Wenn 8.000 Einträge im Speicherarray zugeordnet werden (192 Einträge im Array sind für bestehende Zusammenführungen reserviert, um zu konkurrieren oder manuelle Zusammenführungen zu ermöglichen), können keine neuen DML-Transaktionen auf dauerhaft speicheroptimierten Tabellen ausgeführt werden. Nur Prüfpunkt- und Zusammenführungsvorgänge dürfen die verbleibenden Einträge nutzen. Dadurch wird sichergestellt, dass DML-Transaktionen das Array nicht füllen und dass einige Einträge im Array zum Zusammenführen vorhandener Dateien und zum Freigeben von Speicherplatz im Array reserviert sind.

• Aufwand für die Manipulation von Speicherarrays. Interne Prozesse durchsuchen das Speicherarray nach Vorgängen, z. B. um die Delta-Datei zu finden und Informationen zu einer gelöschten Zeile anzufügen. Die Kosten für diese Vorgänge steigen mit der Anzahl der Einträge.

Um diese Ineffizienzen zu verhindern, werden die älteren geschlossenen CFPs zusammengeführt, basierend auf einer unten beschriebenen Zusammenführungsrichtlinie, sodass das Speicherarray komprimiert wird, um dieselbe Datenmenge mit einer reduzierten Anzahl von CFPs darzustellen.

Die Gesamtgröße aller dauerhaften Tabellen in einer Datenbank sollte 250 GB nicht überschreiten. Dauerhafte Tabellen, die bis zu 250 GB Arbeitsspeicher verwenden, erfordern unter Annahme von Einfüge-, Lösch- und Aktualisierungsvorgängen durchschnittlich 500 GB Speicherplatz. Für die Unterstützung von 500 GB Speicherplatz sind 4.000 Daten- und Delta-Dateipaare in der speicheroptimierten Dateigruppe erforderlich.

Kurzzeitige Anstiege bei den Datenbankaktivitäten können Verzögerungen bei Prüfpunkt- und Zusammenführungsvorgängen verursachen, wodurch die Anzahl der benötigten Daten- und Delta-Dateipaare erhöht wird. Um kurzfristige Spitzen bei Datenbankaktivitäten auszugleichen, kann das Speichersystem bis zu 8.000 Daten- und Delta-Dateipaare zuordnen, mit einem Gesamtspeicher von bis zu 1 TB. Wenn dieser Grenzwert erreicht ist, werden in der Datenbank keine neuen Transaktionen zulässig sein, bis Prüfpunktvorgänge nachholen. Wenn die Größe dauerhafter Tabellen im Arbeitsspeicher länger als 250 GB beträgt, besteht die Möglichkeit, den Grenzwert von 8.000 Dateipaaren zu erreichen.

Der Zusammenführungsvorgang verwendet als Eingabe eine oder mehrere benachbarte geschlossene CFPs (als Seriendruckquelle bezeichnet) basierend auf einer intern definierten Zusammenführungsrichtlinie und erzeugt eine resultierende CFP, die als Seriendruckziel 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 in einem Ziel-CFP konsolidiert. Nachdem die Zusammenführung abgeschlossen ist, 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 enthält die speicheroptimierte Tabellendateigruppe vier Daten- und Delta-Dateipaare zum Zeitstempel 500, die Daten aus vorherigen Transaktionen enthalten. Beispielsweise entsprechen die Zeilen in der ersten Datendatei Transaktionen mit Zeitstempel größer als 100 und kleiner als oder gleich 200; alternativ dargestellt als (100, 200]. Die zweite und dritte Datendatei sind zu weniger als 50 Prozent gefüllt nach Berücksichtigung der als gelöscht markierten Zeilen. Der Zusammenführungsvorgang kombiniert diese beiden CFPs und erstellt ein neues CFP, das Transaktionen mit einem Zeitstempel größer als 200 und kleiner oder gleich 400 enthält, was dem kombinierten Bereich dieser beiden CFPs entspricht. Eine weitere CFP mit dem Bereich (500, 600] und einer nicht leeren Deltadatei für den Transaktionsbereich (200, 400] zeigt, dass der Zusammenführungsvorgang gleichzeitig mit transaktionalen Aktivitäten, einschließlich des Löschens weiterer Zeilen aus den Quell-CFPs, durchgeführt werden kann.

Ein Hintergrundthread wertet alle geschlossenen CFPs mithilfe einer Zusammenführungsrichtlinie aus und initiiert dann eine oder mehrere Zusammenführungsanforderungen für die qualifizierenden CFPs. Diese Merge-Anfragen werden vom Offline-Prüfpunkt-Thread verarbeitet. Die Auswertung der Zusammenführungsrichtlinie erfolgt regelmäßig und auch, wenn ein Prüfpunkt geschlossen wird.

SQL Server 2014 (12.x) Zusammenführungsrichtlinie

SQL Server 2014 (12.x) implementiert die folgende Zusammenführungsrichtlinie:

• Eine Zusammenführung wird geplant, wenn 2 oder mehr aufeinander folgende CFPs konsolidiert werden können, nachdem gelöschte Zeilen berücksichtigt wurden, sodass die resultierenden Zeilen in 1 GFP der idealen Größe passen können. Die ideale Größe der GFP wird wie folgt bestimmt:

  • Wenn ein Computer weniger als oder gleich 16 GB Arbeitsspeicher hat, beträgt die Datendatei 16 MB, und die Delta-Datei beträgt 1 MB.

  • Wenn ein Computer über mehr als 16 GB Arbeitsspeicher verfügt, beträgt die Datendatei 128 MB, und die Delta-Datei beträgt 16 MB.

• Eine einzelne CFP kann selbst zusammengeführt werden, wenn die Datendatei 256 MB überschreitet und mehr als die Hälfte der Zeilen gelöscht wird. Eine Datendatei kann größer als 128 MB werden, wenn z. B. eine einzelne Transaktion oder mehrere gleichzeitige Transaktionen eingefügt oder eine große Datenmenge aktualisiert werden, wodurch die Datendatei über ihre ideale Größe hinaus wachsen muss, da eine Transaktion nicht mehrere CFPs umfassen kann.

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

Nicht alle CFPs mit verfügbarer Speicherplatz sind für die Zusammenführung berechtigt. Wenn beispielsweise zwei benachbarte CFPs zu 60 % mit% gefüllt sind, sind sie nicht für die Zusammenführung berechtigt, und jede dieser CFPs hat 40 % des% Speichers ungenutzt. Im schlimmsten Fall werden alle CFPs 50% voll sein, eine Speicherauslastung von nur 50%. Während die gelöschten Zeilen möglicherweise auf dem Speicher vorhanden sind, weil die CFPs sich nicht für eine Zusammenführung qualifizieren, wurden die gelöschten Zeilen möglicherweise bereits durch die Garbage Collection im Arbeitsspeicher entfernt. Die Verwaltung des Speicherplatzes und des Speichers ist unabhängig von der Speicherbereinigung. Der Speicher von aktiven CFPs (nicht alle CFPs werden aktualisiert) kann bis zu 2 Mal größer sein als die Größe dauerhafter Tabellen im Arbeitsspeicher.

Bei Bedarf kann eine manuelle Zusammenführung explizit durch Aufrufen von sys.sp_xtp_merge_checkpoint_files (Transact-SQL) ausgeführt werden.

Lebenszyklus einer GFP

CPFs durchlaufen mehrere Zustände, bevor sie freigegeben werden können. Zu einem bestimmten Zeitpunkt befinden sich die CFPs in einer der folgenden Phasen: PRECREATED, UNDER CONSTRUCTION, ACTIVE, MERGE TARGET, MERGED SOURCE, REQUIRED FOR BACKUP/HA, IN TRANSITION TO TOMBSTONE und TOMBSTONE. Eine Beschreibung dieser Phasen finden Sie unter sys.dm_db_xtp_checkpoint_files (Transact-SQL).

Nach der Berücksichtigung des Speichers von CFPs in verschiedenen Zuständen kann der gesamte Speicher, der von dauerhaften speicheroptimierten Tabellen verwendet wird, viel größer als 2 Mal die Größe der Tabellen im Arbeitsspeicher sein. Die DMV sys.dm_db_xtp_checkpoint_files (Transact-SQL) kann abgefragt werden, um alle CFPs in der speicheroptimierten Dateigruppe sowie deren Phase aufzulisten. Beim Übergang von CFPs vom MERGE SOURCE-Zustand zu TOMBSTONE und letztendlich zur Garbage Collection kann es bis zu fünf Prüfpunkte geben, wobei nach jedem Prüfpunkt eine Transaktionsprotokollsicherung durchgeführt wird, wenn die Datenbank für das vollständige oder massenprotokollierte Wiederherstellungsmodell konfiguriert ist.

Sie können den Prüfpunkt manuell erzwingen, gefolgt von der Protokollsicherung, um die Garbage Collection zu beschleunigen, doch dann werden 5 leere CFPs hinzugefügt (5 Daten-/Delta-Dateipaare mit einer Datendatei der Größe 128 MB). In Produktionsszenarien werden die automatischen Prüfpunkte und Protokollsicherungen, die als Teil der Sicherungsstrategie durchgeführt werden, nahtlos CFPs durch diese Phasen überführen, ohne dass ein manueller Eingriff erforderlich ist. Die Auswirkungen des Garbage Collection-Prozesses sind, dass Datenbanken mit speicheroptimierten Tabellen im Vergleich zu ihrer Größe im Arbeitsspeicher möglicherweise eine größere Speichergröße aufweisen. Es ist nicht ungewöhnlich, dass CFPs bis zu viermal die Größe der dauerhaft speicheroptimierten Tabellen im Arbeitsspeicher aufweisen.

Siehe auch

Erstellen und Verwalten von Speicher für Memory-Optimized Objekte