EXPLICACION DEL "ITL ENQUEUE"

Buenos dias amigos.

En la entrega anterior veìamos un singular patron de bloqueo

SID SERIAL# TY OBJECT_NAM HELD REQUEST
----- ------- -- ---------- ---------- --------
36 8428 TX 0 4
36 8428 TM TAB1 3 0
52 29592 TM TAB1 3 0
52 29592 TX (Rollback=RBS1_6) 6 0

Que cuando se presenta podemos asegurar que se trata de un bloqueo ITL, la pregunta del millon ¿como deducimos esto a partir de la salida del script anterior?

- Para garantizar la consistencia de informacion frente a cualquier solicitud de operacion DML oracle inicia un bloqueo contra la tabla (TM) en modo row exclusive (3) para prevenir modificaciones estructurales sobre el segmento en cuestion. Es por ello que vemos que ambas transacciones (36 y 52) que desean modificar datasets sobre la tabla (TAB1) mantienen un bloqueo TM (nivel de tabla) y de tipo row exclusive.

- Una vez que se bloquea el segmento de modo que no se pueda modificar la estructura del mismo, entonces se reserva un slot en el segmento de rollback, identificando asi el segmento de rollback que se encargara de mantener toda la informacion de UNDO necesaria para las lecturas consistentes de la tabla y para recuperar la informacion anterior a el cambio en caso de un posible rollback.

- Una vez que el plan de ejecucion identifica los bloques a ser cambiados por la sentencia DML, entonces la(s) transaccion(es) que desean realizar la operacion DML sobre el dataset reservan slots ITL en la cabecera de los bloques pertenecientes a dicho dataset, si encuentran ITL's libres, entonces la transaccion marca al ITL con un puntero hacia el segmento de rollback usado para reversar la transaccion, segmento de rollback que reservamos en el paso anterior, es por ello que vemos una reserva de tipo TX (fila) de modo 6 (EXCLUSIVE) en el segmento 6 de rollback (ese segmento es el que servira para almacenar la informacion de UNDO de la transaccion en cuestion).

- Posteriormente con los bloques identificados y el (los) ITL reservado(s) entonces se proceden a marcar los row directories de las cabeceras de bloques colocando el LOCK BYTE de modo que apunte a el ITL correspondiente a la transaccion que tomo el bloqueo.

- La transaccion que no encuentra ITL libre ya sea por falta de espacion en el BLOQUE o por un valor demasiado bajo en MAXTRANS, entonces queda imposibilitado de marcar los row directories para que apunten a el ITL (que no pudieron reservar), entonces quedaran en standby solicitando un bloqueo a nivel de fila (TX) de modo 4 (share), , hasta que se libere un slot ITL para que dicho bloqueo entre en accion y se pueda proceder con el proceso de bloqueo normalmente, es por ello que vemos la una transaccion de la sesion con el sid 36 esperando por ese tipo de bloqueo en la salida del query anterior.

Espero que la explicacion sirva para que cuando corramos el script del post anterior y observemos una salida con el patron anteriormente expuesto sepamos el por que ese patron hace referencia a un bloqueo de encolamiento ITL


Ha sido un gusto compartir este razonamiento con ustedes, nos vemos en la proxima entrega.