Tipus de bloquejos,
causes principals i
impacte en el rendiment
1 Introducció
El següent document és un estudi superficial dels
bloquejos en una base de dades Oracle i les causes
principals. S'analitzen tots els bloquejos que poden
existir en RDBMS Oracle exceptuant el latches i el
mutexes. Finalment s'inclou un cas d'estudi que
analitza l'estructura i com es relacionen una taula de
transaccions i una ITL.
2 Bloquejos a la shared pool
Les estructures de memòria a la shared pool, com
són la cache de diccionari (row cache) i la cache de
libreria (library cache), estan compostes bàsicament
per diversos latches que protegeixen un cojunt de
hash buckets on estan ubicades les llistes enllaçades.
Per accedir a una d'aquestes llistes existeix un nivell
intermedi abans que els latches i amb els quals
operen. Són una serie de bloquejos que s'han
d'adquirir per poder tenir accés als buckets i a les
llistes.
La seves principals funcions són: preservar la
integritat del diccionari de dades, proporcionar
transaccions amb una vista consistent de la definició
dels objectes i gestiona l'execució de SQL o PL/SQL
compartit. Existeixen tres tipus
• Row cache locks.
• Library cache locks.
• Library cache pins.
2.1 Row cache locks
Els bloquejos del diccionari de dades protegeixen les
definicions dels objectes en el diccionari mentre
estan sent referenciats. Això és necessari per
prevenir que puguin ser eliminats o que canviïn les
seves definicions mentre són utilitzats. Aquests
bloquejos han de ser adquirits durant el temps que la
sentència SQL està sent analitzada (parse) o
executada.
Emmagatzema les files de dades del diccionari i
1
forma part de la shared pool, utilitza els bloquejos
per proporcionar un bloqueig de gra fi, això
significa que cada objecte està protegit per un
bloqueig dedicat. Les files que estan a la memòria
cau actuen com una estructura de recurs per poder
implementar el bloqueig i estan assignades
dinàmicament a la shared pool. Els tipus de
bloqueig són: Q[A] ... Q[Z].
Quan s’intenta obtenir un bloqueig d'aquest tipus,
en mode no-wait, i no està disponible provoca el
següent error :
ORA-00054 resource busy and
acquire with NOWAIT specified
Alternativament la petició pot ser inserida en una
cua i esperar per l'esdeveniment d'espera library
cache lock.
L'esdeveniment d'espera row cache lock indica
esperes tractant d’adquirir un bloqueig de row
cache, té una duració aproximada de tres segons i
la petició de bloqueig és abandonada després de
1000 timeouts. No són molt comuns i són producte
d’algun conflicte amb el recurs. Poden ser adquirits
de les següents maneres:
• Mode 0: no bloquejat.
• Mode 3: compartit.
• Mode 5: exclusiu.
• Mode 10: error en l’adquisició del
bloqueig.
Si no pot ser adquirit la sessió romandrà en espera
tres segons i farà un nou intent. Si després de 1000
intents el bloqueig no està disponible la sessió
avorta i torna el següent missatge al fitxer d’alertes:
Waited too long for row cache
enqueue lock
2.2 Library cache locks
Els bloquejos de la library cache controlen la
concurrència entre clients quan estan adquirint un
bloqueig al gestor d’objectes. Això permet a un
client evitar que altres accedeixin al mateix objecte
o mantenir un dependència durant un llarg temps.
També serveix per localitzar un objecte dins de la
library cache.
Aquest bloquejos són adquirits als gestor d’objectes,
durant les crides d'anàlisis (parse). El mode en que
són adquirits és exclusiu en gestors parents i childs, i
compartit en totes les seves dependències. Aquest
bloquejos son retinguts en NULL per detectar
invalidacions i permeten no haver de localitzar el
gestor un altre cop.
L’estructura de recurs és el gestor d’objectes i és on
s’implementa el bloqueig, les estructures de bloqueig
són assignades dinàmicament des de la shared pool.
Els tipus de bloqueig són: L[A] ... L[P].
L'esdeveniment d'espera library cache lock indica
una espera en adquirir un bloqueig en la library
cache. Les esperes en aquest cas són poc freqüents.
2.3 Library cache pins
Library cache pins administren la coherència en
aquesta memòria cau. Clavar (pinning) un objecte fa
que el heap sigui carregat dins de la memòria. Si
algú vol modificar o examinar l'objecte, primer ha
d'adquirir un pin en el heap apropiat, després un
bloqueig en el gestor associat. Una espera implica
que qualsevol altra sessió sosté el pin d'un mode
incompatible.
S'adquireix de manera compartida per llegir als
heaps i prevenir modificacions als objectes
dependents. De manera exclusiva per modificar els
heaps.
En aquest cas el gestor d'objectes és l'estructura de
recurs que implementa el bloqueig. Els pins són
assignats des de la shared pool. Els tipus de bloqueig
són: N[A] ... N[Z].
L'esdeveniment d'espera library cache lock indica
esperes per adquirir a library cache pin, són poc
comunes.
3 Bloquejos DML
Els bloquejos DML garanteixen la consistència de
les dades durant una transacció. Són necessaris per
dos propòsits fonamentals:
• Els bloquejos de taula garanteixen la
consistència de la definició de l'objecte
durant el temps que duri la transacció.
• Els bloquejos de fila asseguren la
consistència de les dades durant la transacció
sencera.
2
3.1 Bloquejos DML a nivell de
taula
S'implementen com enqueues del tipus TM i de
següent manera: cada cursor manté una llista de
bloquejos de taula, la qual és construïda quan es fa
l'anàlisi (parsing) de la sentència. Abans de la
primera execució del cursor , es crida a una funció
per obtenir tots els bloquejos de la taula i s'alliberen
automàticament quan la transacció finalitza.
3.2 Bloquejos DML a nivell de fila
A part d'assegurar la integritat de la definició de
l'objecte durant la transacció, la consistència de les
dades també ha de ser protegida. Això
s'aconsegueix per mitjà de la implementació de
bloquejos a nivell de fila i de transacció.
Els bloquejos a nivell de fila s'implementen per
mitjà d'un byte de bloqueig a cada capçalera de fila
i a la ITL (interested transaction list) de cada bloc
de dades o índexs. Quan un fila és bloquejada, el
byte de bloqueig apunta cap a l'entrada dins de la
ITL que te informació sobre si el bloqueig està
actiu o no. De qualsevol manera, totes les entrades
ITL d'una transacció apunten a un enqueue TX que
en última instància, determina si una transacció ha
finalitzat o no i per tant si els bloquejos de fila
estan actius o no.
S'implementen com un enqueue TX, els descriptors
ITL implementen els bloquejos de fila.
Row level lock
Al exemple es pot veure:
La transacció 1 (Tx1) vol modificar les files 2 i 3:
• Accedeix al bloc i assigna la entrada ITL1
• Accedeix a les files per el rowid i verifica
que no estan bloquejades per altra
transacció, per tant el camp de bloqueig
(segon byte) de la capçalera de la fila val 0.
 • La transacció 1 bloqueja les 2 files no pot ser reclamat.
