Suspect database – MSDTC in-doubt transaction

Em uma bela madrugada, onde todas as coisas obscuras aparecem, um dos servidores de um cluster falhou e executou um failover para um outro nó. Até esse momento nada de estranho e esse é o comportamento esperado.

Problema

Ao verificar os bancos de dados da instancia que sofreu o failover me deparei com o status de “suspect” em um deles. Nesse ponto começou a investigação de como isso aconteceu e como resolver!

Consegui encontrar no errorlog as seguintes mensagens:

Attempting to initialize Microsoft Distributed Transaction Coordinator (MS DTC). This is an informational message only. No user action is required.

QueryInterface failed for “DTC_GET_TRANSACTION_MANAGER_EX::ITransactionDispenser”: 0x80004005(failed to retrieve text for this error. Reason: 15105).

QueryInterface failed for “ITransactionDispenser”: 0x80004005(failed to retrieve text for this error. Reason: 15105).

Attempting to initialize Microsoft Distributed Transaction Coordinator (MS DTC). This is an informational message only. No user action is required.

SQL Server detected a DTC/KTM in-doubt transaction with UOW  {07372A47-24B9-4BC3-A651-0260624FFF8E}. Please resolve it following the guideline for Troubleshooting DTC Transactions.

An error occurred while recovering database ‘XXX’. Unable to connect to Microsoft Distributed Transaction Coordinator (MS DTC) to check the completion status of transaction (0:-222014414). Fix MS DTC, and run recovery again.

An error occurred during recovery, preventing the database ‘XXX’ (database ID 5) from restarting. Diagnose the recovery errors and fix them, or restore from a known good backup. If errors are not corrected or expected, contact Technical Support.

A aplicação que utilizava essa database também utilizava Microsoft Distributed Transaction Coordinator (MSDTC) e tudo indicava que alguma coisa se perdeu no caminho da comunicação entre o MSDTC da aplicação e do banco de dados.

No meu caso eu tinha um agravante: o cluster não possuía uma instância do MSDTC, ou seja, utilizava o MSDTC local.

Quando uma instância do SQL Server 2008 ou superior é inicializada em um cluster, ela tenta encontrar uma instância do MSDTC para comunicação na seguinte ordem:

  • Dentro do grupo do cluster onde reside o recurso do SQL Server
  • Dentro de outros grupos do cluster
  • Instância MSDTC local

Resolução

Eu não sabia o que tinha acontecido com MSDTC e resolvi tomar uma ação para deixar meu banco de dados online e depois tentar resolver qualquer problema.

Utilizei o comando abaixo:

sp_configure ‘show advanced options’, 1
go
reconfigure
go
sp_configure ‘in-doubt xact resolution’, 2
go
reconfigure
go
sp_configure ‘show advanced options’, 0
go
reconfigure
go

E depois trouxe o banco de dados ONLINE.

Podem existir outras formas de resolver esse problema, porem essa ação permitiu que meu banco dados ficasse online e pude executar um DBCC CHECKDB que para meu alivio retornou sem nenhum erro!

Antes de liberar meu banco de dados para produção novamente voltei a configuração padrao

sp_configure ‘in-doubt xact resolution’, 0
go
reconfigure
go

Outra alterativa seria vizualizar a view sys.dm_tran_active_transactions, essa view mostra algumas informações sobre  as transações com uso do MSDTC.

Os campos: transaction_uow, transaction_state, dtc_state são campos que devem ser olhados com cuidado em uma analise pois contem informaçoes importantes.

MDCTS-01

O campo transaction_uow pode ser relacionado com o Unit of Work ID dentro da lista de transações do MSDTC.

MDCTS-02

Assim você pode identificar o status da sua transação e pode tomar a ação necessária que cabe ao seu ambiente.

Conclusão

Quando a instância SQL Server executou um failover para o outro nó do cluster, a instância passou a se comunicar com o MSDTC local do novo nó, que não tinha informações das transações registradas no nó anterior.

Ao tentar iniciar o processo de recovery do banco de dados, o SQL Server encontrou informações sobre transações distribuídas que não haviam sido terminadas (confirmadas ou abortadas) antes da falha. O SQL Server entrou no processo de validar as informações do LOG e questionou o MSDTC a respeito das transações, e o novo MSDTC local não tinha informações a respeito destas transações. Por esse motivo o SQL Server não foi capaz de resolve-las e desta forma interrompeu o processo de recovery ocasionando o estado de “suspect”

A melhor solução para que isso não ocorra é ter uma instancia do MSDTC dentro do cluster.

Referências:

How to configure DTC for SQL Server in a Windows 2008 cluster

Opção de configuração de servidor in-doubt xact resolution

sys.dm_tran_active_transactions

 

Maníaco, entusiasta, fascinado, fanático por SQL Server e nas horas vagas um DBA que adora o que faz! Também possui certificações como: MCT, MCSE - Data Management and Analystics, MCSE - Data Plataform e MCSA - SQL Server 2016/2014/2012

Responda