Change Tracking o CDC: elegir el flujo correcto en SQL Server

Un buscador necesita saber qué productos cambiaron para actualizar sus documentos actuales. Un almacén analítico puede necesitar los valores anteriores y posteriores de cada modificación capturada. Aunque ambas tareas se llamen sincronización incremental, sus requisitos son distintos. Change Tracking y Change Data Capture resuelven partes diferentes del problema.

Primero decide si importan los estados intermedios. Si un precio cambia tres veces durante una interrupción, ¿basta el último o deben procesarse las tres modificaciones? Define también cómo propagar borrados. Consultar LastModified no descubre una fila eliminada, salvo que su eliminación se registre por separado.

Elegir el significado del flujo

Change Tracking registra claves primarias modificadas y metadatos del cambio. El consumidor consulta los valores actuales en la tabla original. Sirve para actualizar una representación del estado presente, no para reconstruir todas las transiciones. Varias modificaciones de una clave no equivalen a un registro completo de eventos del negocio. El seguimiento de columnas tampoco ofrece sus valores anteriores.

CDC lee modificaciones confirmadas del registro de transacciones y las guarda en tablas de captura. Según la opción de enumeración, permite obtener imágenes anteriores y posteriores o cambios netos. Existe retraso de captura: confirmar una transacción no significa que ya esté disponible en el rango CDC. En instalaciones convencionales de SQL Server también hay que atender los trabajos de captura y limpieza.

Esta consulta de solo lectura muestra configuración de base y tablas con 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;

Habilitar la función en la base no significa que todas las tablas estén incluidas. Comprueba tablas concretas, claves primarias, columnas, permisos y compatibilidad de la versión y edición utilizadas.

Ninguna función crea por sí sola una auditoría inmutable. La limpieza elimina historial, los administradores pueden modificar la configuración y los datos técnicos no necesariamente explican quién cambió algo ni por qué.

Incluir el punto de control en la consistencia

Un consumidor de Change Tracking guarda la última versión aplicada correctamente. Antes de solicitar más datos debe compararla con la versión mínima válida de cada tabla.

-- 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 punto anterior al mínimo ya no es seguro. Se han eliminado metadatos necesarios y continuar puede dejar filas obsoletas en el destino. Reinicializa desde una base coherente. Investiga también resultados NULL, incluida la configuración y los permisos, en vez de interpretarlos como cero.

Para extraer datos coherentes, valida el punto, captura la siguiente versión y enumera cambios junto con las filas originales usando el patrón documentado de aislamiento snapshot, que debe estar habilitado. Los borrados necesitan un LEFT JOIN desde las claves cambiadas porque puede faltar la fila original. Materializa el resultado dentro de esa lectura coherente y no mantengas la transacción durante una entrega de red lenta.

Aplica los cambios del destino y avanza su punto de control de forma atómica cuando sea posible. Si no, haz idempotente la entrega. Avanzar antes de confirmar el destino abre una ventana de pérdida; confirmar sin protección contra repeticiones abre una ventana de duplicados.

CDC utiliza límites LSN en lugar de versiones Change Tracking. Respeta el rango disponible y los extremos inclusivos de sus funciones. Utiliza la función documentada para obtener el siguiente LSN, sin inventar operaciones sobre sus valores binarios.

Diseñar la recuperación antes del calendario

La retención debe superar la interrupción máxima creíble, el tiempo de recuperación y un margen. Supervisa cuánto le queda a cada consumidor antes de perder historial utilizable. Un trabajo de consulta exitoso no basta si la captura está detenida y no entrega nada.

Prueba una carga inicial con escrituras concurrentes, borrados, varias modificaciones de la misma clave, una caída después del commit del destino y una interrupción mayor que la retención. Una copia inicial y un punto posterior sin relación consistente pueden perder cambios intermedios para siempre.

Los cambios de esquema también necesitan coordinación. Añadir una columna original no la añade automáticamente a una instancia CDC existente. Acuerda la evolución de captura y destino. La elección solo está completa cuando existe un procedimiento de recuperación ensayado.

Referencias técnicas: Microsoft Learn: Change Tracking · Microsoft Learn: Change Data Capture · Microsoft Learn: Working with Change Tracking.