modificant el camp de bloqueig amb el valor
La contenció per ITL es manifesta per si mateixa
del corresponent index a la seva ITL, en
com una espera amb un enqueue TX en mode
aquest cas 1.
compartit.
El mateix passa amb la transacció 2 (Tx2), que vol
modificar un fila diferent de les que ha canviat la
Tx1, la fila 1. 3.4 Bloquejos de transacció
(transaction blocks)
És corresponen amb transaccions actives i estan
emmagatzemades a la taula de transaccions de la
capçalera del bloc dels segments de rollback. Els
identificadors de transacció dins de la ITL apunten
cap a la taula de transacció.
Aquest tipus de bloqueig s’implementa con un
enqueue TX.
Els identificadors de transacció (XID) identifiquen
un transacció única dins del sistema. S’utilitzen
dins de la ITL d’un bloc de dades o d'índex i
consisteix en:
Al segon exemple que veurem a continuació, la
transacció 2 (Tx2) vol modificar la fila 2. Al accedir
al la fila en el bloc, la transacció detecta que la fila
està bloquejada per un altre transacció (el camp de
bloqueig no és 0). Es tracta d'un conflicte ?
• Un nombre de segment de rollback/undo
Es fa una neteja (cleanout), eliminant la informació
de la transacció, per veure si la transacció 1 (Tx1) • Un nombre de slot dins de la taula de
ha fet commit. Si després encara està activa hi ha un transaccions
conflicte. La transacció 2 (Tx2) ha d'esperar a que la • Un nom de seqüència denominat wrap#
Transacció 1 (Tx1) alliberi el bloqueig en la fila i
això passarà quan la transacció 1 (Tx1) finalitzi
(commit o rollback) i s'ha realitzat d'una neteja de
blocs (block cleanut)
La transacció Tx2 espera com a resultat de la petició
del enqueue TX que està associat amb la transacció 1
(Tx1) de manera exclusiva. El mateix passa amb la
transacció 3 (Tx3) que vol modificar la fila 3.

