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.

Query para verificar que un evento "enqueue" hace referencia un enqueue ITL

Buenos dias amigos,

Lo prometido es deuda, aqui tienen el query (extraido de la pagina: http://www.rampant-books.com/art_nanda_interested_tarnsaction_list_itl.htm) que ofreci en la entrega anterior, sirve para verificar si es que un evento "enqueue" es producido por una contencion en ITL

Select s.sid SID,
s.serial# Serial#,
l.type type,
' ' object_name,
lmode held,
request request
from v$lock l, v$session s, v$process p
where s.sid = l.sid and
s.username <> ' ' and
s.paddr = p.addr and
l.type <> 'TM' and
(l.type <> 'TX' or l.type = 'TX' and l.lmode <> 6)
union
select s.sid SID,
s.serial# Serial#,
l.type type,
object_name object_name,
lmode held,
request request
from v$lock l, v$session s, v$process p, sys.dba_objects o
where s.sid = l.sid and
o.object_id = l.id1 and
l.type = 'TM' and
s.username <> ' ' and
s.paddr = p.addr
union
select s.sid SID,
s.serial# Serial#,
l.type type,
'(Rollback='||rtrim(r.name)||')' object_name,
lmode held,
request request
from v$lock l, v$session s, v$process p, v$rollname r
where s.sid = l.sid and
l.type = 'TX' and
l.lmode = 6 and
trunc(l.id1/65536) = r.usn and
s.username <> ' ' and
s.paddr = p.addr
order by 5, 6
/

Salida de ejemplo del query anterior

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


Note como la sesion 36 y 52 tienen un bloqueo de tipo 3 (transaction exclusive) TM (nivel de tabla) en TAB1, pero las sesion 52 tambien mantiene un bloqueo de tipo 6 (exclusive) TX (nivel de transaccion fila) en el segmento de rollback y la sesion y la sesion 36 esta esperando (HELD=0) por un bloqueo TX (nivel de fila) de nivel 4 (share).

Cuando tenemos esta particular combinacion de bloqueos podemos estar seguros que la sesion 36 esta esperando debido a un bloqueo de tipo ITL.

Vamos a deducir este singular patròn de bloqueos en la siguiente entrega cuando hablemos de BLOCK CLEANOUT.

Hasta pronto ....

Cambiar el poder de balanceo de una instancia ASM

Buenos dias amigos,


Esta vez vamos a aprender a cambiar el poder de balanceo de una instancia ASM. Como todos sabemos ASM es una tecnología relativamente nueva de almacenamiento físico que Oracle pone a nuestra disposicion para colocar ahi nuestros archivos de base de datos, este nuevo sistema de manejo de nuestro almacenamiento de datos trae consigo la ventaja de performance de un RAW DEVICE, mas las características de concurrencia de un CFS (Cluster Filesystem) y mas las ventajas de manejo de un filesystem comun de S/O.

Si es que nosotros agregamos o quitamos un disco a un diskgroup asm (un conjunto de discos ASM forman lo que se conoce como DISKGROUP, cuyo tamaño es logicamente la sumatoria de todos sus ASM DISKS), Oracle tiene que realizar un proceso de re-balanceo que no es mas que redistribuir la carga de informacion entre el resto de discos que conforman ese diskgroup, dicho proceso se lo puede ver haciendo un query a la vista v$asm_operation, ahora, debido a que es una operacion que demanda gran cantidad de I/O a nivel de disco, es recomendable que cuando realizemos este tipo de operaciones, durante el tiempo ocioso de nuestra instancia (por lo general noches o madrugadas) cambiemos el nivel de poder de rebalancing de el proceso, para ello debemos usar la sentencia: ALTER DISKGROUP nombre_del_diskgroup REBALANCE POWER XX; siendo XX el nivel de poder de rebalanceo que puede fluctuar entre 1 y 11 siendo 1 el valor por default y tambien el nivel mas lento de rebalanceo que existe (11 lógicamente es el mas veloz pero el que mas carga consume por lo tanto no debemos colocarlo durante horas en las que la B.D. de produccion este en pleno uso).