{"id":1430,"date":"2016-05-30T21:57:54","date_gmt":"2016-05-30T19:57:54","guid":{"rendered":"https:\/\/clemente.pamplona.name\/dba\/?p=1430"},"modified":"2016-05-31T13:47:57","modified_gmt":"2016-05-31T11:47:57","slug":"estudio-de-traza-de-un-deadlock","status":"publish","type":"post","link":"http:\/\/clemente.pamplona.name\/dba\/estudio-de-traza-de-un-deadlock\/","title":{"rendered":"Estudio de traza de un Deadlock"},"content":{"rendered":"

Hoy vamos a ver como obtener algo mas de informaci\u00f3n de una incidencia que probablemente tengamos a menudo.<\/p>\n

Los deadlocks no implican mal funcionamiento de la base de datos <\/h1>\n

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\u00f3n posiblemente sea interbloqueo) es una situaci\u00f3n en la que dos o mas usuarios est\u00e1n esperando cada uno a un recurso bloqueado por el otro.
\nLa manera en la que Oracle soluciona esta situaci\u00f3n es rolling back<\/i> una de las sentencias implicadas en el deadlock, al liberar uno de estos bloqueos la otra finaliza su solicitud.
\nCuando esta situaci\u00f3n ocurre, Oracle deja un fichero de traza en el $DIAG_DEST , que nos indica cuales eran los procesos y sentencias implicados. El an\u00e1lisis de esa traza es lo que vamos a mirar hoy.<\/p>\n

Deadlock Graph <\/h1>\n

Seguramente el apartado mas importante de la traza sea el llamado \u00abdeadlock graph\u00bb, estas dos l\u00edneas que parecen tan cr\u00edpticas son las que mas informaci\u00f3n nos van a dar sobre el bloqueo.<\/p>\n

\r\nDeadlock graph:\r\n--------Blocker(s)------- --------Waiter(s)--------\r\nResource Name           process session_holds waits process session_holds waits\r\nTX-000e001a-002dd880     65               414    X       24          9       X\r\nTX-00090006-01e831ca     24                 9    X        65        414      X\r\n<\/pre>\n
Viendo el tipo de bloqueo en \u00abresource_name\u00bb 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)<\/b>.
\nEn nuestro caso, por ejemplo,tendr\u00edamos seg\u00fan soporte un claro caso de bloqueo de aplicaci\u00f3n.
\n\"Bloqueo<\/a><\/p>\n
 Informaci\u00f3n de la sesi\u00f3n <\/h2>\n
Otro apartado interesante es el de la informaci\u00f3n de la sesi\u00f3n. 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 .
\nMediante esta informaci\u00f3n podemos buscar los objetos por los que se han causado el interbloqueo<\/p>\n
\r\nsession 414: DID 0001-0041-000592FB session 9: DID 0001-0018-00004FD9 \r\nsession 9: DID 0001-0018-00004FD9 session 414: DID 0001-0041-000592FB\r\nRows waited on:\r\nSession 414: obj - rowid = 001272E0 - AAExowAQAAAACF5AAUv (dictionary objn - 1209056, file - 1024, block - 8569, slot - 20)\r\nSession 9:   obj - rowid = 001272E0 - AAExowAQAAAACMNAAJ  (dictionary objn - 1209056, file - 1024, block - 8973, slot - 9)\r\n<\/pre>\n
 SQL implicado <\/h2>\n
Finalmente llegamos al apartado que puede ser mas clarificador de cara al equipo de desarrollo encargado de depurar el c\u00f3digo.
\nEste tercer bloque nos amplia la informaci\u00f3n de las sesiones implicadas, cont\u00e1ndonos esquema, terminal y las consultas implicadas en el deadlock <\/p>\n
\r\n----- Information for the OTHER waiting sessions -----\r\nSession 9:\r\nsid: 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)\r\n\r\nclient details:\r\nO\/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\r\n\r\ncurrent SQL:\r\nUPDATE SCOTT2.TIPO_COCHE  SET COLOR = :1, CILINDRADA = :2 WHERE MATRICULA = :3 AND ANCHO = :4\r\n----- End of information for the OTHER waiting sessions -----\r\n\r\nInformation for THIS session:\r\n----- Current SQL Statement for this session (sql_id=8zqxt1a6d7ts1) -----\r\nUPDATE SCOTT2.TIPO_COCHE SET TIPO = :1, PERSONA = :2 WHERE MATRICULA = :3 AND LARGO = :4\r\n<\/pre>\n
El fichero de traza es mucho mas amplio, pero, como hab\u00e9is podido ver, mediante el estudio de la cabecera de la traza podemos recopilar mucha informaci\u00f3n para poder depurara el c\u00f3digo de aplicaci\u00f3n para que no vuelva a ocurrir<\/p>\n
Como siempre, tenemos mas informaci\u00f3n en soporte, en las notas<\/p>\n