Change Tracking ou CDC: escolher o fluxo certo no SQL Server

Um mecanismo de busca precisa saber quais produtos mudaram para atualizar seus documentos atuais. Um data warehouse pode precisar dos valores anteriores e posteriores de cada atualização capturada. As duas necessidades costumam receber o nome de sincronização incremental, mas têm significados diferentes. Change Tracking e Change Data Capture atendem partes distintas desse problema.

Primeiro decida se estados intermediários importam. Se o preço muda três vezes enquanto o consumidor está parado, basta o preço final ou todas as mudanças precisam ser processadas? Defina também a propagação de exclusões. Consultar LastModified não encontra uma linha que deixou de existir, a menos que a exclusão seja registrada separadamente.

Escolher a semântica do fluxo

Change Tracking registra chaves primárias alteradas e metadados. O consumidor lê os valores atuais na tabela de origem. Isso atende à atualização de uma representação do estado corrente, não à reconstrução de todas as transições históricas. Mudanças repetidas na mesma chave não formam um registro completo de eventos de negócio. O acompanhamento de colunas também não fornece valores anteriores.

CDC lê alterações confirmadas do log de transações e grava tabelas de captura. Conforme a opção de enumeração, o consumidor recebe valores anteriores e posteriores ou mudanças líquidas. Existe latência: uma transação confirmada pode ainda não estar disponível no intervalo CDC. Em instalações convencionais de SQL Server, os trabalhos de captura e limpeza também precisam de acompanhamento.

Esta inspeção de leitura mostra a configuração da base e as tabelas com 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 a função na base não inclui automaticamente todas as tabelas. Confira tabelas específicas, chaves primárias, colunas, permissões e suporte da versão e edição utilizadas.

Nenhum dos recursos cria automaticamente uma trilha de auditoria imutável. A limpeza remove histórico, administradores podem mudar a configuração e os registros técnicos não necessariamente identificam o responsável ou a razão de negócio.

Tratar o checkpoint como parte dos dados

O consumidor de Change Tracking guarda a última versão aplicada com sucesso. Antes de continuar, deve compará-la à versão mínima válida de cada tabela.

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

Um checkpoint anterior ao mínimo deixou de ser seguro. Metadados necessários foram removidos; continuar silenciosamente pode deixar linhas desatualizadas no destino. Reinicialize a partir de uma base consistente. Investigue resultados NULL, incluindo configuração e permissões, sem tratá-los como versão zero.

Para uma extração coerente, valide o checkpoint, capture a próxima versão e leia alterações junto com as linhas originais no padrão documentado de isolamento snapshot, previamente habilitado. Exclusões exigem um LEFT JOIN partindo das chaves alteradas, pois a linha original pode faltar. Materialize a extração nessa visão consistente antes de encerrar a leitura; não mantenha a transação durante uma transmissão de rede lenta.

Sempre que possível, aplique as alterações e avance o checkpoint em uma transação do destino. Caso contrário, torne a entrega idempotente. Avançar antes da confirmação abre uma janela de perda; confirmar sem proteção contra repetição abre uma janela de duplicação.

CDC utiliza limites LSN em vez de versões Change Tracking. Respeite o intervalo disponível e os extremos inclusivos das funções. Para avançar entre intervalos, utilize a função documentada que calcula o próximo LSN, sem improvisar aritmética com valores binários.

Preparar a recuperação antes do agendamento

A retenção deve superar a maior parada plausível, o tempo de recuperação e uma margem. Monitore a distância de cada consumidor até perder o histórico necessário. Uma consulta executada com sucesso não basta quando a captura está parada e não produz dados.

Teste carga inicial com gravações concorrentes, exclusões, várias mudanças na mesma chave, falha após commit no destino e indisponibilidade além da retenção. Uma cópia inicial associada a um checkpoint posterior sem consistência pode perder mudanças intermediárias definitivamente.

Mudanças de esquema também exigem contrato. Adicionar uma coluna na origem não a inclui automaticamente em uma instância CDC existente. Coordene captura e esquema do destino. A solução só está completa com um procedimento de recuperação realmente exercitado.

Referências técnicas: Microsoft Learn: Change Tracking · Microsoft Learn: Change Data Capture · Microsoft Learn: Working with Change Tracking.