Introduction Comment survient un Deadlock? Comment ... - Trivadis

Objet Deadlock - Une expérience désagréable
Auteur Peter Jensch (peter.jensch@trivadis.com)
Nature des informations Informations à caractère technique
Source Notre expérience de formation et de conseil
Introduction
L'apparition de Deadlocks dans les applications de base de données Oracle est toujours
une expérience désagréable. Même occasionnel, un Deadlock (interblocage) empêche
toute utilisation pertinente de l'application en cours! L'acceptation de l'application est alors
refusée, d'autant que les Deadlocks révèlent généralement un problème issu de
l'application. Il est donc essentiel pour les développeurs d'applications et les DBA de
savoir éviter les Deadlocks ou de savoir les dénicher et les interpréter correctement.
Sont particulièrement sensibles aux Deadlocks toutes les tables contenant des Locks
explicites assurant la cohérence écriture/lecture, toutes les contraintes FK non indexées
(n'existent plus dans la version 9i d'Oracle) et tous les paramètres de stockage des
segments de données dont la valeur est insuffisante (en l'occurrence, les paramètres
INITTRANS, MAXTRANS et PCTFREE). Ces éléments peuvent être à l'origine de blocages et
d'interblocages intempestifs. Les causes sont multiples et doivent être recherchées au cas
par cas.
Comment survient un Deadlock?
Lorsque deux utilisateurs (ou plus) tentent d'accéder aux mêmes sources de données dans
un ordre différent, il se produit un blocage ou un interblocage des ressources qui peut se
manifester au niveau des tables, des partitions ou des enregistrements.
La liste des blocages possibles est très longue. Je me limiterai donc à la présentation des
blocages principaux.
DX Distributed TX
TM DML-Enqueue
TX Transaction
UL User-defined Locks
...
Comment une base de données consigne-t-elle un Deadlock?
Lorsqu'un Deadlock se produit (message d'erreur Oracle: ora-00060), un message s'inscrit
dans le journal d'alerte et un fichier de trace est créé dans le dossier

USER_DUMP_DESTINATION. L'entrée inscrite dans le journal d'alerte fournit le nom du
fichier de trace créé.
Analyser le journal d'alerte et le fichier de trace est une opération fastidieuse et exigeante.
Trouver la solution au problème relève alors du miracle. Sous certaines conditions, il est
pourtant possible de trouver une réponse rapide et détaillée.
Exemple tiré d'un fichier alert_log:
Mon Jul 29 09:14:42 2002
ORA-000060: Deadlock detected. More info in file
d:\oracle\admin\DB1\udump\ORA01784.TRC.
Exemple (extrait) tiré du fichier de trace correspondant ORA01784.TRC:
Dump file d:\oracle\admin\DB1\udump\ORA01784.TRC
Mon Jul 29 09:14:42 2002
ORACLE V9.0.1.2.1 - Production vsnsta=0
vsnsql=10 vsnxtr=3
Windows 2000 Version 5.0 Service Pack 2, CPU type 586
Oracle9i Enterprise Edition Release 9.0.1.2.1 - Production
With the Partitioning option
JServer Release 9.0.1.2.0 - Production
Windows 2000 Version 5.0 Service Pack 2, CPU type 586
Instance name: db1
Redo thread mounted by this instance: 1
Oracle process number: 12
Windows thread id: 1784, image: ORACLE.EXE
*** 2002-07-29 09:14:42.000
*** SESSION ID:(12.11) 2002-07-29 09:14:42.000
DEADLOCK DETECTED
Current SQL statement for this session:
update emp set sal = sal + 100
where deptno = 20
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-00080006-000008f8 12 12 X 11 10 X
TX-00090002-000008fc 11 10 X 12 12 X
session 12: DID 0001-000C-00000002 session 10: DID 0001-000B-00000002
session 10: DID 0001-000B-00000002 session 12: DID 0001-000C-00000002
Rows waited on:
Session 10: obj - rowid = 00007C6A - AAAHxqAABAAAO/CAAG
(dictionary objn - 31850, file - 1, block - 61378, slot - 6)
Session 12: obj - rowid = 00007C6A - AAAHxqAABAAAO/CAAA
(dictionary objn - 31850, file - 1, block - 61378, slot - 0)
SQL statements executed by the waiting sessions:
Session 10:
update emp set sal = sal + 100
where deptno = 10
===================================================
PROCESS STATE
-------------
Process global information:

