Transações com vazamento do SQL Server

Eu tenho um banco de dados acessado por cerca de 50 clientes via TDS sobre TCP, que parece não estar liberando espaço para log. O número de processos permanece em torno dos 50 esperados e alguns deles têm uma vida útil bastante longa (> 120 dias).

O banco de dados agora possui 40 GB de espaço de log (possui apenas dados de 14 GB), 39 GB livres. Devido a limitações de espaço na unidade, eu gostaria de diminuir para algo mais razoável (10gb-ish). Quando executo DBCC SHRINKFILE('db_log', 10000), ele retorna um erro indicando que o final do log está em uso.

Para liberar o acesso ao final do log, tentei colocar o banco de dados no modo de usuário único com o seguinte:

ALTER DATABASE db SET SINGLE_USER WITH ROLLBACK IMMEDIATE
GO
ALTER DATABASE db SET MULTI_USER
GO

mas o script está retornando a seguinte mensagem repetida centenas de vezes:

Nonqualified transactions are being rolled back. Estimated rollback completion: 100%.

O que me leva a acreditar que, em algum lugar, estou deixando algumas transações não confirmadas. Não conheço nenhum processo que possa abrir intencionalmente tantas transações ao mesmo tempo, por isso acho que elas devem se acumular ao longo do tempo, nunca sendo fechadas.

Pergunta: Como localizo o processo ou script incorreto ou por que o log não está sendo liberado?

sys.dm_tran_active_transactionsestá mostrando 18 transações razoáveis ​​com propósitos compreensíveis. sp_whomostra apenas os processos que eu conheço.

Versão do SQL Server:

Microsoft SQL Server 2008 R2 (RTM) - 10.50.1600.1 (X64) 
Apr  2 2010 15:48:46 
Copyright (c) Microsoft Corporation
Enterprise Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) (Hypervisor)

Versão do servidor:

Windows Server 2008 R2 x64 - Datacenter 4 vCPUs, 16 GB de memória, Passagem de disco para dados e log, disco do sistema operacional é VHD

no Hyper-V (Datacenter x64 do Windows Server 2008 R2 SP1) Intel X5650 duplo (6 núcleos, 12 threads a 2,67 GHz) de memória de 72 GB

O hipervisor possui apenas três VMs e não mostra alto uso de recursos. A VM do SQL Server mostra ~ 40% da CPU sob carga e 99% de acertos no cache.

Existe um comando SQL que mostrará transações OPEN. (DBCC OPENTRAN)

http://msdn.microsoft.com/en-us/library/ms182792.aspx

Exibe informações sobre a transação ativa mais antiga e as transações replicadas distribuídas e não distribuídas mais antigas, se houver, no banco de dados especificado. Os resultados são exibidos apenas se houver uma transação ativa ou se o banco de dados contiver informações de replicação

Por qualquer motivo, parecia não haver nada mantendo o arquivo de log aberto. Ao executar vários backups de log (> 10), o final do log foi liberado e a redução pode ocorrer. Não sei por que ... mas funcionou.

backup log db to disk = '\\l-backup1\drop\2012-12-23_db_log.bak' with stats = 1
go 15
dbcc shrinkfile('db_log', 10240)
go

Se estou entendendo sua pergunta corretamente, você tem um log de transações de 40Gb com 39Gb grátis? O log é uma estrutura circular, composta por arquivos de log virtual menores. Cada vez que um VLF está cheio, o SQL começa a usar o próximo VLF. (Não necessariamente na mesma ordem em que os VLFs estão no arquivo). Quando você reduz o arquivo de log, ele libera espaço livre da END do log. Se a parte ativa do log estiver no final, nenhum espaço poderá ser liberado; se estiver no meio em algum lugar, você poderá recuperar apenas parte do espaço. O DBCC LOGINFO mostrará todos os VLFs no log e um status mostrando que o VLF contém atualmente qualquer log ativo. Eu acredito que o status 2 está ativo e 0 está inativo. Tenho certeza que o google pode fornecer mais informações, se necessário.

Se o seu problema é apenas que a parte ativa está atualmente no final, sua melhor aposta é apenas esperar até que ela volte ao início novamente e reduza o log. Isso pode levar uma quantidade surpreendente de tempo, seja paciente. Vai chegar lá.
Lembre-se também de que, se QUALQUER parte de uma VLF estiver atualmente ativa, a VLF inteira será mantida ativa.

No entanto, você deve monitorar o tamanho do arquivo de log; se ele crescer inesperadamente novamente, será necessário fazer uma investigação sobre a causa. Você deve evitar um encolhimento desnecessário do arquivo de log; quando crescer novamente, poderá diminuir o desempenho.

Mais informações sobre VLFs podem ser encontradas na publicação do blog Kimberly Tripps aqui .