Transacciones filtradas de SQL Server

Tengo una base de datos a la que acceden alrededor de 50 clientes a través de TDS a través de TCP que no parece estar liberando espacio de registro. El número de procesos se mantiene alrededor de los 50 esperados, y algunos de ellos duran bastante (> 120 días).

La base de datos ahora tiene 40 gb en espacio de registro (solo tiene datos de 14 gb), 39 gb libres. Debido a las limitaciones de espacio en la unidad, me gustaría reducir a algo más razonable (10 gb-ish). Cuando ejecuto DBCC SHRINKFILE('db_log', 10000), devuelve un error de que el final del registro está en uso.

Para liberar el acceso al final del registro, intenté colocar la base de datos en modo de usuario único con lo siguiente:

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

pero el script devuelve el siguiente mensaje repetido cientos de veces:

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

Lo que me lleva a creer que en algún lugar, estoy dejando algunas transacciones sin comprometer. No conozco ningún proceso que pueda abrir intencionalmente esta cantidad de transacciones a la vez, por lo que creo que deben acumularse con el tiempo, sin cerrarse nunca.

Pregunta: ¿Cómo ubico el proceso o script ofensivo o por qué no se publica el registro?

sys.dm_tran_active_transactionsestá mostrando 18 transacciones razonables con propósitos comprensibles. sp_whomuestra solo los procesos que conozco.

Versión de 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)

Versión del servidor:

Windows Server 2008 R2 x64: vCPU Datacenter 4, 16 GB de memoria, pase a través del disco para datos y registro, el disco del sistema operativo es VHD

en Hyper-V (Windows Server 2008 R2 SP1 x64 Datacenter) Dual Intel X5650 (6 núcleos, 12 hilos a 2,67 GHz) 72 GB de memoria

El hipervisor solo tiene tres máquinas virtuales y no muestra un alto uso de recursos. SQL Server VM muestra ~ 40% de CPU bajo carga y 99% de aciertos de caché.

Hay un comando SQL que mostrará las transacciones ABIERTAS. (DBCC OPENTRAN)

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

Muestra información sobre la transacción activa más antigua y las transacciones replicadas distribuidas y no distribuidas más antiguas, si las hay, dentro de la base de datos especificada. Los resultados se muestran solo si hay una transacción activa o si la base de datos contiene información de replicación

Por alguna razón, no parecía haber nada que mantuviera abierto el archivo de registro. Al ejecutar varias copias de seguridad del registro (> 10), se liberó el final del registro y se pudo producir la reducción. No estoy seguro de por qué ... pero funcionó.

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

Si entiendo su pregunta correctamente, ¿tiene un registro de transacciones de 40 Gb con 39 Gb gratis? El registro es una estructura circular, compuesta de archivos de registro virtuales más pequeños. Cada vez que un VLF está lleno, SQL comienza a usar el siguiente VLF. (No necesariamente en el mismo orden que los VLF están en el archivo). Cuando reduce el archivo de registro, libera espacio libre desde el FIN del registro. Si la parte activa del registro está al final, no se puede liberar espacio, si está en el medio en algún lugar, entonces solo podrá recuperar parte del espacio. DBCC LOGINFO le mostrará todos los VLF en el registro y un estado que indica que VLF contiene actualmente cualquier registro activo. Creo que el estado 2 está activo y 0 está inactivo. Estoy seguro de que Google puede proporcionar más información si es necesario.

Si su problema es solo que la parte activa está actualmente al final, entonces su mejor opción es esperar hasta que vuelva al inicio nuevamente, luego reduzca el registro. Esto puede tomar una cantidad sorprendente de tiempo, sea paciente. Llegará allí.
Recuerde también que si CUALQUIER parte de un VLF está actualmente activa, entonces todo el VLF se mantiene activo.

Sin embargo, debe controlar el tamaño del archivo de registro, si inesperadamente vuelve a crecer, deberá investigar un poco sobre la causa. Debe evitar la reducción innecesaria del archivo de registro, ya que cuando vuelva a crecer puede reducir el rendimiento.

Puede encontrar más información sobre VLF en la publicación del blog de Kimberly Tripps aquí .