Lecture d'un deadlock

Version imprimable

Bonjour,

J'aurai besoin d'une petite aide, j'ai obtenu un deadlock pour un traitement et j'ai eu deux fois la même requête qui ressort.
Je l'ai signalé donc aux développeurs, de ne plus faire tourner le traitement plusieurs fois en même temps afin d'éviter ce problème.

Le deadlock graph est le suivant :
Code:

1 2 3 4 5 Deadlock graph: ---------Blocker(s)-------- ---------Waiter(s)--------- Resource Name process session holds waits process session holds waits TXblabla 33 56 X 37 52 S TXblabla2 37 52 X 33 56 S
Mais en parallèle, j'ai regardé l'objet bloqué à l'aide de ces requêtes :
Code:

1 2 3 4 => select dbms_rowid.rowid_object('XXX') from dual; 999 => select object_name from all_objects where object_id = 999; TableX
Il en ressort qu'il s'agit de la table TableX qui est bloquante qui n'a rien à voir avec la requête exécuté.
La requête exécuté est :

Code:

=> insert into TableY (a,b,c) values (a,b,c);

Merci pour votre aide.

15/12/2014, 10h18
aieeeuuuuu

Bonjour,

La TableY aurait-elle une contrainte d'intégrité référançant la TableX ?
Auquel cas, une insertion dans Y pose en effet des verrous sur X afin de valider cette contrainte...
15/12/2014, 10h56
skyarnangel

Bonjour,

Merci pour le coup de pouce, je n'y avais pas pensé, mais ce n'est pas ça.
Les tables X et Y n'ont qu'une seule contrainte qui est leurs clés primaires.

Bonjour,
Citation:
Envoyé par skyarnangel
Bonjour,

Le deadlock graph est le suivant :
Code:

1 2 3 4 5 Deadlock graph: ---------Blocker(s)-------- ---------Waiter(s)--------- Resource Name process session holds waits process session holds waits TXblabla 33 56 X 37 52 S TXblabla2 37 52 X 33 56 S
Vous avez deux Transaction Enqueues (TX) prises sur un mode X et attente sur un mode S(Share). Il y a deux possibilités dans ce cas qui peuvent résulter d'un pareil deadlock graph

Existence d'un ou de plusieurs Bitmap indexes dans votre application (sur vos tables en deadlock au moins)
Primary key ou unique key overlapping

La partie du deadlock graph qui suit (ce que vous avez déjà posté) montre les SQL en conflit. Vous avez déjà identifié un insert. Il faut voir alors le deuxième SQL. Si c'est également un insert alors je pencherai plutôt pour une primary key/unique key overlapping. Sinon c'est la présence d'un bitmap indexe

https://hourim.wordpress.com/2011/03...-bitmap-index/

Pour votre information il ne peut y avoir un deadlock du à une Foreign key non indexée sans la présence d'au moins un TM enqueue dans le deadlock graph
Bien à vous

15/12/2014, 11h57
skyarnangel
Bonjour,

Merci pour votre aide, mais je n'ai pas pu profiter de votre lien, on m'indique une adresse introuvable ?

Les sessions qui ont provoqués le deadlock montrent la même requête, j'en ai conclu que le programme a été lancé 2 fois en même temps et est entré en conflits.

J'ai vérifié, et il n'y a pas de bitmap index sur mes tables
Code:

1 2 3 4 5 select distinct INDEX_TYPE from user_indexes where table_name in ('TABLEX', 'TABLEY'); INDEX_TYPE --------------------------- NORMAL
Je pense que le problème se situe sur la deuxième option.

Mais, ma question vient sur le fait que l'objet bloqué est la table X alors que les requêtes font une insertion sur la table Y.

J'espérai m'être trompé lorsque j'ai posté mes requêtes qui interrogent les tables contenant les rowid ou quelque chose comme ça, mais ça ne semble choquer personne.

Serait il possible que les requêtes SQL qui sortent dans le fichier traces ne soient pas celles à l'origine du deadlock ?
15/12/2014, 12h21
Mohamed.Houri

Citation:

Envoyé par skyarnangel

Bonjour,
Serait il possible que les requêtes SQL qui sortent dans le fichier traces ne soient pas celles à l'origine du deadlock ?

Elles font forcément partie du deadlock.

Ce que par contre, ne vous dit pas le deadlock graph, c'est qu'il est possible que vous ayez plusieurs autres objets impliqués dans le deadlock mais qui n'apparaissent pas dans le deadlock graph.

Est-ce que vous pouvez poster la partie qui contient les deux sql et particulièrement la partie Rows waited on:

Bien à vous
Mohamed Houri

Bonjour,

Voici ce que vous m'avez demandé :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
 
