Informationen zur Änderungsnachverfolgung (SQL Server)

Gilt für: SQL Server Azure SQL-Datenbank Azure SQL Managed Instance

Dieser Artikel beschreibt die Funktion zur Änderungsnachverfolgung für SQL Server, eine leichtgewichtige Lösung, die einen effizienten Mechanismus zur Änderungsnachverfolgung für Anwendungen bietet.

Für den Einstieg lesen Sie bitte Konfigurieren der Änderungsnachverfolgung.

Übersicht

Bisher mussten Anwendungsentwickler benutzerdefinierte Mechanismen zur Änderungsnachverfolgung implementieren, damit die Anwendungen Änderungen an Daten in einer Datenbank abfragen und auf Informationen im Zusammenhang mit den Änderungen zugreifen konnten. Diese Mechanismen waren in der Regel mit viel Arbeit verbunden, z. B. mit einer Kombination aus Triggern, Zeitstempelspalten, neuen Tabellen zur Speicherung von Tracking-Informationen und benutzerdefinierten Bereinigungsprozessen. Die Änderungsverfolgungsfunktion von SQL Server vereinfacht diesen Prozess und macht es einfach, Informationen über Änderungen zu identifizieren, ohne dass eine benutzerdefinierte Lösung erforderlich ist.

Die Anforderungen an die Menge erforderlicher Informationen zu den Änderungen variieren je nach Anwendungstyp. Anwendungen können die Änderungsnachverfolgung verwenden, um die folgenden Fragen zu den an einer Benutzertabelle vorgenommenen Änderungen zu beantworten:

• Welche Zeilen wurden in einer Benutzertabelle geändert?

  • Es ist nur die Tatsache von Belang, dass eine Zeile geändert wurde, nicht jedoch, wie oft die Zeile geändert wurde oder welche Werte bei Zwischenänderungen festgelegt wurden.

  • Die aktuellen Daten können direkt aus der nachverfolgten Tabelle abgerufen werden.

• Wurde eine Zeile geändert?

  • Die Tatsache, dass eine Zeile geändert wurde, und Informationen zu der Änderung müssen verfügbar sein und zum Zeitpunkt der Änderung in derselben Transaktion aufgezeichnet werden.

Unidirektionale und bidirektionale Synchronisierungsanwendungen

Anwendungen, die Daten mit einer Instanz der SQL Server-Datenbank-Engine synchronisieren müssen, müssen in der Lage sein, Änderungen abzufragen. Die Änderungsnachverfolgung kann sowohl als Grundlage für unidirektionale als auch für bidirektionale Synchronisierungsanwendungen verwendet werden.

Unidirektionale Synchronisierungsanwendungen

Es können unidirektionale Synchronisierungsanwendungen, z. B. ein Client oder eine Zwischenspeicherungsanwendung auf der mittleren Ebene, erstellt werden, die die Änderungsnachverfolgung verwenden. Wie in der folgenden Abbildung dargestellt, müssen für eine Zwischenspeicherungsanwendung Daten in Datenbank-Engine gespeichert und in anderen Datenspeichern zwischengespeichert werden. Die Anwendung muss in der Lage sein, den Cache auf dem aktuellen Stand zu halten, indem dieser mit allen an den Datenbanktabellen vorgenommenen Änderungen aktualisiert wird. Es werden keine Änderungen zurück an Datenbank-Engineübergeben.

Bidirektionale Synchronisierungsanwendungen

Es können auch bidirektionale Synchronisierungsanwendungen erstellt werden, die die Änderungsnachverfolgung verwenden. In diesem Szenario werden die Daten in einer Instanz von Datenbank-Engine mit mindestens einem Datenspeicher synchronisiert. Die Daten in diesen Speichern können aktualisiert werden, und die Änderungen müssen wieder mit Datenbank-Enginesynchronisiert werden.

Ein gutes Beispiel für eine bidirektionale Synchronisierungsanwendung ist eine gelegentlich verbundene Anwendung. In einer Anwendung dieses Typs fragt eine Clientanwendung einen lokalen Speicher ab und aktualisiert diesen. Wenn eine Verbindung zwischen einem Client und einem Server verfügbar ist, führt die Anwendung die Synchronisierung mit einem Server aus, und geänderte Daten fließen in beide Richtungen.

Die bidirektionalen Synchronisierungsanwendungen müssen Konflikte erkennen können. Zu einem Konflikt kommt es, wenn in der Zeit zwischen zwei Synchronisierungen die gleichen Daten in beiden Datenspeichern geändert wurden. Wenn eine Anwendung über die Fähigkeit zum Erkennen von Konflikten verfügt, kann sichergestellt werden, dass keine Änderungen verloren werden.

