De vez en cuando puede pasar que dos sesiones que se pisen se bloqueen al intentar hacer cambios en los mismos datos (a nivel de registro o a nivel de tabla). En sistemas no concurrentes y/o bien diseñados no tiene por que pasar ya que las aplicaciones suelen estar mínimamente pensadas para evitarlo; o en todo caso en pruebas pre-producción ya se detecta y se corrige. El caso es que incluso aunque se planee evitarlos se pueden producir. En la mayoría de casos se resuelven solitos al acabar de realizar los cambios la sesión bloqueante, incluso ni nos daremos cuenta. En otros casos más infrecuentes se producen bloqueos circulares irresolubles, “deadlocks”, donde se acaba haciendo rollback de una transacción y se genera una entrada en el fichero de alerta:
ORA-00060: Deadlock detected. More info in file /opt/oracle/admin/XXX/udump/XXX_ora_28205.trc
Si consultamos el fichero de traza encontraremos información más detallada: sesiones involucradas, objeto, registro, consulta que lo provoca, etc... Aquí incluyo algunas partes de un fichero de ejemplo. En la primera parte del fichero vemos que sesión sufrirá el rollback(marcada en negrita) y más abajo vemos el bloqueo circular (donde la 1706 espera a la 1693 y viceversa):
...
*** ACTION NAME:() 2011-01-27 08:07:36.110
*** MODULE NAME:(Servicio.exe) 2011-01-27 08:07:36.110
*** SERVICE NAME:(SYS$USERS) 2011-01-27 08:07:36.110
*** SESSION ID:(1693.30703) 2011-01-27 08:07:36.110
DEADLOCK DETECTED ( ORA-00060 )
[Transaction Deadlock]
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-00090022-00173f07 82 1693 X 21 1706 X
TX-00030014-0013a2dd 21 1706 X 82 1693 X
Rows waited on:
Session 1706: obj - rowid = 0000CF1C - AAAM8cAA5AAACX+AAF
(dictionary objn - 53020, file - 57, block - 9726, slot - 5)
Session 1693: obj - rowid = 0000CF1C - AAAM8cAA5AAACX+AAI
(dictionary objn - 53020, file - 57, block - 9726, slot - 8)
…Con esta información también podemos saber exactamente que objetos y registro/s es el origen de la disputa. Si es algo que se repite de forma cíclica podemos ayudar al responsable de la aplicación dandole más datos (además de las consultas) para que lo resuelva. Para saber que registro de que tabla:
- Convertimos a decimal el obj que se indica al final en hex (0000CF1C->53020)
- Obtenemos el nombre del objeto del diccionario de datos:
SELECT owner, object_name, object_type FROM dba_objects WHERE object_id = 53020; - Consultamos la tabla obtenida buscando el registro por el rowid:
SELECT * FROM tabla WHERE rowid=’AAAM8cAA5AAACX+AAF’’
Un poco más abajo del fichero también se puede ver que consultas han provocado el deadlock y otra información como la cantidad de “waits” de la session en cuestión etc...
Todo esto me hace gracia comentarlo porque a veces desarrolladores mal acostumbrados nos piden que comprobemos si existen bloqueos entre usuarios porque tienen algo que no va tan rápido como siempre. En contraposición también tenemos a usuarios muy impacientes, que cierran a saco sus aplicaciones... Si a ti te pillan en horario, te vienen a preguntar, lo miras sin renegar, miras si existe y si la sessión bloqueante sigue trabajando... Si es el caso y hay que esperar, ¿que le dices? La primera vez le explicas de que va el tema, la segunda vez se lo recuerdas y la tercera que se vaya a tomar un café...