DEADLOCK DETECTED
Current SQL statement for this session:
insert into TABLEY(a,b,c) values (a1,b1,c1)
The following deadlock is not an ORACLE error. It is a
deadlock due to user error in the design of an application
or from issuing incorrect ad-hoc SQL. The following
information may aid in determining the deadlock:
Deadlock graph:
                       ---------Blocker(s)--------  ---------Waiter(s)---------
Resource Name          process session holds waits  process session holds waits
TX-AAA                   33      53     X             37      51           S
TX-AAA                   37      51     X             33      53           S
 
session 53: DID 0001-0021-000000C1	session 51: DID 0001-0025-00000060
session 51: DID 0001-0025-00000060	session 53: DID 0001-0021-000000C1
 
Rows waited on:
Session 51: obj - rowid = 99X99X9X - XXpoxeXXXAAAAAAAA
  (dictionary objn - 999, file - 10, block - 0, slot - 0)
Session 53: obj - rowid = 99X99X9X - XXpoxeXXXAAAAAAAA
  (dictionary objn - 999, file - 10, block - 0, slot - 0)
Information on the OTHER waiting sessions:
Session 51:
  pid=99 serial=9999 audsid=9999 user: 99/USER
  O/S info: user: user, term: , ospid: 999999, machine: hostname
            program: blabla@hostname (TNS V1-V3)
  application name: blabla@hostname (TNS V1-V3), hash value=0
  Current SQL Statement:
 
insert into TABLEY(a,b,c) values (a1,b1,c1)
End of information on OTHER waiting sessions.

Code:

1
2
3
4
5
select dbms_rowid.rowid_object('XXpoxeXXXAAAAAAAA') from dual;
                                     999
 
select object_name from all_objects where object_id = 999;
TABLEX

J'ai anonymisé les données mais grossomodo c'est ça.

Merci pour le coup de pouce :)

15/12/2014, 14h56
mnitu

TableX et TableY sont dans un même cluster ?
15/12/2014, 15h12
skyarnangel

Je suis pas sure de la définition de cluster...

J'ai pu comprendre qu'il s'agit d'une information sur la répartitions des informations, les tables sont sur le même tablespace, probalement dans des datafiles différents mais sur la même machine, il ne sont pas spécialement "rangé".

Citation:

Envoyé par skyarnangel

Bonjour,

Voici ce que vous m'avez demandé :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
DEADLOCK DETECTED
Current SQL statement for this session:
insert into TABLEY(a,b,c) values (a1,b1,c1)
The following deadlock is not an ORACLE error. It is a
deadlock due to user error in the design of an application
or from issuing incorrect ad-hoc SQL. The following
information may aid in determining the deadlock:
Deadlock graph:
                       ---------Blocker(s)--------  ---------Waiter(s)---------
Resource Name          process session holds waits  process session holds waits
TX-AAA                   33      53     X             37      51           S
TX-AAA                   37      51     X             33      53           S

session 53: DID 0001-0021-000000C1	session 51: DID 0001-0025-00000060
session 51: DID 0001-0025-00000060	session 53: DID 0001-0021-000000C1

Rows waited on:
Session 51: obj - rowid = 99X99X9X - XXpoxeXXXAAAAAAAA
  (dictionary objn - 999, file - 10, block - 0, slot - 0)
Session 53: obj - rowid = 99X99X9X - XXpoxeXXXAAAAAAAA
  (dictionary objn - 999, file - 10, block - 0, slot - 0)
Information on the OTHER waiting sessions:
Session 51:
  pid=99 serial=9999 audsid=9999 user: 99/USER
  O/S info: user: user, term: , ospid: 999999, machine: hostname
            program: blabla@hostname (TNS V1-V3)
  application name: blabla@hostname (TNS V1-V3), hash value=0
  Current SQL Statement:
  
insert into TABLEY(a,b,c) values (a1,b1,c1)
End of information on OTHER waiting sessions.

Selon Jonathan Lewis la présence de slot -0 est une indication (possible pas tout le temps vraie) que le rowid en question n'a rien à voir les objets impliqués dans le deadlock. Ce n'est en réalité que ce qu'il y avait dans v$session.row_wait_obj# avant que le deadlock n'ait lieu

http://jonathanlewis.wordpress.com/2.../13/deadlocks/

15/12/2014, 19h47
pachot

Bonjour,
L'information du rowid n'est pas toujours fiable.
La requête en attend, elle, l'est: c'est bien l'insert qui est en attente. Est-ce qu'il n'y aurait pas 2 insert qui essaieraient d'insérer la même valeur de clé?
Cordialement,
Franck.
16/12/2014, 09h30
skyarnangel

Bonjour,

Oui, je pense qu'il s'agit bien du problème, la double insertion.
Comme je le dit, mon problème était le rowid remonté qui ne semble n'avoir rien à voir avec le problème.

Mais vous dites que le rowid n'est pas forcément pertinent, ce qui du coup explique mon fichier trace.

Merci pour le coup de main, je vais passer la discussion en résolu.