Version imprimable
Bonjour,
Étrange situation ce matin... nous avons des sessions qui ont ce wait, MSQL_XACT_MGR_MUTEX, J'ai killer la plus vielle session qui a ce wait mais voilà, elle ne kill pas. Je regarde avec kill with statusonly et toujours 0% completed. Nous avons 5 sessions qui ont ce wait. Les sessions qui sont dans le mutex sont relié à du monittoring (via des dmv) Est-ce que quelqu'un pourrait nous donner une piste d'investigation?
Output de sp_WhoIsActive
Pièce jointe 220770
Essayer de lancer cette command pour voir en détaille ce SPID
Code:dbcc inputbuffer(62)
MSQL_XACT_MGR_MUTEX'
il Se produit lorsqu''une tâche attend d''avoir obtenu la propriété du gestionnaire de transactions de la session pour effectuer une opération de transaction au niveau de la session
C'est vrai que la définition n'aide pas forcément plus comme ca :-)
Est-ce que tu utilises d'autres fonctionnalités comme le mirroring, CDC ou RCSI sur ton instance?
++
Bonjour,
Il semblerait qu'il y ait un problème de synchronisation dans les threads qui gèrent des transactions.
De ce que la documentation nous permet de penser, un des threads d'une transaction distribuée n'existe plus, mais empêche celle sur la base étudiée de se terminer.
- Est-ce que le KILL WITH STATUSONLY vous donne un quelconque progrès ?
- Est-ce que l'interrogation de la vue sys.dm_exec_requests pour les session_id qui ont ce wait vous retourne des lignes ?
Si la réponse à la deuxième question est non, interrogez la vue sys.dm_exec_connections pour trouver l'adresse IP et le port de la machine qui participe à la transaction distribuée (colonnes client_net_address et client_tcp_port). Il faut ensuite trouver le l'ID du processus sur cette machine, ce que l'on obtient en interrogeant sys.dm_exec_sessions (colonne host_process_id). Sur la machine cible, si vous ne trouvez pas l'ID du processus et que la commande netstat pour les ports concernés ne vous retourne rien, c'est que la transaction sur la base de données étudiée est orpheline.
A ce stade, vous avez deux options :
- Soit vous attendez que le ROLLBACK se termine, et cela peut être très long
- Soit, si vous êtes en édition Enterprise, vous prenez une sauvegarde complète de toutes les bases de données hébergées par l'instance en question, immédiatement ensuite, vous exécutez un CHECKPOINT de la même manière, et encore immédiatement ensuite, vous redémarrez le service SQL Server.
La deuxième solution est moche, mais sous cette édition de SQL Server, la phase d'annulation d'une transaction se fait en arrière plan (phase UNDO du processus de récupération d'une base de données). Les applications devraient avoir accès à la base de données dès la fin de la phase REDO, qui est exécutée avant cela. Il est cependant possible que durant la phase d'UNDO, l'acquisition de verrous pour terminer l'annulation de la transaction vous cause des situation de blocage.
@++ ;)
En gros, vous avez un peu le choix entre la peste et le choléra.
