Discussion :

[Pozzo]

Bonjour,

Il y a un soucis de deadlock sur mon appli.
Je connais l'ordre SQL qui est bloqué et son emplacement dans le package PLSQPL concerné grâce au fichier trace généré par Oracle.
Reste à déterminer l'emplacement de l'ordre SQL qui a bloqué la ligne.

Dans le cas de mon autonomous transaction le scénario est le suivant :
La transaction mère supprime une ligne.
Elle appelle une procédure autonome qui supprime la même ligne.
La fille attend que la mère libère la ligne avec un commit.
Elle ne rend donc pas la main à la mère qui est bloquée à son tour.
=> Deadlock

Pour éviter cela nous utilisons une règle qui dit qu'une table est géré que par transaction autonome ou sans aucune transaction autonome. (tout ou rien).
Pas dur.

Sauf que là je pense que cette règle a été transgressée.

Ma question est :
"Est ce que le contenu du fichier trace (15250 lignes) est sensé me donner l'emplacement (PlSql + Sql) du verrouillage de la ligne ?"

J'ai fureté un peu, lu le doc 62365.1 mais l'interprétation du fichier trace me semble peu documentée.

Une idée ?
Pozzo

Je suis donc à la recherche de l'odre delete

[pachot]

Bonjour,

SQL_TRACE (event 10046) ne donnera pas directement qui a posé un lock, mais peut permettre de le deviner en regardant les requêtes qui peuvent avoir touché la ligne en question.
Les locks peuvent être tracés par l'event 10704.
Si c'est un verrou TM (niveau table) on le voit. Si c'est un verrou TX (niveau ligne) alors les verrou TM correspondant (mode 2 ou 3) donnera peut être un indication.

Mais probablement pas besoin d'aller jusque là. C'est au design qu'il y a un problème. Pour quelle raison cette autonomous transaction ? Les cas qui justifient son utilisation sont très rares.

Cordialement,
Franck.

[Pozzo]

Merci Pacho,

Je vais regarder dans la direction du 10704.

Plutôt que le 10046 je pense aussi faire un trigger en utilisant "who called me" ça sera moins vaste à dépouiller.

Pour répondre à ta question oui c'est un problème de design. Plus exactement un problème ne non respect des règles imposées par le design.

Sur l'appli 3 tables ne doivent pas dépendre de la session principale. Ce sont des tables de log :
Un traitement peut effectuer un rollback ou un commit mais la log est toutjours "commitée" car quoi qu'il se passe on doit pouvoir le savoir.
J'utilise donc une transaction autonome.
Il se trouve qu'une action dans la session mère manipule certainement les mêmes données d'où le deadlock et ma recherche.

En tout cas merci.

En revanche j'ai cherché à droite et à gauche mis à part Larry Ellison et l'ainé de ses neveux (le rouquin sympa mais un peu énervant) personne ne semble savoir comment analyser complètement la log générée par un deadlock.

A+
Pozzo

[pachot]

Un traitement peut effectuer un rollback ou un commit mais la log est toutjours "commitée" car quoi qu'il se passe on doit pouvoir le savoir.
J'utilise donc une transaction autonome.
Il se trouve qu'une action dans la session mère manipule certainement les mêmes données d'où le deadlock et ma recherche.

Effectivement c'est le cas d'utilisation des autonomous transaction... sauf que la transaction principale ne devrait pas y toucher.

En revanche j'ai cherché à droite et à gauche mis à part Larry Ellison et l'ainé de ses neveux (le rouquin sympa mais un peu énervant) personne ne semble savoir comment analyser complètement la log générée par un deadlock.

Tu peux poster la trace du deadlock. si c'est un verrou TX, on devrait pouvoir y retrouver les rowid sans l'aide de Larry

[Pozzo]

Oui la transaction principale est bien fautive.

Retrouver le rowid ne m'avancera pas à grand chose et il est dedans.
C'est le programme (ou la requête à partir de laquelle je tenterai de trouver le programme) que je cherche.

Je poste le rapport.

Merci

[pachot]

Retrouver le rowid ne m'avancera pas à grand chose et il est dedans.

C'est le programme (ou la requête à partir de laquelle je tenterai de trouver le programme) que je cherche.

Une idée: avant de lançer l'appli, tu vérouille la table pour bloquer là où un verrou est posé. Et lorsque c'est en attente, alors tu peux investiguer dans v$session.

Sinon, en examinant, le tkprof tu verras toutes les requêtes. Peut-être que tu pourras identifier lesquelles sont susceptibles de vérouiller la table en question (pas toujours évident lorsque c'est vérouillé par de l'intégrité référentielle).