Transactions préparées et verrouillage, diagnostic avec le traqueur
Posté : jeu. 12 févr. 2026 12:36
Merci à Thomas pour sa question :
"Un truc m'étonne sur le traqueur et je veux être sûr de bien comprendre.
J'ai un certain nombre de lock (transactionid) . Ok donc en attente depuis le client. J'interroge traqueur_bloqueurs_transactions et j'ai des enregistrements.
Tous les enregistrements de la journée d'hier dans traqueur_bloqueurs_transactions sont cette fameuse transaction préparée, et le dtcol coïncide avec tous les events locks. J'en déduis donc que c'est cette transaction préparée XA ouverte depuis 2 semaines qui provoque les lock. Comme je ne connais pas encore bien cette dernière table traqueur_bloqueurs_transactions , je voulais savoir si j'avais juste ou non ?"
Réponse :
Non, ça n'est pas suffisant pour conclure sur la culpabilité de la transaction préparée mais c'est idem au départ pour les sessions sans transactions préparées. La différence dans le diagnostic va se situer dans la possibilité de remonter jusqu'au(x) coupable(s) à coup sûr (si ce sont des des PID) ou de ne garder qu'un panel de suspectes (si ce sont des transactions préparées)
Sauf bug toujours possible, sont enregistrées dans traqueur_bloqueurs_transactions comme traqueurs_bloqueurs_process tous les potentiels bloqueurs, donc "trop" de lignes.
Les bloqueurs finaux, ceux qui bloquent les autres sans attendre eux-mêmes de verrous (attention, ils peuvent être en train de bosser tout simplement mais dans ce cas sont actifs et présents aussi dans traqueurs_sessions_actives), sont enregistrés dans la colonnes blockers de traqueurs_sessions_actives, transactions préparées et PID.
Il faut donc s'intéresser à la colonne blockers pour rechercher les coupables et joindre avec traqueur_bloqueur_processes dans le cas de PID. Il y a un gros bémol actuellement avec des transactions préparées, si une transaction préparée est une bloqueuse finale, c'est un 0 qui est écrit dans blockers (pas de PID donc pas de jointure possible avec traqueur_bloqueurs_process mais pas non plus de jointure possible même avec traqueur_bloqueurs_transactions ).
On n'obtient pas la transaction préparée coupable si il y a un 0 dans blockers de traqueurs_session_actives mais plusieurs lignes dans traqueur_bloqueurs_transactions à la date de collecte, il faut des investigations complémentaires hors tables du traqueur. Ce serait une évolution possible, il faudrait sans doute 2 colonnes et pas une colonne "fourre-tout" pour tout ce qui bloque.
"Un truc m'étonne sur le traqueur et je veux être sûr de bien comprendre.
J'ai un certain nombre de lock (transactionid) . Ok donc en attente depuis le client. J'interroge traqueur_bloqueurs_transactions et j'ai des enregistrements.
Tous les enregistrements de la journée d'hier dans traqueur_bloqueurs_transactions sont cette fameuse transaction préparée, et le dtcol coïncide avec tous les events locks. J'en déduis donc que c'est cette transaction préparée XA ouverte depuis 2 semaines qui provoque les lock. Comme je ne connais pas encore bien cette dernière table traqueur_bloqueurs_transactions , je voulais savoir si j'avais juste ou non ?"
Réponse :
Non, ça n'est pas suffisant pour conclure sur la culpabilité de la transaction préparée mais c'est idem au départ pour les sessions sans transactions préparées. La différence dans le diagnostic va se situer dans la possibilité de remonter jusqu'au(x) coupable(s) à coup sûr (si ce sont des des PID) ou de ne garder qu'un panel de suspectes (si ce sont des transactions préparées)
Sauf bug toujours possible, sont enregistrées dans traqueur_bloqueurs_transactions comme traqueurs_bloqueurs_process tous les potentiels bloqueurs, donc "trop" de lignes.
Les bloqueurs finaux, ceux qui bloquent les autres sans attendre eux-mêmes de verrous (attention, ils peuvent être en train de bosser tout simplement mais dans ce cas sont actifs et présents aussi dans traqueurs_sessions_actives), sont enregistrés dans la colonnes blockers de traqueurs_sessions_actives, transactions préparées et PID.
Il faut donc s'intéresser à la colonne blockers pour rechercher les coupables et joindre avec traqueur_bloqueur_processes dans le cas de PID. Il y a un gros bémol actuellement avec des transactions préparées, si une transaction préparée est une bloqueuse finale, c'est un 0 qui est écrit dans blockers (pas de PID donc pas de jointure possible avec traqueur_bloqueurs_process mais pas non plus de jointure possible même avec traqueur_bloqueurs_transactions ).
On n'obtient pas la transaction préparée coupable si il y a un 0 dans blockers de traqueurs_session_actives mais plusieurs lignes dans traqueur_bloqueurs_transactions à la date de collecte, il faut des investigations complémentaires hors tables du traqueur. Ce serait une évolution possible, il faudrait sans doute 2 colonnes et pas une colonne "fourre-tout" pour tout ce qui bloque.