Hoy vamos a ver como obtener algo mas de información de una incidencia que probablemente tengamos a menudo.
Los deadlocks no implican mal funcionamiento de la base de datos
Lo primero que tenemos que tener muy claro es que un deadlock no es un mal funcionamiento de la base de datos, un deadlock (la traducción posiblemente sea interbloqueo) es una situación en la que dos o mas usuarios están esperando cada uno a un recurso bloqueado por el otro.
La manera en la que Oracle soluciona esta situación es rolling back una de las sentencias implicadas en el deadlock, al liberar uno de estos bloqueos la otra finaliza su solicitud.
Cuando esta situación ocurre, Oracle deja un fichero de traza en el $DIAG_DEST , que nos indica cuales eran los procesos y sentencias implicados. El análisis de esa traza es lo que vamos a mirar hoy.
Deadlock Graph
Seguramente el apartado mas importante de la traza sea el llamado «deadlock graph», estas dos líneas que parecen tan crípticas son las que mas información nos van a dar sobre el bloqueo.
Deadlock graph:
--------Blocker(s)------- --------Waiter(s)--------
Resource Name process session_holds waits process session_holds waits
TX-000e001a-002dd880 65 414 X 24 9 X
TX-00090006-01e831ca 24 9 X 65 414 X
Viendo el tipo de bloqueo en «resource_name» y los distintos waits podremos obtener el tipo de bloqueo que ha sido, para ello tenemos una tabla maestra en la nota de soporte How to Identify ORA-00060 Deadlock Types Using Deadlock Graphs in Trace (Doc ID 1507093.1).
En nuestro caso, por ejemplo,tendríamos según soporte un claro caso de bloqueo de aplicación.
Información de la sesión
Otro apartado interesante es el de la información de la sesión. En este apartado nos indica de manera mas sencilla cuales son las sesiones implicadas y cuales son los objectos en los que hemos tenido el problema .
Mediante esta información podemos buscar los objetos por los que se han causado el interbloqueo
session 414: DID 0001-0041-000592FB session 9: DID 0001-0018-00004FD9
session 9: DID 0001-0018-00004FD9 session 414: DID 0001-0041-000592FB
Rows waited on:
Session 414: obj - rowid = 001272E0 - AAExowAQAAAACF5AAUv (dictionary objn - 1209056, file - 1024, block - 8569, slot - 20)
Session 9: obj - rowid = 001272E0 - AAExowAQAAAACMNAAJ (dictionary objn - 1209056, file - 1024, block - 8973, slot - 9)
SQL implicado
Finalmente llegamos al apartado que puede ser mas clarificador de cara al equipo de desarrollo encargado de depurar el código.
Este tercer bloque nos amplia la información de las sesiones implicadas, contándonos esquema, terminal y las consultas implicadas en el deadlock
----- Information for the OTHER waiting sessions -----
Session 9:
sid: 9 ser: 37801 audsid: 206118217 user: 103/SCHEMA1 flags: (0x45) USR/- flags_idl: (0x1) BSY/////- flags2: (0x40009) //INC pid: 24 O/S info: user: SYSTEM, term: SERVERTEST, ospid: 12260 image: ORACLE.EXE (SHAD)
client details:
O/S info: user: launcherusr, term: , ospid: 13041768 machine: client2 program: schema2@client2 (TNS V1-V3) application name: schema2@client2 (TNS V1-V3), hash alue=54028978
current SQL:
UPDATE SCOTT2.TIPO_COCHE SET COLOR = :1, CILINDRADA = :2 WHERE MATRICULA = :3 AND ANCHO = :4
----- End of information for the OTHER waiting sessions -----
Information for THIS session:
----- Current SQL Statement for this session (sql_id=8zqxt1a6d7ts1) -----
UPDATE SCOTT2.TIPO_COCHE SET TIPO = :1, PERSONA = :2 WHERE MATRICULA = :3 AND LARGO = :4
El fichero de traza es mucho mas amplio, pero, como habéis podido ver, mediante el estudio de la cabecera de la traza podemos recopilar mucha información para poder depurara el código de aplicación para que no vuelva a ocurrir
Como siempre, tenemos mas información en soporte, en las notas
- Master Note for Database Error ORA-00060 «deadlock detected while waiting for resource» (Doc ID 1509919.1)
- Master Note: Locks, Enqueues and Deadlocks (Doc ID 1392319.1)
- How to Identify ORA-00060 Deadlock Types Using Deadlock Graphs in Trace (Doc ID 1507093.1)
