Deadlocks avec des select

Bonjour,

D'apres ce que j'ai compris, les deadlocks sont des sessions qui s'entre verouillent en accedant à des données.

Mon soucis est que j'ai un cas sous la main où les 2 sessions inceminées ne font que des select...:aie:

avez vous deja vu ca?

y'a pas l'audit sur tes tables par hasard ? Sinon, il y a peut-être un lock sur PLAN_TABLE... regarde dans v$lock ;)

en consultant la vue v$lock je n'ai pas d'info sur le plan_table.

voici un peu de detail :

http://img49.imageshack.us/img49/570...itregf7.th.jpg

c'est quoi la requette ? tu utilise select .... for update ?

Citation:

---

Envoyé par bouyao

c'est quoi la requette ? tu utilise select .... for update ?

---

voici la requete de la session bloquante :

SELECT "PROCDREFPRODUIT","OPEIDOPERATION","TOPTYPE" FROM "MV_PRODUIT_OPERATION_PREREF" "MV_PRODUIT_OPERATION_PREREF"

il manque un bout :ange:

Quelle est la version d'Oracle ?
Que donne:

Code:

---

1 2	select * from dba_blockers; select * from dba_waiters;

---

Un deadlock provoque une erreur ORA-00060 et un fichier trace côté serveur.
Est-ce le cas ?

Citation:

---

Envoyé par orafrance

il manque un bout :ange:

---

Si tu parles de la requete je ne crois pas.

Citation:

---

Envoyé par pifor

Quelle est la version d'Oracle ?
Que donne:

Code:

---

1 2	select * from dba_blockers; select * from dba_waiters;

---

Un deadlock provoque une erreur ORA-00060 et un fichier trace côté serveur.
Est-ce le cas ?

---

Oracle est en 9.2.0.1.

le 1er select renvoi le n° de la session bloquante.
le 2e :
Waiting session : 35
Holding session : 36
Lock-type : Distributed Xaction
Mode_held : Exclusive
Mode requested : Exclusive
Lock_id1 : 44
Lock_id2 : 0

Le plus surprenant c'est qu'il n'y a pas de ora-00060 ni de fichier trc généré... pourtant j'ai de l'espace disque dispo, j'ai d'autres ora-00060 mais pas celui-la.

A priori, la session 36 a un verrou exclusif demandé par la session 35. Si la session 36 fait COMMIT ou ROLLBACK le problème d'attente sera résolu.

là où ca se complique c'est que ces transactions se passent pas le biais d'un serveur Tomcat...

donc en gros c'est de toute facon un soucis de dev de l'application.

a quoi correspond PCT_FREE?

j'ai lu qu'etre proche de la limite pouvait aider à provoquer des deadlocks.

Ce n'est pas un deadlock, c'est a un verrou enqueue type DX : distributed transaction.
Je pense que tu utilise une requête distribué et tu ne fait pas de commit.

Citation:

---

donc en gros c'est de toute facon un soucis de dev de l'application.

---

Il suffit d'avoir 2 sessions qui essaient de mettre à jour la même ligne dans la même table pour avoir ce problème. Ce qui peut être anormal, c'est que la transaction bloquante dure trop longtemps et qu'il n'y a pas de durée maximale de transaction (time out) ni au niveau de l'instance ni au niveau applicatif.

Citation:

---

a quoi correspond PCT_FREE?
j'ai lu qu'etre proche de la limite pouvait aider à provoquer des deadlocks.

---

C'est un paramètre de stockage des blocs. Cela n'a rien a voir avec des problèmes de verrouillage sauf cas très particulier de la saturation de la Interested Transaction List (ITL) dans le bloc (mais dans ce cas il faut avoir plus que 2 transactions en jeu).

Citation:

---

Envoyé par bouyao

Ce n'est pas un deadlock, c'est a un verrou enqueue type DX : distributed transaction.
Je pense que tu utilise une requête distribué et tu ne fait pas de commit.

---

pas de commit en effet, puisque la requete ne fait qu'un select.

Citation:

---

Envoyé par pifor

Il suffit d'avoir 2 sessions qui essaient de mettre à jour la même ligne dans la même table pour avoir ce problème. Ce qui peut être anormal, c'est que la transaction bloquante dure trop longtemps et qu'il n'y a pas de durée maximale de transaction (time out) ni au niveau de l'instance ni au niveau applicatif.


C'est un paramètre de stockage des blocs. Cela n'a rien a voir avec des problèmes de verrouillage sauf cas très particulier de la saturation de la Interested Transaction List (ITL) dans le bloc (mais dans ce cas il faut avoir plus que 2 transactions en jeu).

---

apparement la session en question est ouverte depuis le 23 juillet...

Citation:

---

Envoyé par pholos

pas de commit en effet, puisque la requete ne fait qu'un select.

---

Certes, mais les choses cessent d'être aussi simples dans le cas de sélections distantes (via db links).

c'est vrai que nous utilisons beaucoup de dblinks mais je pense qu'il faudrait vraiment que vous regardiez les requetes qui s'interbloquent.

session bloquante

Code:

---

SELECT "PROCDREFPRODUIT","OPEIDOPERATION","TOPTYPE" FROM "MV_PRODUIT_OPERATION_PREREF" "MV_PRODUIT_OPERATION_PREREF"

---

session en attente

Code:

---

select value$ from props$ where name = 'GLOBAL_DB_NAME'

---

les connexions sont dedicated ou en shared server (paramètres shared_servers et mts%) ?

je sens bien un méchant bug genre le bug 2796282 corrigé en 9.2.0.5. :?

Faudrait nous en dire plus sur l'architecture pour identifier le bug : RAC, MV, MV log, DBlink, etc...

On peut aussi se poser la question de savoir si l'outil affiche vraiment les bonnes informations...En général, Oracle ne prend pas de verrou dans le cas de SELECT sauf si on utilise la clause FOR UPDATE. Si vous ouvrez 2 sessions différentes et exécutez les instructions SQL affichées par votre outil, les sessions sont-elles bloquées ? Qu'affiche votre outil dans ce cas-là ?

ta MV ne serait pas en cours de refresh par hasard ?

une trace en level 12 et un tkprof avec sys=yes ne serait pas superflus :ange: