Change Tracking oder CDC: den passenden SQL-Server-Datenstrom

Ein Suchindex muss wissen, welche Produkte geändert wurden, um deren aktuellen Stand neu einzulesen. Ein Data Warehouse benötigt möglicherweise alte und neue Werte jeder erfassten Änderung. Beides wird oft inkrementelle Synchronisierung genannt, beschreibt aber verschiedene Anforderungen. Change Tracking und Change Data Capture in SQL Server liefern dafür unterschiedliche Grundlagen.

Entscheiden Sie zuerst, ob Zwischenstände wichtig sind. Reicht nach drei Preisänderungen während eines Ausfalls der letzte Preis, oder müssen alle Änderungen verarbeitet werden? Klären Sie auch Löschungen. Eine Abfrage auf LastModified findet keine bereits entfernte Zeile, sofern deren Löschung nicht separat dokumentiert wird.

Die Bedeutung des Datenstroms festlegen

Change Tracking speichert geänderte Primärschlüssel und Änderungsmetadaten. Aktuelle Werte liest der Verbraucher aus der Ursprungstabelle. Das passt zur Aktualisierung eines nachgelagerten aktuellen Zustands, nicht zur Rekonstruktion sämtlicher Übergänge. Wiederholte Änderungen bilden kein vollständiges Ereignisprotokoll. Auch die optionale Spaltenverfolgung liefert keine früheren Spaltenwerte.

CDC liest bestätigte Änderungen aus dem Transaktionsprotokoll in Erfassungstabellen. Je nach Abfrageoption lassen sich erfasste Vorher- und Nachherwerte oder Nettoänderungen beziehen. Die Erfassung erfolgt verzögert: Ein erfolgreiches Quell-COMMIT bedeutet nicht, dass die Änderung bereits im verfügbaren CDC-Bereich liegt. Bei klassischen SQL-Server-Installationen müssen auch Erfassungs- und Bereinigungsjobs überwacht werden.

Diese schreibgeschützte Abfrage zeigt Datenbankkonfiguration und Tabellen mit Change Tracking.

SELECT d.name, d.is_cdc_enabled,
       ct.retention_period, ct.retention_period_units_desc,
       ct.is_auto_cleanup_on
FROM sys.databases AS d
LEFT JOIN sys.change_tracking_databases AS ct
    ON ct.database_id = d.database_id
WHERE d.database_id = DB_ID();

SELECT OBJECT_SCHEMA_NAME(object_id) AS SchemaName,
       OBJECT_NAME(object_id) AS TableName,
       is_track_columns_updated_on
FROM sys.change_tracking_tables;

Eine aktivierte Datenbankoption bedeutet nicht, dass sämtliche Tabellen erfasst werden. Prüfen Sie konkrete Tabellen, Primärschlüssel, Spalten, Zugriffsrechte und die Unterstützung durch Version und Edition.

Keines der Verfahren erzeugt automatisch ein unveränderliches Auditarchiv. Bereinigung entfernt Historie, Administratoren können Einstellungen ändern, und technische Änderungsdaten erklären nicht zwingend den Benutzer oder fachlichen Grund.

Kontrollpunkte gehören zum Datenbestand

Ein Change-Tracking-Verbraucher speichert die zuletzt erfolgreich angewendete Version. Vor dem Weiterlesen muss diese mit der kleinsten noch gültigen Version der Tabelle verglichen werden.

-- Replace dbo.Products with an existing tracked table.
SELECT CHANGE_TRACKING_CURRENT_VERSION() AS CurrentVersion,
       CHANGE_TRACKING_MIN_VALID_VERSION(
           OBJECT_ID(N'dbo.Products')
       ) AS MinimumValidVersion;

Ein älterer Kontrollpunkt ist nicht mehr zuverlässig. Benötigte Metadaten wurden bereits entfernt; einfach fortzufahren kann veraltete Zielzeilen zurücklassen. Erstellen Sie stattdessen einen konsistenten neuen Ausgangsbestand. Auch NULL muss untersucht werden, etwa hinsichtlich Tabellenkonfiguration und Rechten, und darf nicht als Version null im numerischen Sinn gelten.

Für eine konsistente Extraktion werden Kontrollpunktprüfung, nächste Version und Lesen der Änderungen samt Ursprungszeilen nach dem dokumentierten Snapshot-Isolation-Verfahren zusammengeführt. Snapshot-Isolation muss vorher aktiviert sein. Für Löschungen ist ein LEFT JOIN von den geänderten Schlüsseln erforderlich, da die Quellzeile fehlen kann. Materialisieren Sie den benötigten Auszug innerhalb der konsistenten Sicht; halten Sie die Transaktion nicht während langsamer Netzwerkübertragung offen.

Zieländerungen und Fortschreibung des Zielkontrollpunkts sollten möglichst atomar erfolgen. Andernfalls muss eine wiederholte Lieferung unschädlich sein. Ein zu früh fortgeschriebener Kontrollpunkt riskiert Verlust; eine Zielbestätigung ohne Wiederholungsschutz riskiert doppelte Verarbeitung.

CDC verwendet LSN-Grenzen statt Change-Tracking-Versionen. Beachten Sie den verfügbaren Bereich der Erfassungsinstanz und inklusive Abfragegrenzen. Für den nächsten Bereich dient die dokumentierte Funktion zur nächsten LSN, keine selbst erfundene Binärarithmetik.

Wiederherstellung vor dem Zeitplan entwerfen

Die Aufbewahrungszeit muss den längsten plausiblen Ausfall einschließlich Aufholzeit und Reserve abdecken. Überwachen Sie den verbleibenden Abstand jedes Verbrauchers zum Historienverlust. Ein erfolgreicher Polling-Job beweist wenig, wenn die eigentliche Erfassung stillsteht.

Prüfen Sie Erstbefüllung bei laufenden Schreibzugriffen, Löschungen, Mehrfachänderungen, Absturz nach Ziel-COMMIT und Ausfall über die Aufbewahrungsgrenze. Ein Ausgangsbestand und ein unpassend späterer Kontrollpunkt können Änderungen dazwischen dauerhaft verlieren.

Auch Schemaänderungen brauchen Abstimmung. Eine neue Quellspalte erscheint nicht automatisch in einer vorhandenen CDC-Erfassungsinstanz. Koordinieren Sie Erfassung und Zielschema. Die passende Funktion ist erst zusammen mit einem erprobten Wiederanlaufverfahren eine vollständige Lösung.

Technische Referenzen: Microsoft Learn: Change Tracking · Microsoft Learn: Change Data Capture · Microsoft Learn: Working with Change Tracking.