process: 671C58C8, call: 67247E80, xact: 6689333C, curses: 671EC654, usrses:
671EC654
----------------------------------------
SO: 671C58C8, type: 2, owner: 00000000, flag: INIT/-/-/0x00
(process) Oracle pid=12, calls cur/top: 67247E80/67247E80, flag: (0) -
int error: 0, call error: 0, sess error: 0, txn error 0
(post info) last post received: 120 0 4
last post received-location: kslpsr
last process to post me: 671c3e28 1 6
last post sent: 0 0 15
last post sent-location: ksasnd
last process posted by me: 671c3e28 1 6
(latch info) wait_event=0 bits=10
holding 19792c0 Parent+children enqueue hash chains level=4
Location from where latch is held: ksqcmi: kslgpl:
Si ces informations ne suffisent pas, il est possible de générer des informations
complémentaires par l'intermédiaire des événements de base de données en ajoutant le
paramètre Init.ora suivant:
Event=“60 trace name errorstack level 3;name systemstate level 10“
Ce paramètre peut, le cas échéant, produire de très gros fichiers de trace. La taille de ces
fichiers est définie par le paramètre Init.ora nommé max_dump_file_size. Les entrées
inscrites au-delà de cette limite sont tout simplement sectionnées: l'interprétation du fichier
est alors considérablement plus difficile puisque certaines informations capitales ont été
coupées.
Solution au problème:
Parmi les scripts Trivadis que vous pouvez télécharger gratuitement à l'adresse
www.trivadis.com, vous trouverez deux scripts (sslckwa1.sql et sslckwai.sql) qui, au
moment de leur exécution, éditent toutes les tables actuellement bloquées et fournissent
diverses informations concernant le Locker, le Waiter et l'origine. L'exécution des scripts se
réfère au moment présent, si bien que les Deadlocks en cours ne sont pas consignés.
Heureusement, il existe un trigger et une procédure de base de données capables
d'exécuter l'enregistrement des informations dans les tables Log dès que survient un
Deadlock. Le fonctionnement est le suivant: lorsque survient le message Oracle ORA-
00060, le trigger de base de données est activé et les informations importantes du
Deadlock sont insérées dans deux tables.

Voici les tables requises, le trigger de base de données et la procédure PL/SQL installés
sous User Sys:
Table tvd_lock_info_1
CREATE TABLE tvd_lock_info_1 (
lock_date DATE
, os_locker VARCHAR2(30)
, locker_schema VARCHAR2(30)
, locker_pid VARCHAR2(9)
, os_waiter VARCHAR2(30)
, waiter_schema VARCHAR2(30)
, waiter_pid VARCHAR2(9)
, sql_text_waiter VARCHAR2(200)
);
Table tvd_lock_info_2
CREATE TABLE tvd_lock_info_2 (
lock_date DATE
, wait VARCHAR2(3)
, os_user VARCHAR2(30)
, process VARCHAR2(9)
, locker VARCHAR2(30)
, object_owner VARCHAR2(30)
, object_name VARCHAR2(30)
, program varchar2(50)
)
TABLESPACE users
/
Procédure tvd_prc_lock_info
CREATE OR REPLACE PROCEDURE tvd_prc_lock_info
IS
PRAGMA AUTONOMOUS_TRANSACTION;
BEGIN
INSERT INTO tvd_lock_info_1
( lock_date, os_locker, locker_schema, locker_pid,
os_waiter, waiter_schema, waiter_pid, sql_text_waiter )
SELECT /* first the table-level locks (TM) and mixed TM/TX TX/TM */
SYSDATE
, S_LOCKER.OSUSER OS_LOCKER
, S_LOCKER.USERNAME LOCKER_SCHEMA
, S_LOCKER.PROCESS LOCKER_PID
, S_WAITER.OSUSER OS_WAITER
, S_WAITER.USERNAME WAITER_SCHEMA
, S_WAITER.PROCESS WAITER_PID
, 'Table lock (TM): ' || U.NAME || '.' || O.NAME || ' - Mode held: '||
DECODE(L_LOCKER.LMODE,
0, 'None', /* same as Monitor */
1, 'Null', /* N */
2, 'Row-S (SS)', /* L */
3, 'Row-X (SX)', /* R */
4, 'Share', /* S */
5, 'S/Row-X (SSX)', /* C */
6, 'Exclusive', /* X */
'???: ' || to_char(L_LOCKER.LMODE)) || ' / Mode requested: '||