3.3 Contenció ITL

Dins de la capçalera del bloc hi ha una taula de
transaccions, cada entrada descriu les files o
elements que tenen les transaccions bloquejades. És
necessari un slot de transacció per qualsevol
modificació al bloc. Quan una sessió vol modificar
un bloc, una entrada a la ITL ha de ser obtinguda.
El nombre inicial d’entrades ITL s’inicialitza amb el
paràmetre INITRANS i pot créixer dinàmicament
fins al màxim marcat pel paràmetre MAXTRANS o
per la quantitat total d'espai lliure en el bloc ja que
cada assignació consumeix uns 24 bytes. És
recomanable incrementar el PCTFREE en comptes
de INITRANS ja que l'espai assignat per INITRANS
En l'exemple és pot veure com el mapatge d'un
XID amb l'estructura d’un segment de rollback. És
realitza una cerca per localitzar el segment de
rollback/undo (RBU) apropiat. Es localitza el
nombre de slot dins de la taula de transacció de la
capçalera del bloc de RBU i es verifica el nombre
de wrap. Si el nombre de wrap dins del slot de la
taula de transacció és diferent del nombre de wrap
dins del XID, el slot ha sigut reutilitzat per una
transacció posterior.
4 Bloqueig de buffers
Per cada bloc a la buffer cache, hi ha una capçalera

