Si pudiera actualizar su pregunta con el gráfico de punto muerto, sería información útil. (Cuando su aplicación encuentra un interbloqueo, Oracle generará un ORA-00060 y se escribirá un archivo de rastreo en user_dump_dest). Si busca en el archivo de rastreo, encontrará una sección llamada "Gráfico de interbloqueo". Si puede publicar eso, y también publicar la declaración que causó el interbloqueo y otras declaraciones involucradas en el interbloqueo, entonces podemos comenzar a sacar algunas conclusiones. (Toda la información que solicité está disponible en el archivo de rastreo).
Como mencionó Alessandro, es posible que las sesiones bloqueen diferentes filas en la misma tabla y se bloqueen debido a claves externas no indexadas en la tabla secundaria de una relación padre/hijo. Además, es posible que pueda tener interbloqueos en dos sesiones que actualizan diferentes filas de la misma tabla, incluso si la tabla no es parte de una relación padre/hijo, si, por ejemplo, la tabla tiene pocas entradas de ITL.
Una vez más, publique la información solicitada anteriormente y estoy seguro de que podemos determinar la causa raíz de su interbloqueo.
Agregando lo siguiente, ahora que se ha proporcionado el archivo de rastreo de interbloqueo:Bueno, en primer lugar, según el contenido del archivo de rastreo, este es un simple interbloqueo debido a que las sesiones se superponen/colisionan en las filas que intentan bloquear. A pesar de sus comentarios anteriores sobre el interbloqueo en diferente filas, estoy aquí para decirles que este interbloqueo en particular se debe a un bloqueo a nivel de fila en el mismo filas.
El hecho de que el gráfico de interbloqueo muestre el modo en que se mantiene el bloqueo es 'X' (exclusivo) y el modo en el que se espera el bloqueo es 'X', me dice que se trata de un bloqueo simple a nivel de fila.
En este caso, SID 20 está ejecutando "eliminar de RPT_TABLE.TEMP_TABLE_T1 donde TEMP_T1_ID=:1" y ya tiene un bloqueo en rowid AAAPDIAAMAAAEfIAAA.
Mientras tanto, SID 790 está ejecutando "RPT_TABLE.T1_UPDATE_StoredProc", mientras mantiene un bloqueo en el ID de fila AAAPDIAAMAAAEfGAAA.
Observe en la sección "Filas en espera" del archivo de seguimiento, que el SID 20 está esperando en la fila que contiene el SID 790 y el SID 790 está esperando en la fila que contiene el SID 20. Este es un punto muerto clásico.
Alguna información adicional:
-
El tipo de puesta en cola es TX (consulte el gráfico de punto muerto), por lo que definitivamente no bloqueo debido a claves foráneas no indexadas. Si se bloqueara debido a FK no indexados, el tipo de puesta en cola sería TM, no TX. (Hay al menos otro caso en el que están involucradas las puestas en cola de TM, y no se trata de FK sin indexar. Por lo tanto, no suponga que la puesta en cola de TM siempre significa FK sin indexar).
-
El modo en el que se espera el bloqueo es 'X' (exclusivo), por lo que se trata de un bloqueo a nivel de fila. Si el modo esperado fuera 'S' (compartido), entonces no ser bloqueo de nivel de fila. Más bien, podría ser escasez de ITL o PK o aplicación en el Reino Unido.
¡Espero que eso ayude!
