Tempdb está crescendo e são todos os dados de armazenamento de versão. Quando eu corro:
select hostname,elapsed_time_seconds,session_id, transaction_id, is_snapshot, blocked, lastwaittype, cpu, physical_io, open_tran, cmd
from sys.dm_tran_active_snapshot_database_transactions a
join master..sysprocesses b
on a.session_id=b.spid
order by a.elapsed_time_seconds desc
Isso mostra duas sessões com decorridos_time_seconds quase 400.000 (~4,5 dias). No entanto, a coluna open_tran para essas sessões é zero toda vez que eu verifico. O aplicativo está usando transações implícitas - não tenho certeza se isso é relevante.
Além disso, o nome de host relatado para uma dessas sessões foi alterado (não, nem os endereços IP nem os nomes de host foram alterados) a partir desta manhã. Então, parece que talvez o cliente que tinha esse id de sessão esta manhã desconectado e outro cliente tem esse id de sessão agora.
Embora não mostre transações ativas para essas sessões na maioria das vezes, encontro transações que correspondem a transaction_id em sys.dm_tran_active_transactions com as seguintes propriedades:
transaction_begin_time: [~4.5 days ago]
name: DTCXact
transaction_type: 4
transaction_state: 2
transaction_status: 12
transaction_status2: 386
dtc_state: 1
dtc_status: 0
dtc_isolation_level: 4096
Existe uma maneira de explicar o que estou vendo? Se não houver transações abertas, por que eles ainda teriam algo ativo na loja de versões?
SQL Server 2014 SP2 12.0.5214.6
Esse problema foi causado por uma transação distribuída órfã. Como a transação é órfã, o ID da sessão é inválido quando você o vê. Para limpar a condição, encontre a transação mais antiga com um instantâneo ativo, pesquise a unidade de trabalho (UOW) e, em seguida, elimine o UOW.
Depois que ele for eliminado, execute a primeira consulta novamente para ver se há mais alguma que precise ser limpa.
Em alguns casos, você pode precisar encontrar o UOW encontrando primeiro transações órfãs, que devem ter um ID de sessão de -2.
Consulte Kill (Transact-SQL) para saber mais.