Lecture d'un deadlock

**skyarnangel** · 15/12/2014, 09h14

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

Merci pour votre aide.

**aieeeuuuuu** · 15/12/2014, 10h18

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...

**skyarnangel** · 15/12/2014, 10h56

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.

**Mohamed.Houri** · 15/12/2014, 11h27

Bonjour,

Envoyé par skyarnangel

Bonjour,

Le deadlock graph est le suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

**skyarnangel** · 15/12/2014, 11h57

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 ?

**Mohamed.Houri** · 15/12/2014, 12h21

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

**skyarnangel** · 15/12/2014, 13h57

Bonjour,

Voici ce que vous m'avez demandé :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

**mnitu** · 15/12/2014, 14h56

TableX et TableY sont dans un même cluster ?

**skyarnangel** · 15/12/2014, 15h12

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é".

**Mohamed.Houri** · 15/12/2014, 15h19

Envoyé par skyarnangel

Bonjour,

Voici ce que vous m'avez demandé :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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/

**pachot** · 15/12/2014, 19h47

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.

**skyarnangel** · 16/12/2014, 09h30

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.

Lecture d'un deadlock [9iR2]

Administration Oracle

Discussions similaires

Partager

Partager