3
de buffer. Aquestes capçaleres actuen com a
estructures de recursos als bloquejos de buffer. Les
sessions manipulen la capçaleres per mitjà dels
gestors de buffer, que són unes estructures que
s’assignen dinàmicament i que actuen com
estructures de bloquejos. Els bloquejos de buffer
poden ser adquirits de manera compartida o
exclusiva.
Les capçaleres dels buffers implementen una llista
doblement enllaçada dels gestors de buffers per a les
sessions que estan utilitzant i altra per als que estan
esperant.
Aquesta mena de bloquejos no s’implementen com
enqueues, s’implementen com estructures de
bloqueig dins de la buffer cache. Les sessions que
esperen per un bloqueig de buffer esperen en
l'esdeveniment d’espera buffer busy wait o write
complete waits.
4.1 Buffer busy waits
Quan una sessió vol llegir o modificar un buffer a la
SGA adquireix el latch cache buffer chains i travessa
la buffer chain fins trobar la capçalera del buffer
corresponent. Llavors ha d’adquirir un bloqueig a la
capçalera del buffer de manera exclusiva o
compartida depenent de l’operació a realitzar. Una
vegada que s’ha bloquejat i s’ha fixat la sessió,
allibera el latch i realitza l’operació pertinent. Si la
sessió no pot obtenir el bloqueig espera per buffer
busy waits. Es poden classificar segons el tipus de
contenció:
• Contenció al blocs de dades: té lloc quan hi
ha diverses sessions realitzant operacions
DML al mateix objecte al mateix moment o
per que diverses consultes accedeixen als
mateixos blocs. Depenent de la versió de
base de dades, aquest últim supòsit ha de
donar lloc a un nou esdeveniment d’espera
anomenat read by another session.
• Contenció a les capçaleres dels segments de
dades: té lloc quan algunes taules o índexs
tenen una activitat molt alta a les capçaleres
de segment. Un procés visita una capçalera
per obtenir o modificar les FREELIST i
estendre la marca d’aigua (HWM). Cada
segment té una o més freelist a la capçalera
del segment per realitzar un seguiment dels
blocs de dades per sota de la marca d’aigua.
• Contenció a les capçaleres de segment
d’undo: és causada per freqüents
actualitzacions a les capçaleres de segment
4
d’undo.
• Contenció als blocs d’undo: és provocada
quan diverses sessions concurrents estan
consultant dades i modificant-les al mateix
temps. Bàsicament les sessions que
consulten les dades estan lluitant per
imatges de lectures consistents dels blocs
de dades.
La contenció als blocs d’índex és similar a la
contenció als blocs de dades però existeixen dos
excepcions:
• Index block split: succeeix quan un bloc
d’índex ha de ser redistribuït, en aquest
cas, no es permeten operacions mentre
s’està duent a terme la redistribució.
• Bitmap índex update: cada entrada cobreix
un rang de rowids, si una sessió actualitza
una columna que forma part de l’índex,
l’entrada ha de ser actualitzada i aquesta
operació comprèn tres fases: descomprimir
el mapa de bits, modificar-lo i comprimir-
lo un altre vegada. Es tracta d’una operació
molt costosa i durant el temps que dura
l’operació cap altre sessió pot modificar
una fila del mateix rang. Per això no són
recomanables per sistemes OLTP.
4.2 Write complete waits
Quan un procés necessita modificar un buffer que
ha esta marcat com being writen espera per aquest
esdeveniment ja que no poden ser modificats fins
que hagin estat portats a disc i els seus flags
netejats.
5 Cas d'estudi: ITL i taula de
transaccions
En aquest cas d'estudi analitzarem com és la ITL i
una taula de transaccions.
Disposem d'una taula anomena còmics on tenim
emmagatzemats una serie de còmics, el seu
contingut és el següent:
ID NOM
---------- ------------
1 watchmen
2 dark knight
3 maus
4 tintin
El que farem serà actualitzar la quarta fila, recent generat per la transacció.
canviarem el nom de tintin pel de blake i mortimer
4. identifica l'estat de la transacció. C---
però no finalitzarem la transacció. Aquest és el
indica que la transacció ha estat
aspecte del bloc una vegada feta l'actualització:
confirmada i netejada. El valor ---- indica
block_row_dump: que la transacció està activa.
tab 0, row 0, @0x1f79 5. lck: és el nombre de files bloquejades per
tl: 15 fb: --H-FL-- lb: 0x0 cc: 2 la transacció en el bloc.
col 0: [ 2] c1 02 6. scn/fsc: pot indicar el scn o el nombre de
col 1: [ 8] 77 61 74 63 68 6d 65 6e bytes d'espai lliure que haurà disponibles si
tab 0, row 1, @0x1f67
la transacció confirma.
tl: 18 fb: --H-FL-- lb: 0x0 cc: 2 Si relacionem el bloc amb la ITL veurem que el
efectivament el lock byte del bloc és la posició que
col 0: [ 2] c1 03
ocupa la transacció en la llista (0x3). També
col 1: [11] 64 61 72 6b 20 6b 6e 69 67 68 74 s'observa que el flag de la transacció 0x03 és ---.
tab 0, row 2, @0x1f5c Això indica que la transacció no ha finalitzat i
tl: 11 fb: --H-FL-- lb: 0x0 cc: 2 encara està activa i que té una fila bloquejada
(lck=1).
col 0: [ 2] c1 04
D'altra banda la informació que ens proporciona el
col 1: [ 4] 6d 61 75 73
camp uba ens servirà per identifica la transacció
tab 0, row 3, @0x1e83 dins de la taula de transaccions del registre d'undo:
tl: 25 fb: --H-FL-- lb: 0x3 cc: 2 index state cflags wrap# uel scn dba
col 0: [ 2] c1 05 0x00 9 0x00 0x04c0 0x001d 0x0000.002dba60 0x00c00103

col 1: [18] 62 6c 61 6b 65 20 61 6e 64 20 6d 6f 72 74 69 6d 65 0x01 9 0x00 0x04c0 0x0000 0x0000.002dba5b 0x00c00103

72 0x02 9 0x00 0x04c0 0x001a 0x0000.002dbc3c 0x00c00104

tab 0, row 4, @0x1f08 0x03 9 0x00 0x04bd 0x001e 0x0000.002dba94 0x00c00103

tl: 16 fb: --H-FL-- lb: 0x0 cc: 2 0x04 9 0x00 0x04c0 0x000b 0x0000.002dbbe3 0x00c00104

0x05 9 0x00 0x04c0 0x0017 0x0000.002dbd11 0x00c00105

