Vergleich zwischen Change Data Capture und Änderungsnachverfolgung
SQL Server 2008 weist zwei Nachverfolgungsfunktionen auf, mit denen Anwendungen die DML-Änderungen (Einfüge-, Aktualisierungs- und Löschvorgänge) ermitteln können, die an Benutzertabellen in einer Datenbank vorgenommen wurden. Bevor diese Funktionen verfügbar gemacht wurden, mussten benutzerdefinierte Nachverfolgungsmechanismen in Anwendungen implementiert werden. Diese benutzerdefinierten Mechanismen erforderten oft Schemaänderungen an den nachverfolgten Tabellen oder die Verwendung von Triggern. Weder Change Data Capture noch die Änderungsnachverfolgung erfordert Schemaänderungen an der Quelle oder die Verwendung von Triggern.
Change Data Capture
Change Data Capture stellt Änderungsverlaufsinformationen für Benutzertabellen bereit, indem sowohl die Tatsache, dass DML-Änderungen vorgenommen wurden, als auch die geänderten Daten erfasst werden. Die Änderungen werden über einen asynchronen Prozess durch Lesen des Transaktionsprotokolls erfasst, der keine großen Auswirkungen auf die Systemleistung hat.
Wie in der folgenden Abbildung gezeigt, werden die an Benutzertabellen vorgenommenen Änderungen in entsprechenden Änderungstabellen aufgezeichnet. Diese Änderungstabellen stellen eine Übersicht über den Änderungsverlauf dar. Die von SQL Server bereitgestellten Change Data Capture-Funktionen ermöglichen die einfache und systematische Verarbeitung der Änderungsdaten.
.gif "Konzeptdarstellung von Change Data Capture")
Änderungsnachverfolgung
Bei der Änderungsnachverfolgung wird die Tatsache erfasst, dass Zeilen in einer Tabelle geändert wurden. Die geänderten Daten werden nicht erfasst. Hierdurch können Anwendungen die geänderten Zeilen ermitteln, wobei die aktuellen Zeilendaten direkt von den Benutzertabellen abgerufen werden. Im Hinblick auf den Verlauf ist die Änderungsnachverfolgung also nicht so aussagekräftig wie Change Data Capture. Der Vorteil für die Anwendungen, die keine Verlaufsinformationen erfordern, liegt darin, dass viel weniger Speicherplatz benötigt wird, da die Änderungsdaten nicht aufgezeichnet werden. Zur Nachverfolgung der Änderungen wird ein synchroner Nachverfolgungsmechanismus verwendet. Dieser wurde so konzipiert, dass er sich minimal auf die Leistung der DML-Vorgänge auswirkt.
Die folgende Abbildung zeigt ein Synchronisierungsszenario, in dem die Verwendung der Änderungsnachverfolgung vorteilhaft ist. In diesem Szenario erfordert eine Anwendung die folgenden Informationen: alle Zeilen in der Tabelle, die seit der letzten Synchronisierung der Tabelle geändert wurden, und nur die aktuellen Zeilendaten. Da zur Nachverfolgung der Änderungen ein synchroner Mechanismus verwendet wird, kann eine Anwendung die bidirektionale Synchronisierung anwenden und eventuelle Konflikte zuverlässig ermitteln.
.gif "Konzeptdarstellung der Änderungsnachverfolgung")
Funktionsunterschiede zwischen Change Data Capture und Änderungsnachverfolgung
In der folgenden Tabelle sind die Funktionsunterschiede zwischen Change Data Capture und Änderungsnachverfolgung aufgelistet. Der Nachverfolgungsmechanismus in Change Data Capture umfasst die asynchrone Erfassung der Änderungen aus dem Transaktionsprotokoll, sodass die Änderungen nach Abschluss des jeweiligen DML-Vorgangs verfügbar sind. Der Nachverfolgungsmechanismus bei der Änderungsnachverfolgung umfasst die synchrone Erfassung der Änderungen im Einklang mit den DML-Vorgängen, sodass die Änderungen unmittelbar verfügbar sind.
Funktion |
Change Data Capture |
Änderungsnachverfolgung |
|---|---|---|
Nachverfolgte Änderungen |
|
|
DML-Änderungen |
Ja |
Ja |
Nachverfolgte Informationen |
|
|
Verlaufsdaten |
Ja |
Nein |
Ob Spalte geändert wurde |
Ja |
Ja |
DML-Typ |
Ja |
Ja |