Interested Transaction List (ITL)

Como todos conocemos, todo motor de base de datos debe mantener algun mecanismo de bloqueo para evitar la concurrencia de mas de una transaccion a la vez sobre el mismo dataset, por ello, la primera transaccion que necesite trabajar sobre un dataset, debe bloquearla para que dicho dataset no sea modificado hasta que la transaccion que mantiene el bloqueo termine ya sea confirmando (commit) o anulando (rollback) la transaccion.

El nivel de granularidad con el que se bloquea un dataset depende de cada RDBMS, el sistema de bloqueo de el RDBMS de ORACLE es a nivel de fila, lo que quiere decir que la unidad mas pequeña con la que oracle puede bloquear un dataset es UNA FILA (un registro).

De la misma manera el mètodo que utilizan los diferentes motores de base de datos para registrar el bloqueo difiere unas de otras, por ejemplo existen RDBMS's que mantienen un manejador de bloqueo que es la estructura de informacion que registra, mantiene y controla todos los bloqueos que se dan dentro de la base de datos. Esto sin embargo resulta en un PUNTO DE BLOQUEO adicional debido a que en bases de datos con demasiada transaccionalidad el mismo Manejador de Bloqueo se convierte en el cuello de botella ya que al momento en el que alguna transaccion pide bloquar, liberar o consultar el bloqueo sobre un determinado dataset, lo debe hacer a travez de el manejador de bloqueo, serializando de este modo la concurrencia paralela de varias llamadas que se realizan al mismo tiempo sobre este manejador transaccional. Es por ello que Oracle mantiene el control de sus transacciones en los mismos bloques de datos en lugar de encargarlo a un ente que serialize el manejo de transacciones.

La estructura mediante la cual Oracle controla o registra los bloqueos de registros se encuentra en la cabecera de los bloques de datos y se la conoce como ITL (Interester Transaction List), cada nodo de esta lista enlazada se la conoce como slot y c/u contiene el ROWID y la TRANSACTION ADDRESS que esta solicitando el bloqueo, cuando la misma u otra transaccion quiere bloquear otra fila, entonces la ROWID de esa fila y la TRANSACTION ADDRESS de la transaccion interesada en el bloqueo (por ello el nombre de INTERESTED Transaction List) y asi sucesivamente. El nùmero de slots disponibles para que las transacciones registren su "interes" por un registro especifico de la tabla esta dado por los parametros INITTRANS y MAXTRANS. El parametro INITTRANS define cuantos SLOTS ITL se crearan conjuntamente con la creacion del segmento; una vez que la transaccion termina, el bloqueo de el registro es liberado y por ende tambien se libera el SLOT ocupado para registrar esa transaccion, para que otra transaccion lo ocupe posteriormente. Si es que en un momento dado todos los SLOTS definidos por INITTRANS estan llenos, nuevos SLOTS son añadidos conforme las transacciones los soliciten, hasta alcanzar el maximo numero de SLOTS dado por el parametro MAXTRANS.

Cabe señalar que si bien el parametro MAXTRANS define el maximo numero de slots disponibles, si es que el bloque de datos no tiene espacio para crear un nuevo SLOT, pece a que aun no se llegue aun al numero de transacciones dado por MAXTRANS, el SLOT NO PODRA SER CREADO hasta que se libere espacio en el bloque de datos, para evitar este efecto en tabas que tienen un nivel alto de transaccionalidad, podemos jugar con el parametro PCTFREE y PCTUSED para mantener siempre el espacio suficiente en nuestro bloque de datos para que el numero de slots dado por MAXTRANS siempre pueda ser alcanzado.

En el supuesto caso de que el bloque este lleno o que ya se ha alcanzado el numero de slots dado por MAXTRANS y todos esten ocupados por transacciones, entonces la transaccion que pide el boqueo se colocara en un estado de espera en el evento ITL WAIT mismo que se lo puede observar en vistas tales como v$session_wait con el nombre de "enqueue"

Sin embargo, el evento "enqueue" es un evento que abarca una gama muy grande de tipos de encolamiento (el encolamiento ITL es uno de los tantos que esta dentro de esa gama). En una proxima entrega les prometo colocar el SQL con el cual podemos confirmar si es que el encolamiento es efectivamente dado por ITL.

En proximas entregas veremos el SQL ofrecido y el proceso de limpieza de bloqueo que utiliza Oracle para encerar los registros ITL una vez que la transaccion finalize.

Hasta la proxima amigos.