FROM
DECODE(L_WAITER.REQUEST,
0, 'None', /* same as Monitor */
1, 'Null', /* N */
2, 'Row-S (SS)', /* L */
3, 'Row-X (SX)', /* R */
4, 'Share', /* S */
5, 'S/Row-X (SSX)', /* C */
6, 'Exclusive', /* X */
'???: '||to_char(L_WAITER.REQUEST))
SQL_TEXT_WAITER
OBJ$ O
, USER$ U
, V$LOCK L_WAITER
, V$LOCK L_LOCKER
, V$SESSION S_WAITER
, V$SESSION S_LOCKER
WHERE S_WAITER.SID = L_WAITER.SID
AND L_WAITER.TYPE IN ('TM')
AND S_LOCKER.sid = L_LOCKER.sid
AND L_LOCKER.ID1 = L_WAITER.ID1
AND L_WAITER.REQUEST > 0
AND L_LOCKER.LMODE > 0
AND L_WAITER.ADDR != L_LOCKER.ADDR
AND L_WAITER.ID1 = O.OBJ#
AND U.USER# = O.OWNER#
UNION
SELECT /* now the (usual) row-locks TX */
SYSDATE
, S_LOCKER.OSUSER OS_LOCKER
, S_LOCKER.USERNAME LOCKER_SCHEMA
, S_LOCKER.PROCESS LOCK_PID
, S_WAITER.OSUSER OS_WAITER
, S_WAITER.USERNAME WAITER_SCHEMA
, S_WAITER.PROCESS WAITER_PID
, 'TX: ' || O.SQL_TEXT SQL_TEXT_WAITER
FROM
V$LOCK L_WAITER
, V$LOCK L_LOCKER
, V$SESSION S_WAITER
, V$SESSION S_LOCKER
, V$_LOCK1 L1_WAITER
, V$OPEN_CURSOR O
WHERE S_WAITER.SID = L_WAITER.SID
AND L_WAITER.TYPE IN ('TX')
AND S_LOCKER.sid = L_LOCKER.sid
AND L_LOCKER.ID1 = L_WAITER.ID1
AND L_WAITER.REQUEST > 0
AND L_LOCKER.LMODE > 0
AND L_WAITER.ADDR != L_LOCKER.ADDR
AND L1_WAITER.LADDR = L_WAITER.ADDR
AND L1_WAITER.KADDR = L_WAITER.KADDR
AND L1_WAITER.SADDR = O.SADDR;
INSERT INTO tvd_lock_info_2
( lock_date, wait, os_user, process, locker,
object_owner, object_name, program )
SELECT SYSDATE
, DECODE(L.REQUEST,0,'NO','YES') WAIT
, S.OSUSER
, S.PROCESS
, S.USERNAME LOCKER
, U.NAME T_OWNER
, O.NAME OBJECT_NAME
, ' '||S.PROGRAM PROGRAM
FROM
V$LOCK L
, USER$ U
, OBJ$ O

, V$SESSION S
WHERE U.USER# = O.OWNER#
AND S.SID = L.SID
AND L.ID1 = O.OBJ#
AND L.TYPE = 'TM'
AND U.NAME != 'SYS'
UNION
SELECT SYSDATE
, DECODE(L.REQUEST,0,'NO','YES') WAIT
, S.OSUSER
, S.PROCESS
, S.USERNAME LOCKER
, '-'
, 'Record(s)'
, ' '||S.PROGRAM PROGRAM
FROM V$LOCK L
, V$SESSION S
WHERE S.SID = L.SID
AND L.TYPE = 'TX';
COMMIT;
END;
/
show errors
Trigger log_deadlock_errors
CREATE OR REPLACE TRIGGER log_deadlock_errors
AFTER SERVERERROR
ON DATABASE
BEGIN
IF (IS_SERVERERROR (60)) THEN
sys.tvd_prc_lock_info;
END IF;
END log_deadlock_errors;
/
show errors
Test du nouveau trigger
Il est possible de provoquer un Deadlock à l'aide d'un petit test:
Connectez-vous à une base de données en ouvrant deux sessions SQL-Plus en tant que
l'utilisateur Scott; nous appellerons ces deux sessions Session A et Session B. Pour
provoquer le Deadlock, il faut exécuter un Lock sur une table dans les deux sessions. Si les
deux commandes des deux sessions sont interverties, un Deadlock se produit:
Séquence Session A Session B
1 UPDATE emp SET sal = sal +
100
WHERE deptno = 10;
2 UPDATE emp SET sal = sal + 200
WHERE deptno = 20;
3 UPDATE emp SET sal = sal +
200
WHERE deptno = 20;