Funktionsweise der Änderungsnachverfolgung

Zum Konfigurieren der Änderungsnachverfolgung können Sie DDL-Anweisungen oder SQL Server Management Studio verwenden. Weitere Informationen finden Sie unter Aktivieren und Deaktivieren der Änderungsnachverfolgung. Zum Nachverfolgen von Änderungen muss die Änderungsnachverfolgung zuerst für die Datenbank und dann für die Tabellen, die in dieser Datenbank nachverfolgt werden sollen, aktiviert werden. Die Tabellendefinition muss in keiner Weise geändert werden, und es werden keine Trigger erstellt.

Nachdem die Änderungsnachverfolgung für eine Tabelle konfiguriert wurde, werden bei der Verwendung einer DML-Anweisung, die sich auf die Zeilen in der Tabelle auswirkt, Änderungsinformationen für jede geänderte Zeile aufgezeichnet. Zum Abfragen von geänderten Zeilen und Informationen zu den Änderungen können Sie Änderungsnachverfolgungsfunktionenverwenden.

Die Werte der Primärschlüssel-Spalte ist die einzige Information aus der nachverfolgten Tabelle, die mit den Änderungsinformationen aufgezeichnet wird. Diese Werte identifizieren die Zeilen, die geändert wurden. Zum Abrufen der aktuellen Daten dieser Zeilen kann eine Anwendung die Werte der Primärschlüsselspalte verwenden, um die Quelltabelle mit der nachverfolgten Tabelle zu verknüpfen.

Informationen zu den an den einzelnen Zeilen vorgenommenen Änderungen können auch mithilfe der Änderungsnachverfolgung abgerufen werden. Dazu zählen z. B. der Typ des DML-Vorgangs, der die Änderung (Einfügung, Update oder Löschung) bewirkt hat, oder die Spalten, die im Rahmen eines Updatevorgangs geändert wurden.

Alle DML-Vorgänge werden nachverfolgt, auch wenn sich der Wert einer Spalte nicht ändert. Wenn zum Beispiel eine Aktualisierungsanweisung eine Spalte auf denselben Wert setzt, den sie bereits hat, wird die Spalte trotzdem als geändert betrachtet.

Bereinigen der Änderungsnachverfolgung

Informationen der Änderungsnachverfolgung für alle Tabellen (für die Änderungsnachverfolgung aktiviert ist) werden in einem speicherinternen Rowstore gespeichert. Die Daten der Änderungsnachverfolgung für jede Tabelle, für die Änderungsnachverfolgung aktiviert ist, werden bei jedem Prüfpunkt aus dem speicherinternen Rowstore in die entsprechende interne Tabelle auf dem Datenträger geleert. Während des Prüfpunkts wird auch der speicherinterne Rowstore gelöscht, nachdem die Zeilen in die Tabellen auf dem Datenträger verschoben werden.

Jede Tabelle, für die Änderungsnachverfolgung aktiviert ist, verfügt über eine interne Tabelle auf dem Datenträger, die von Änderungsnachverfolgungsfunktionen verwendet wird, um die Version und die Zeilen zu bestimmen, die seit einer bestimmten Version geändert wurden. Jedes Mal, wenn der Thread Auto Cleanup aufgerufen wird, scannt er alle Benutzerdatenbanken auf der SQL Server-Instanz, um die Datenbanken zu identifizieren, für die Änderungsnachverfolgung aktiviert ist. Entsprechend der eingestellten Beibehaltungsdauer der Datenbank werden die abgelaufenen Datensätze jeder internen Tabelle auf dem Datenträger gelöscht.

In den Service Packs für SQL Server 2014 (12.x) und SQL Server 2016 (13.x) wurde eine gespeicherte Prozedur hinzugefügt, mit der Sie eine manuelle Bereinigung für die internen Tabellen der Änderungsnachverfolgung durchführen können. Weitere Informationen zur gespeicherten Prozedur finden Sie unter KB173157.

Zugehöriger Inhalt

• Aktivieren und Deaktivieren der Änderungsnachverfolgung
• Verwenden der Änderungsnachverfolgung
• Verwalten der Änderungsnachverfolgung
• Behandlung von Problemen bei der automatischen Bereinigung von Änderungen
• Nachverfolgen von Datenänderungen
• Änderungsnachverfolgung Gespeicherte Prozeduren
• Änderungsnachverfolgung bei Tabellen