Como Resolver o Erro de Transaction Log Cheio por causa do CDC no SQL Server

Gerenciar ambientes críticos exige atenção a detalhes que vão muito além dos comandos tradicionais de manutenção. Recentemente, durante um plantão de monitoramento no Grafana, me deparei com um alerta de espaço em disco (Low Disk Space) que parecia ser apenas mais um ciclo de crescimento do Transaction Log. No entanto, a causa raiz revelou um comportamento complexo envolvendo o Change Data Capture (CDC) e a retenção de LSN. Neste artigo, mostro o raciocínio que utilizei para solucionar esse incidente em produção sem causar downtime. 

O alerta mostrava que o disco H: estava com menos de 1% de espaço disponível. De imediato, presumi que podia se tratar do disco de Transaction Log, o que naturalmente acendeu um sinal de alerta. A prioridade naquele momento era clara - liberar espaço em disco para manter o sistema operando, mas principalmente garantir a consistência e a durabilidade das informações persistidas no arquivo de transaction log. 

Qualquer ação de forma impensada ali poderia comprometer a sequência de LSN (Log Sequence Number) e, em um cenário de falha, inviabilizar uma recuperação point-in-time. O transaction log é o coração do banco de dados, ele registra todas as transações e cada modificação feita por elas. Perder esse histórico simplesmente não era uma opção.

Ao acessar o servidor, confirmei que o disco tinha 2 TB e que, de fato, se tratava do volume de Transaction Log, exatamente como eu havia previsto. Iniciei imediatamente alguns backups de log, utilizando uma ferramenta que persistia esses backups em nuvem. Os backups estavam sendo executados com sucesso, mas, mesmo assim, o espaço em disco não era liberado com a execução do shrink, o log continuava crescendo.

Nesse ponto, ficou claro que realizar somente os backups de log e em seguida shrink, não iria liberar o Transaction Log, havia algo a mais que estava impedindo o truncamento do log. Comecei então a investigar possíveis transações ativas. Havia algumas em execução, mas nada que justificasse aquele comportamento. O ambiente estava relativamente tranquilo, sem carga relevante da aplicação. 

 

Foi quando algo específico chamou minha atenção - o job de CDC Cleanup estava em execução, rodando um DELETE TOP sobre uma tabela de CDC que dei o nome de "Exemplo". Era um típico processo de limpeza de dados antigos das tabelas CDC.

Não necessariamente esse DELETE era o responsável por segurar o transaction log. No entanto, após algumas verificações adicionais, ficou claro que não havia muita atividade no banco nem processos relevantes abertos pela aplicação. O ambiente estava relativamente tranquilo para justificar um log praticamente exaurido.

Nesse banco de dados, caso fosse necessário, eu tinha autorização para interromper o job de CDC Cleanup temporariamente. E após algumas tentativas, incluindo backups, análises e algumas abordagens com scripts, decidi parar temporariamente o job de cleanup. 

Importante ressaltar que a interrupção foi temporária, acompanhada de monitoramento contínuo e adotada como uma medida controlada de contingência, respeitando as premissas de consistência e recuperação do banco de dados. 

Tive uma surpresa, logo em seguida executando a consulta abaixo, observei uma mudança importante:

A coluna log_reuse_wait_desc, que antes indicava ACTIVE_TRANSACTION, passou a mostrar REPLICATION. Esse detalhe mudou completamente o foco da análise. O log não estava preso por transações, mas aguardando o processamento relacionado a replicação do Change Data Capture (CDC). 

Apesar de ter ocultado algumas informações e não tê-las colocado no contexto deste artigo. Uma das primeiras coisas que eu já havia feito foi analisar o Error Log do SQL Server. Foi ali que encontrei informações importantes que ajudaram a fechar o raciocínio. Ao cruzar esses dados com a execução de um DBCC OPENTRAN, ficou evidente que ainda havia log retido pelo CDC devido a uma transação não distribuída.

Pesquisando mais a fundo, encontrei um artigo do Subhro Saha explicando exatamente esse cenário. O transaction log não é truncado quando os registros no início do log ainda estão pendentes de replicação ou captura pelo CDC. Enquanto o Log Reader ou o Job Capture não processarem esses registros, o SQL Server simplesmente não consegue reutilizar aquele espaço.

Uma das alternativas para esse tipo de situação é o uso do comando sp_repldone, que força o SQL Server a marcar transações pendentes como distribuídas ou capturadas. É uma abordagem paliativa, com implicações claras, e que deve ser utilizada com bastante cautela somente se não houver outra opção.

Após avaliar o cenário, realizar novos backups de log e considerando o risco iminente de esgotamento total do disco, optei por seguir com essa abordagem. A execução do comando abaixo marcou as transações pendentes como concluídas e permitiu a liberação do transaction log, sem qualquer downtime na aplicação do cliente.

O espaço foi imediatamente liberado e o ambiente e a aplicação continuou operando dentro da normalidade. Esse incidente reforçou algo importante - O Change Data Capture não é apenas um recurso de auditoria ou captura de alteração de dados. Ele tem impacto direto no ciclo de vida do transaction log e, em cenários específicos, pode se tornar o principal fator de retenção de log em ambientes críticos.

Considerações finais

Alertas como esse de Low Disk Space, retenção de transaction log ou comportamento inesperado de jobs fazem parte da rotina em diferentes níveis da carreira de um DBA. Com o tempo, a experiência ajuda a reconhecer padrões, avaliar riscos e tomar decisões mais conscientes.

A intenção deste artigo foi relatar o ocorrido de forma intuitiva e acessível, sem entrar excessivamente em detalhes técnicos, focando mais no raciocínio adotado durante o incidente do que em procedimentos passo a passo.

Vale destacar que a interrupção do job de CDC ocorreu de forma temporária e controlada, com monitoramento contínuo do ambiente. Nem todas as ações realizadas durante o incidente foram detalhadas neste artigo, considerando as particularidades de cada ambiente e os requisitos de compliance e LGPD.

Parar um job de CDC sem uma análise cuidadosa não é uma prática recomendada e, dependendo do cenário, pode até resolver um problema imediato, mas criar outros efeitos colaterais. Intervenções desse tipo exigem entendimento claro do impacto, planejamento e, sempre que possível faça backups adicionais, inclusive das tabelas de CDC, caso seja necessário algum tipo de manipulação.

Em ambientes críticos, decisões precisam equilibrar urgência e responsabilidade. E muitas vezes, mais importante do que a ação em si, é entender por que ela foi tomada e quais riscos estavam sendo administrados naquele momento. 

Referências

The transaction log

Troubleshoot a full transaction log (SQL Server Error 9002)

sp_repldone (Transact-SQL)

SQL Server: Log_Reuse_Wait_Desc definido como Replicação!!