4 UPDATE emp SET sal = sal + 100
WHERE deptno = 10;
5 UPDATE emp SET sal = sal +
200
WHERE deptno = 20
*
ERROR at line 1:
ORA-00060: deadlock detected
while waiting for resource
Même après la fermeture des deux sessions Scott, les informations enregistrées peuvent
être analysées à partir des deux tables via User SYS:
SELECT to_char(lock_date,'HH24:MI:SS') lock_date
, locker_schema LCK
, waiter_schema WAI
, sql_text_waiter
FROM tvd_lock_info_1;
LOCK_DAT LCK WAI SQL_TEXT_WAITER
-------- ----------- ----------- ------------------------------------------------------
----------
09:14:42 SCOTT SCOTT TX: SELECT ATTRIBUTE FROM V$CONTEXT WHERE NAMESPACE
= 'LBAC$L
09:14:42 SCOTT SCOTT TX: SELECT MAX(TAG#) FROM LBAC$LAB
09:14:42 SCOTT SCOTT TX: SELECT POL# FROM LBAC$POL ORDER BY POL#
09:14:42 SCOTT SCOTT TX: SELECT POL#,PACKAGE FROM LBAC$POL WHERE
BITAND(FLAGS,1) =
09:14:42 SCOTT SCOTT TX: select pol#, usr_name, usr_labels, package, privs
from lbac$
09:14:42 SCOTT SCOTT TX: table_1_0_139_0_0_0
09:14:42 SCOTT SCOTT TX: update emp set sal = sal + 100 where deptno = 10
L'exécution d'un simple Select dans la table tvd_lock_info_1 permet déjà de savoir QUI a
bloqué QUOI et COMMENT. Un autre Select dans la table tvd_lock_info_2 permet
d'obtenir des informations complémentaires: quels sont les autres sessions, tables et
programmes touchés?
SELECT to_char(lock_date,'HH24:MI:SS') lock_date, wait, os_user, locker,
program, object_owner, object_name
FROM tvd_lock_info_2;
LOCK_DAT WAI OS_USER LOCKER PROGRAM OBJECT_OWNER OBJECT_NAME
-------- --- -------------- ------- ------------ ---------------- --------------
09:14:43 NO TRIVADIS\pej SCOTT sqlplusw.exe - Record(s)
09:14:43 NO TRIVADIS\pej SCOTT sqlplusw.exe SCOTT EMP
09:14:43 NO TRIVADIS\pej SCOTT sqlplusw.exe - Record(s)
09:14:43 NO TRIVADIS\pej SCOTT sqlplusw.exe SCOTT EMP
09:14:43 YES TRIVADIS\pej SCOTT sqlplusw.exe - Record(s)
Sur la page "Tools & Services" de notre site web, vous pouvez télécharger gratuitement un
fichier contenant la table Create, la procédure Create et le trigger de base de données
requis (cslcktrg.sql) ainsi qu'un fichier destiné à la version formatée (lslcksta.sql).

Pour obtenir davantage d'informations sur le comportement transactionnel, les blocages et
les interblocages, n'hésitez pas à consulter d'anciennes éditions du DOAG et à visiter notre
site web.
Bonne chance avec Oracle! En espérant que vous saurez éviter les plantages et les attentes
provoqués par les Deadlocks...
Peter Jensch
Trivadis AG E-mail: peter.jensch@trivadis.com
Peter Jensch Tél.: +49 711 90 36 32 30
Max-Lang-Strasse 56 Fax: +49 711 90 36 32 59
D-70771 Leinfelden-Echterdingen Internet: http://www.trivadis.com