Siguiendo con el post anterior creo necesario comentar que existen otros tipos de bloqueo que se producen por un diseño conflictivo que se une a las peculiaridades de oracle.
Dejo primero la traza de ejemplo:
*** ACTION NAME:() 2011-04-21 14:08:01.227
*** MODULE NAME:(MiPrograma.exe) 2011-04-21 14:08:01.227
*** SERVICE NAME:(SYS$USERS) 2011-04-21 14:08:01.227
*** CLIENT ID:() 2011-04-21 14:08:01.227
*** SESSION ID:(1636.58026) 2011-04-21 14:08:01.227
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
TM-0001f1b8-00000000 99 1636 SX SSX 92 1461 SX SSX
TM-0001f1b8-00000000 92 1461 SX SSX 99 1636 SX SSX
session 1636: DID 0001-0063-0003159E session 1461: DID 0001-005C-000375B1
session 1461: DID 0001-005C-000375B1 session 1636: DID 0001-0063-0003159E
Rows waited on:
Session 1461: no row
Session 1636: no row
Aquí lo que primero nos llama la atención es que ya tenemos registros bloqueados como se ve abajo. Además el tipo de bloqueo es distinto (antes X o modo exclusivo, ahora SX o exclusivo compartido?). En la documentación podemos ver más de los tipos.
Aquí el tema está en que deadlocks con bloqueo tipo SX se producen al manipular tablas con claves foraneas donde el campo no está indexado (en la fk, no la pk de la tabla primaria) y estamos intendo hacer update/delete sobre la tabla principal. Por decirlo de alguna manera oracle necesita mantener la integridad referencial y consulta la hija para que se siga cumpliendo.
Solución en este caso? Crear siempre la clave primaria en la tabla principal, un indice y una foregin key en la tabla secundaria. Nada más...