col 0: [ 2] c1 06
0x06 9 0x00 0x04c0 0x000a 0x0000.002dbed1 0x00c00106
col 1: [ 9] 62 6c 75 65 62 65 72 72 79
0x07 9 0x00 0x04c0 0x0018 0x0000.002dbacc 0x00c00104
end_of_block_dump 0x08 9 0x00 0x04c0 0x001c 0x0000.002dbc72 0x00c00104
Es pot observar que la quarta fila te el byte de 0x09 9 0x00 0x04be 0xffff 0x0000.002dbf00 0x00c00106
bloqueig activat, el camp lock byte (lb) te un valor. 0x0a 9 0x00 0x04c0 0x0009 0x0000.002dbeed 0x00c00106
Aquest valor ha de coincidir amb la posició que 0x0b 9 0x00 0x04c0 0x0002 0x0000.002dbc2d 0x00c00104
ocupa en l'índex de la ITL. La ITL es mostra a 0x0c 9 0x00 0x04c0 0x0019 0x0000.002dbb44 0x00c00104
continuació:
0x0d 9 0x00 0x04bf 0x0008 0x0000.002dbc53 0x00c00104
Itl Xid Uba Flag Lck Scn/Fsc
0x0e 9 0x00 0x04c0 0x0011 0x0000.002dbd1d 0x00c00105
0x01 0x0009.015.000004b0 0x00c001df.00ce.18 C--- 0 scn 0x0000.002d51fc
0x0f 9 0x00 0x04c0 0x0014 0x0000.002dbdfa 0x00c00105
0x02 0x0009.00c.000004b6 0x00c01743.00d7.2b C--- 0 scn 0x0000.002d8ef4
0x10 9 0x00 0x04bf 0x0001 0x0000.002dba59 0x00c00103
0x03 0x0009.021.000004bf 0x00c00106.00ea.23 ---- 1 fsc 0x0000.00000000
0x11 9 0x00 0x04c0 0x0015 0x0000.002dbd2e 0x00c00105

0x12 9 0x00 0x04c0 0x0016 0x0000.002dbd7c 0x00c00105

La informació que ens aporta és la següent: 0x13 9 0x00 0x04c0 0x0012 0x0000.002dbd4d 0x00c00105

1. itl: és el index que ocupa dins del array. És 0x14 9 0x00 0x04c0 0x0006 0x0000.002dbe67 0x00c00105

el valor que utilitza el lock byte del bloc per 0x15 9 0x00 0x04c0 0x0013 0x0000.002dbd34 0x00c00105
mostrar quina transacció ha bloquejat la fila. 0x16 9 0x00 0x04c0 0x0020 0x0000.002dbdad 0x00c00105

2. xid: és l'identificador de la transacció que ha 0x17 9 0x00 0x04bf 0x000e 0x0000.002dbd15 0x00c00105
modificat el bloc. El seu format és segment 0x18 9 0x00 0x04bf 0x000c 0x0000.002dbb07 0x00c00104
+ undo slot + undo sequence number. 0x19 9 0x00 0x04bf 0x001f 0x0000.002dbb95 0x00c00104

3. uba: és l'adreça del registre d'undo del més 0x1a 9 0x00 0x04bf 0x000d 0x0000.002dbc43 0x00c00104

5
 0x1b 9 0x00 0x04be 0x0003 0x0000.002dba87 0x00c00103

0x1c 9 0x00 0x04bf 0x0005 0x0000.002dbd09 0x00c00105

0x1d 9 0x00 0x04bf 0x001b 0x0000.002dba6d 0x00c00103

0x1e 9 0x00 0x04bf 0x0007 0x0000.002dbab0 0x00c00104

0x1f 9 0x00 0x04bf 0x0004 0x0000.002dbbcd 0x00c00104

0x20 9 0x00 0x04bf 0x000f 0x0000.002dbdbf 0x00c00105

0x21 10 0x80 0x04bf 0x0000 0x0000.002db6f9 0x00c00106

La taula de transaccions està composta diverses

columnes però les principals són:
• index: identifica la fila dins de la taula de
transacció.
• state: l'estat de la transacció, 9 inactiva i 10
activa.
• cflags: flag que mostra l'estat de la
transacció: 0x0 sense transacció, 0x10
transacció eliminada, 0x80 transacció activa
i 0x90 realitzant rollback.
• wrap#: un comptador per el nombre de
vegades que el slot ha estat utilitzat.
• uel: és un punter a la següent transacció a
utilitzar després de que aquesta s'activi.
• scn: el scn de la transacció confirmada.
• dba: adreça del bloc de l'últim bloc d'undo
que la transacció utilitzada per escriure un
registre d'undo.
Analitzant la taula de transaccions veiem que la
transacció 33 (0x21) és la que està activa, el valor de
la columna state és 10 i cflag val 0x80.
A partir del dba es pot identificar l'últim bloc d'undo
que ha utilitzat la transacció que és el 0x00c00106
coincideix amb la del camp uba de la ITL.