Change Tracking ou CDC: choisir le bon flux SQL Server

Un index de recherche doit savoir quels produits ont changé pour relire leurs valeurs actuelles. Un entrepôt peut avoir besoin des anciennes et nouvelles valeurs de chaque modification capturée. Ces deux demandes sont souvent appelées synchronisation incrémentale, mais elles n'ont pas le même sens. Change Tracking et Change Data Capture répondent à des besoins différents.

Décidez d'abord si les états intermédiaires comptent. Après trois changements de prix pendant une interruption, le dernier prix suffit-il? Ou faut-il traiter chaque transition? Définissez aussi la propagation des suppressions. Une colonne LastModified ne permet pas de découvrir une ligne qui n'existe plus sans enregistrement séparé de sa suppression.

Choisir la bonne signification

Change Tracking conserve les clés primaires modifiées et des métadonnées. Le consommateur relit les valeurs actuelles dans la table source. Cela convient à une copie de l'état courant, pas à la reconstitution de toutes les transitions historiques. Plusieurs modifications d'une clé ne constituent pas un journal complet d'événements métier. Le suivi optionnel des colonnes ne fournit pas leurs anciennes valeurs.

CDC lit les modifications validées dans le journal transactionnel et les dépose dans des tables de capture. Selon l'option d'énumération, le consommateur obtient des valeurs avant et après ou des changements nets. Il existe un délai de capture: une transaction source validée n'est pas immédiatement disponible dans la plage CDC. Sur une installation SQL Server classique, les tâches de capture et de nettoyage doivent aussi être surveillées.

Cette inspection en lecture seule montre la configuration de la base et les tables utilisant 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;

L'activation au niveau de la base n'implique pas que toutes les tables participent. Vérifiez tables, clés primaires, colonnes capturées, autorisations et disponibilité selon la version et l'édition.

Aucune des deux fonctions ne fournit automatiquement une piste d'audit immuable. Le nettoyage supprime l'historique, la configuration peut changer et les métadonnées techniques n'expliquent pas forcément l'acteur ou la raison métier.

Rendre le point de reprise fiable

Un consommateur Change Tracking conserve la dernière version appliquée avec succès. Avant de poursuivre, il la compare à la version minimale encore valide de chaque table.

-- 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;

Un point plus ancien n'est plus sûr. Des métadonnées nécessaires ont été nettoyées; continuer peut laisser des lignes périmées dans la destination. Réinitialisez depuis une base cohérente. Un résultat NULL demande également une investigation sur la configuration et les droits, pas une conversion implicite vers zéro.

Pour une extraction cohérente, vérifiez le point, capturez la version suivante et lisez les changements avec les lignes source selon le schéma documenté utilisant l'isolation snapshot. Celle-ci doit être activée au préalable. Une suppression nécessite un LEFT JOIN depuis les clés modifiées puisque la ligne source peut manquer. Matérialisez l'extraction dans cette vue cohérente, puis terminez la transaction avant une livraison réseau lente.

Si possible, appliquez les changements et avancez le point de reprise dans une même transaction de destination. Sinon, rendez la livraison idempotente. Avancer le point avant la validation crée un risque de perte; valider sans protection contre la répétition crée un risque de doublon.

CDC utilise des limites LSN plutôt que des versions Change Tracking. Respectez la plage disponible et les bornes inclusives des fonctions. Pour passer à la plage suivante, utilisez la fonction documentée de LSN suivante, pas une arithmétique improvisée sur les valeurs binaires.

Préparer la reprise avant la planification

La rétention doit couvrir la plus longue interruption plausible, le rattrapage et une marge. Surveillez la distance de chaque consommateur à la perte de son historique. Un polling réussi ne suffit pas si la capture est arrêtée et ne fournit rien.

Testez un chargement initial pendant des écritures, une suppression, plusieurs changements de la même clé, une panne après validation de la destination et une interruption au-delà de la rétention. Une copie initiale associée à un point ultérieur sans cohérence peut manquer définitivement les changements intermédiaires.

Les évolutions de schéma demandent aussi un contrat. Ajouter une colonne source ne l'ajoute pas automatiquement à une instance CDC existante. Coordonnez capture et schéma cible. Le choix technique n'est complet qu'avec une procédure de reprise vérifiée.

Références techniques: Microsoft Learn: Change Tracking · Microsoft Learn: Change Data Capture · Microsoft Learn: Working with Change Tracking.