Transactions fuites SQL Server

J'ai une base de données accessible par environ 50 clients via TDS sur TCP qui ne semble pas libérer d'espace de journal. Le nombre de processus reste autour des 50 attendus, et certains d'entre eux ont une durée de vie assez longue (> 120 jours).

La base de données dispose désormais de 40 Go d'espace de journalisation (elle ne dispose que de 14 Go de données), dont 39 Go gratuits. En raison des limites d'espace sur le lecteur, je voudrais réduire à quelque chose de plus raisonnable (10 Go-ish). Lorsque j'exécute DBCC SHRINKFILE('db_log', 10000), il renvoie une erreur indiquant que la fin du journal est en cours d'utilisation.

Afin de libérer l'accès à la fin du journal, j'ai tenté de placer la base de données en mode mono-utilisateur avec les éléments suivants:

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

mais le script renvoie le message suivant répété des centaines de fois:

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

Ce qui m'amène à croire que quelque part, je laisse certaines transactions sans engagement. Je ne connais aucun processus qui ouvrirait intentionnellement autant de transactions en même temps, donc je pense qu'elles doivent s'accumuler au fil du temps, sans jamais être fermées.

Question: Comment localiser le processus ou le script incriminé ou pourquoi le journal n'est-il pas publié?

sys.dm_tran_active_transactionsaffiche 18 transactions raisonnables à des fins compréhensibles. sp_whomontre uniquement les processus que je connais.

Version 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)

Version du serveur:

Windows Server 2008 R2 x64 - processeurs virtuels Datacenter 4, 16 Go de mémoire, disque de transfert pour les données et le journal, le disque du système d'exploitation est un disque dur virtuel

sur Hyper-V (Windows Server 2008 R2 SP1 x64 Datacenter) Dual Intel X5650 (6 cœurs, 12 threads à 2,67 GHz) 72 Go de mémoire

L'hyperviseur n'a que trois machines virtuelles et n'affiche pas une utilisation élevée des ressources. La machine virtuelle SQL Server affiche ~ 40% de CPU sous charge et 99% de hits de cache.

Il existe une commande SQL qui affichera les transactions OPEN. (DBCC OPENTRAN)

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

Affiche des informations sur la transaction active la plus ancienne et les transactions répliquées distribuées et non distribuées les plus anciennes, le cas échéant, dans la base de données spécifiée. Les résultats sont affichés uniquement s'il existe une transaction active ou si la base de données contient des informations de réplication

Pour une raison quelconque, rien ne semblait contenir le fichier journal ouvert. En exécutant plusieurs sauvegardes de journaux (> 10), la fin du journal a été libérée et la réduction pourrait se produire. Je ne sais pas pourquoi ... mais cela a fonctionné.

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 je comprends bien votre question, vous avez un journal des transactions de 40 Go avec 39 Go gratuits? Le journal est une structure circulaire, composée de fichiers journaux virtuels plus petits. Chaque fois qu'un VLF est plein, SQL commence à utiliser le VLF suivant. (Pas nécessairement dans le même ordre que les VLF sont dans le fichier). Lorsque vous réduisez le fichier journal, il libère de l'espace libre à la FIN du journal. Si la partie active du journal est à la fin, aucun espace ne peut être libéré, s'il se trouve quelque part au milieu, vous ne pourrez récupérer qu'une partie de l'espace. DBCC LOGINFO vous montrera tous les VLF dans le journal et un état indiquant que le VLF contient actuellement tout journal actif. Je crois que le statut 2 est actif et 0 est inactif. Je suis sûr que Google peut fournir plus d'informations si nécessaire.

Si votre problème est simplement que la partie active est actuellement à la fin, alors votre meilleur pari est simplement d'attendre qu'elle roule au début, puis de réduire le journal. Cela peut prendre un temps surprenant, soyez patient. Il y arrivera.
Souvenez-vous également que si TOUT élément d'une VLF est actuellement actif, la totalité de la VLF reste active.

Vous devez cependant surveiller la taille du fichier journal, s'il augmente à nouveau de manière inattendue, vous devrez alors enquêter sur la cause. Vous devez éviter de réduire inutilement le fichier journal, car lorsqu'il repousse, il peut ralentir les performances.

Vous trouverez plus d'informations sur les VLF dans le blog de Kimberly Tripps ici .