Administració , àrees i
assignacions de memòria
en el SGDB Oracle
1 Introducció
El següent document és una descripció sobre
l’administració de memòria en un RDBMS Oracle.
Es fa una descripció de les diferents àrees de
memòria utilitzades i com aquestes àrees són
assignades. També es fa una descripció de
l'arquitectura d’un heap i dels algoritmes utilitzats
per administrar la memòria
2 Les àrees de la memòria
Les estructures de memòria en una instància Oracle
són:
1. System Global Area o SGA que és un gran
segment de memòria compartida al que
accedeixen tots el processos d' una instància
en un moment o altre.
2. Process Memory Area de les que formen
part:
• Program Global Area o PGA que és
la memòria privada d'un procés o fill
i que no és accessible per altres
processos o fills.
• User Global Area o UGA que és la
memòria associada amb una sessió.
Depenent del tipus de connexió es
pot trobar a SGA o a la PGA
• Call Global Area o CGA que conté
la informació associada una crida
específica.
1
2.1 System global area
La SGA és l'àrea de memòria compartida que
Oracle crea al iniciar la instància. Tots el processos
de segon plà connecten amb aquest segment de
memòria compartida quan entra en execució. La
seva principal funció es proveir al sistema de les
següents funcionalitats:
1. Memòria cau
2. Concurrència
3. Consistència
4. Control
Per si mateixa és simplement un segment de
memòria compartida. És l'us de la SGA per part del
nucli d'Oracle el que proveeix totes les funcio-
nalitats indicades amb anterioritat. La seva mida
varia des d'uns pocs megabytes en sistemes petits
fins a gigabytes en grans sistemes.
En els sistemes operatius tipus UNIX, la SGA és
una entitat física que es pot veure des de la línia de
comandes del sistema operatiu i està implementada
com un segment de memòria amb el qual els
processos poden interactuar.
De cara a obtenir un rendiment òptim en la majoria
dels sistemes, la totalitat del SGA ha de residir en
memòria real. Si això no és possible i es fa ús de la
memòria virtual per emmagatzema parts de la SGA
el rendiment del sistema disminueix severament ja
que parts de la SGA són paginades (escrites a i
llegides des de disc) per el sistema operatiu
2.1.1 Grànul
La unitat bàsica d' assignació de memòria de la
SGA és el grànul. La seva mida pot variar, per
sistemes petits és de 4MB mentre que per a
sistemes grans 16MB. Quan diem sistemes petits
volem dir sistemes amb menys d’1 GB, (per a
versions antigues 128MB) però és possible que es
donin altres variacions. Els grànuls van ser
introduïts per tenir la possibilitar d'assignar més
memòria manualment mentre la instància està en
execució. A partir de la versió 10g és el mateix nucli
d’Oracle amb el paràmetre sga_target el que pot
assignar més memòria automàticament a les
subpools de la SGA però amb 11g es poden
administrar automàticament totes les memòries, SGA
i la PGA, per mitjà del paràmetre memory_target.
Grànul assignat a la buffer cache
Quan una instància és inicialitzada es creen un
conjunt de grànuls organitzats dins d’un array
segmentat i cadascuna de les entrades de l'array és
una capçalera del grànul que representa i
emmagatzema metadades i informació d’estat. Un
grànul pot trobar-se en tres estats:
• lliure: es poden triar per ser consumits en
operacions en que la memòria ha de créixer.
• inicialitzat: és transitori i només es dona
durant un procés de canvi de mida, una
vegada finalitzat el procés passa a estat
assignat.
• assignat: un grànul que forma part d’un
segment.
Grànuls en un array i en llistes enllaçades
Els grànuls divideixen un gran tros de memòria en
trossos més petits i molt més senzills d'administrar,
al tenir la mateixa mida permet assignar memòria de
la buffer cache a la shared pool o al contrari quan és
necessari.
2.1.2 Memòria compartida i semàfors
El nucli d’oracle usa la memòria compartida i els
semàfors per la comunicació entre processos dins de
la SGA.
2
La comunicació es duu a terme dins de l’espai
d’adreces de la SGA. Els processos que volen
interactuar han d’atacar aquests segments dins
d’aquest espai d’adreces i intercanviar informació
llegint o escrivint dades a les àrees compartides. El
format de les dades i la seva localització ve
determinada pels processos, no està controlada per
el sistema operatiu i son ells els responsables
d'assegurar que no s’escriu a la mateixa posició
simultàniament.
IPC Memòria compartida
D'altra banda els semàfors controlen la integritat de
la memòria compartida actuant com a mecanisme
d’exclusió mútua. Quan un procés necessita
accedir a una posició de memòria compartida
primer ha de mirar si el semàfor d’aquesta posició
de memòria està lliure i si no és així haurà
d’esperar fins que estigui lliure.
Hi ha certs requeriments de la memòria compartida
i dels semàfors que s’han de complir per a que la
base de dades funcioni correctament. Quan s’inicia
la instància el sistema operatiu assigna una porció
de memòria per a crear la SGA, si la memòria
compartida o els semàfors relacionats no estan
establerts correctament la instància no s'iniciarà i
retornarà un error.
2.1.3 Configurant la memòria
compartida
La SGA resideix a la memòria compartida i per tant
ha d'estar disponible per a tots els processos que
podran accedir a qualsevol adreça de memòria de la
SGA. Els valors de la memòria compartida han
d’estar establerts en la configuració del sistema
operatiu.
A continuació es mostren els valors generals que
han de tenir els paràmetres de memòria compartida:
• SHMMNI: el nombre màxim de segments
 de memòria compartida en tot el sistema.
• SHMMAX: la mida màxima de cada
segment.
• SHMALL: el nombre màxim de pàgines de
memòria compartida en tot el sistema.
Un segment no ha de ser necessàriament tan gran
com la mida màxima, és només tan gran com el
espai concedit. Si un procés necessita una mida de
segment més gran que la que pot ser assignada,
estarà compost per diversos segments. Sovint una
instància ha d'assignar diversos segments a una SGA
gran.
El paràmetre SHMMAX limita la mida de cada
segment en el sistema i hauria de ser igual o més
gran que el major segment; en cas contrari la SGA
estarà composta per múltiples segments.
2.1.4 Configurant els semàfors
Els semàfors són un mètode robust per controlar
l'accés a recursos crítics. La instància Oracle utilitza
aquest mecanisme principalment per controlar
l'accés a la memòria compartida Són assignats en
funció del paràmetre d'inicialització processes que
determina el nombre màxim de processos que es
poden connectar concurrent a la base de dades.
Cada instància intentar assignar dos conjunts de
semàfors inicialment i immediatament després
allibera un d'ells evitant l'esgotament d'aquest recurs.
Cada conjunt assigna un mínim de tants semàfors
com el valor del paràmetre processes, i si no és així
la instància assignarà tants com sigui necessari per
satisfer el nombre de semàfors que requereix. Si la
instància no pot assignar suficients semàfors en un o
diversos conjunts la instància no s'inicia.
A continuació es mostren els valors generals que han
de tenir els paràmetres de memòria compartida:
• SEMMSL: nombre màxim de semàfors per
conjunt.
• SEMMNS: nombre total de semàfors en tot
el sistema.
• SEMOPM: nombre màxim d'operacions per
crida semop.
• SEMMNI: nombre màxim de conjunts de
semàfors.
Una crida semop és una crida a una funció per
utilitzar els semàfors.
3
2.1.5 Els database blocks buffer
Els database block buffers contenen còpies dels
blocs llegits dels fitxers de dades. El terme
database block és utilitzat per descriure un bloc que
conté dades d'una taula, d'un índex o de desfer.
Bàsicament és un bloc que conté dades i que tots
els processos comparteixen accedint-hi
concurrentment.
Aquesta àrea de la SGA només conté els blocs en si
mateix ja que la informació de control
s'emmagatzema en l'àrea variable.
La seva mida ve determinada per dos paràmetres:
un defineix la mida de la memòria i altre defineix
la mida del bloc.
2.1.6 El buffer de redo
Es tracta d'una memòria intermèdia de forma
circular que conté informació dels canvis que s'han
fet a la base de dades i que són escrits als fitxers de
log.
Aquesta informació serà utilitzada en cas de neces-
sitat per reconstruir o desfer tots els canvis
realitzats a la base de dades per operacions DML i
DDL.
2.1.7 Variable area
L'àrea variable està formada per un conjunt de
pools de memòria. Un pool és un conjunt de blocs
de grandària fixa que permeten que la memòria
sigui assignada i desassiganada dinàmicament. El
seu principal inconvenient és que pateixen
fragmentació degut a que les mides dels trossos o
chunks de memòria son variables.
Els tres pools que la formen son:
1. Shared pool
2. Large pool
3. Java pool
2.1.8 Heaps
L'espai dins de les pools s'organitza en heaps.
Físicament un heap està format per una capçalera
i un conjunt d'extensions. El heap requereix d’espai
continuo per satisfer les peticions de memòria. Per
exemple si hi ha una petició de 4K no es poden
assignar dos trossos de 3K i 1K, ha de satisfer la
petició amb un de 4K de memòria continua. Si no
existeix un tros d’aquesta mida s’ha d’alliberar
espai del heap.
A mida que l'espai és assignat o desassignat es van
creant fragments anomenats chunk, que poden estar
assignats o lliures.
Dins d'un heap l'espai pot ser sol·licitat com una
assignació permanent o com espai que pot ser
alliberat i reutilitzat. Quan s'assigna un chunk d'espai
que pot ser alliberat s'especifica que el contingut del
chunk és reutilizable i pot ser desclavat (unpinned)
quan no està en ús.
Quan un usuari sol·licita l'espai d'un heap, primer es
realitza una recerca d'espai lliure mitjançant una
llista (free list), si no n'hi ha es poden desclavar
(unpinned) chunks que son mantinguts en llistes
LRU per determinar quin ha de ser el primer en
alliberar-se. Els chunks es poden separar per satisfer
una petició.
split d'un chunk
Si es requereix espai que sobrepassi la mida d'una
extensió sencera la petició serà satisfeta amb
múltiples chunks de diferents extensions.
Si encara no s'ha trobat espai, llavors es sol·licita
una nova extensió i s'afegeix al heap. Si l'assignació
es fa des d'un altre heap llavors es diu que es tracta
d'un subheap. Si no hi ha més extensions es produeix
un error ORA:04031.
2.1.9 Subheaps
Els subheaps tenen diversos propòsits:
4
• Eliminar la fragmentació causada per
assignar chunks petits de memòria
directament d'un heap pare.
• Permeten utilitzar la memòria més
eficientment ja que els chunks que serien
assignats temporalment en el heap pare
poden ser assignats permanentment en un
subhead.
• Elimina la necessitat de portar un registre
de tots els chunks de memòria que són
assignats en el subheap i que es poden
alliberar .
• Permet a la memòria compartida que és
utilitzada per un sol procés ser manipulada
sense adquirir un latch.
Quan un subhead és alliberat, les extensions son
alliberades en el heap pare.
2.1.10 La shared pool
Es podria definir com una memòria cau de
metadades. S'utilitza bàsicament per
l'emmagatzematge en memòria cau d'objectes que
descriuen on són les dades, com es relacionen amb
altres dades i com es poden recuperar.
Està organitzada com un heap i consisteix en:
1. Un àrea permanent de memòria on es troba
l'estructura de les dades.
2. Un àrea administrada dinàmicament on es
troben la library cache i la row cache.
L'espai en la shared pool està dividit en chunks de
diferents mides que pertanyen a una classe
d'assignació. Les principals son:
1. Permanents: el chunk roman assignat fins
que tot el heap és desassignat i normalment
són assignats en espai contigu per reduir la
fragmentació.
2. Alliberable: el chunk es pot alliberar.
3. Recreable: el chunk es pot recrear, això
implica que també és alliberable.
Està composta per grànuls de mateixa manera que
la cache de buffers i és aquesta granularitat la que
permet al mecanisme d’administració automàtica
de memòria moure memòria entre les diferents
parts de la SGA.
La shared pool està dividida en sub-pools que
consisteixen en un conjunt de grànuls. A partir de la
11g cada sub-pool també està dividit en 4 sub-sub-
pools anomenades durations, també cada sub-sub-
pool és un conjunt de grànuls.

Sub-pools i durations
Aquesta divisió en sub-pools i durations té com
avantatge principal una millor assignació i
alliberament de chunks el que es tradueix en menys
fragmentació.
El nombre de sub-pools ve determinat per la mida de
la shared pool i el nombre de CPUs.
2.1.11 Assignacions de chunks
Quan es necessita espai s'inicia un cerca per trobar
un chunk lliure de la mida exacta. Els chunks estan
organitzats en llistes lliures (free lists) segons la seva
mida però si no es troba la mida exacta es selecciona
el chunk de mida més aproximada i es compacta.
Si no pot trobar un chunk lliure a les llistes lliures
s'intenta trobar chunks recreables que estan
desclavats (unpinned), organitzats en llistes LRU.
Que estiguin en estat desclavats vol dir que no estan
en us. Existeixen dues llistes LRU per chunks
inactius:
• Transitoris: que ja no és necessiten.
• Recurrents: seran necessaris en un futur.
Si no hi ha chunks disponibles llavors s'alliberaran
chunks d'aquestes llistes alternativament, començant
per la llista dels transitoris i aturant-se quan s'ha
trobat un chunk suficientment gran.
2.1.12 La large pool
És un àrea de la SGA on es fan assignacions de grans
peces de memòria que són majors que les que pot
suportar la shared pool. S'utilitza específica-ment
per:
1. Connexions de servidors compartits, per
assignar la regió UGA en el SGA.
2. L'execució en paral·lel per permetre
l'assignació dels emmagatzematges
intermedis de missatges entre processos, que
s'utilitzen per coordinar els servidors de
consultes paral·leles.
3. Còpia de seguretat amb RMAN
5
4. Comunicació de procesos via cues (avan-
ced queuing)
Segregant aquestes grans assignacions de memòria
de la shared pool disminueix la seva fragmentació
incrementa la seva eficiència.
2.1.13 La java pool
S'utilitza per executar java a la base de dades. Si
tenim un procediment emmagatzemat en Java,
Oracle utilitzarà aquest tros de memòria per a
processar aquest codi.
2.1.14 Streams pool
El pool de streams és utilitzat exclusivament per les
memòries intermèdies de les cues de missatges
utilitzades en el processos de comunicació
indirecta.
2.2 Process global area
És un àrea de memòria privada a cada procés i no
és compartida, per tant, no es necessiten
mecanismes d'exclusió per protegir la informació ja
que cap altre procés hi pot accedir. Part de la PGA
pot ser assignada en la SGA quan utilitzen shared
servers.
La PGA conté informació sobre recursos del
sistema operatiu que són utilitzats per els
processos, per exemple els descriptors de fitxer, i
informació privada sobre l'estat del procés. Conté
les següents àrees de memòria:
1. Àrea privada de SQL que conté dades
sobre informació d'enllaç (bind variables) i
estruc-tures de memòria en execució.
2. Cursors i àrees SQL per a OCI i Pro*C,
també cursors recursius utilitzats
implícitament per SQLs.
3. Àrea de treball (work area) per a consultes
complexes assignant memòria per a
operacions intensives com ordenacions,
hash-join, bitmap merge, bitmap create i
escriptura de buffers en operacions de
carregues massives (bulk load)
4. Memòria de sessió que és la memòria
assignada per a les variables d'inici i altra
informació relacionada amb la sessió.
D'altra banda per a connexions del tipus
shared server la memòria de sessió és
compartida.

La memòria és assignada mitjançant crides de C del
tipus malloc o memmap i pot créixer o disminuir en
temps d'execució. Es pot descompondre en dos
components principals:
• PGA fixa que conté diverses variables de
mida fixa i alguns punters a la PGA variable.
• PGA variable que està organitzada com un
heap. Té una àrea permanent amb dades de
les taules fixes, fitxers de control, un
subheap per la UGA (si no es tracta d'una
connexió shared server) i un subheap per a la
CGA.
2.2.1 User global area
La user global area conté informació específica de la
sessió i té dos components:
• La UGA fixa que conté diverses variables de
mida fixa i amb informació sobre la UGA
variable.
• La UGA variable organitzada com un heap i
com informació sobre els cursors oberts,
estat dels procediments en ús, informació
modificable a nivell de sessió com traces,
paràmetres del optimizador ...
• Els links de base de dades oberts
• Rols actius
Quan es fa ús de servidors dedicats la UGA fixa és
part de la PGA fixa i la UGA variable és un subheap
dins de la PGA variable. Si per el contrari fem ús de
shared server la UGA és compartida per un conjunt
de diferents processos i és un subheap de la SGA.
La UGA és, en efecte, l'estat de la sessió. La
ubicació de la UGA és totalment dependent de la
forma de connectar-se a Oracle. Si es connecta a
través d'un servidor compartit, la UGA s'ha d'
emmagatzemar en una estructura de memòria en que
6
tots els processos de servidor compartit hi tinguin
accés i aquest lloc és en el SGA. D'aquesta manera,
la sessió pot utilitzar qualsevol dels servidors
compartits, ja que qualsevol d'ells pot llegir i
escriure dades de la sessió.
D'altra banda, si estem utilitzant una connexió de
servidor dedicat, no hi ha necessitat d'un accés
universal al seu estat de la sessió, i la UGA es
converteix pràcticament en sinònim de la PGA. De
fet, es troba al PGA del servidor dedicat. Quan ens
fixem en les estadístiques del sistema, la
informació de la UGA es troba a la PGA (la PGA
serà major o igual a la memòria UGA utilitzada ja
que la mida de la memòria PGA inclourà la mida
UGA).
2.2.2 Call global area
La call global area conté informació de crides
específiques i es requereix per la realització dels
parse, execucions, fetch, SQL recursiu i crides
PL/SQL. Emmagatzema dades temporals, és a dir,
el contingut de la CGA és transitori, i el seu
contingut es desassignat al final de la crida.
Estrictament parlant, el seu contingut no pertany a
una àrea global i el seu contingut és accedit només
per un procés a no ser que sigui accedit per shared
servers, en aquest cas és accedida per diversos
processos.
La CGA emmagatzema buffers d'entrada i sortida i
espai de pila per avaluació. Sempre és un subheap
de la PGA.
3 Cas d'estudi, assignant
memòria compartida.
IPCS és una comanda de UNIX/Linux que és
utilitzada per obtenir informació sobre la
comunicació entre processos. Utilitzarem aquesta
comanda per obtenir informació de l'estat de la
SGA i dels semàfors.
3.1 Model d'un sol segment
En aquets primer cas es fixarà tota la SGA dins
d'un sol segment.
La configuració del paràmetre que ens indica la
mida màxima d'un segment (SHMMAX) és de
2147483648 bytes que son 2GB.
oracle@Colosus:~$ cat /etc/sysctl.conf | grep shm
kernel.shmall=2097152
kernel.shmmni=4096
kernel.shmmax=2147483648 ------ Semaphore Arrays --------

La nostra SGA és d'un 1G: key semid owner perms nsems

NAME VALUE 0x5c23a1bc 491520 oracle 660 154

sga_max_size 1073741824 Per 300 processos:

Per tant la SGA és assignada en un sol segment de NAME VALUE
1GB. processes 300
oracle@Colosus:~$ ipcs -m Tenim tres conjunts de 152 semàfors cadascun per
------ Shared Memory Segments -------- a la instància
key shmid owner perms bytes nattch ------ Semaphore Arrays --------
0xd3ac6c80 1015819 oracle 660 1075838976 25 key semid owner perms nsems
0x5c23a1bc 622592 oracle 660 152
3.2 Model de diversos segments 0x5c23a1bd 655361 oracle 660 152

En aquest segon cas hem modificat la mida màxima 0x5c23a1be 688130 oracle 660 152
del segment a 268435456 bytes que són 256MB, per
tant el sistema operatiu tractarà de fixar els 1024MB
de la SGA en diversos segments:
5 Cas d'estudi: estructures
oracle@Colosus:~$ cat /etc/sysctl.conf | grep shm de la shared pool
kernel.shmall=4194304
kernel.shmmni=4096
En el següent cas d'estudi analitzarem com és
l'estructura de la shared pool analitzant un bolcat de
kernel.shmmax=268435456 memòria (dump).
La nostra SGA continua sent de un 1G:
NAME VALUE 5.1 Num de subpools al sistema
sga_max_size 1073741824

En aquest cas s'han utilitzat 5 segments per assignar La shared pool està dividida en subpools, el
la SGA. nombre de subpools depèn de la mida de diversos
------ Shared Memory Segments --------
paràmetres com la memòria o el nombre de CPUs.
Existeix un paràmetre per especificar el nombre de
key shmid owner perms bytes nattch subpools. El paràmetre és el _kghdsidx_count i pot
0x00000000 1376267 oracle 660 12582912 25 prendre valors entre 1 i 7.
0x00000000 1409039 oracle 660 268435456 25
0x00000000 1441813 oracle 660 268435456 25
0x00000000 1474582 oracle 660 268435456 25
0xd3ac6c80 1507351 oracle 660 257949696 25

4 Cas d'estudi, nombre de

semàfors
El nombre de semàfors utilitzats per una instància
sempre serà superior al valor del paràmetre
Una vegada reiniciat el sistema tenim 3 subpools.
PROCESSES. Veurem quins valors prenen per
diferents valors d'aquest paràmetre.
Per 150 processos: 5.2 Generació de la traça
NAME VALUE Per generar el bolcat de memòria farem ús de la
processes 150
utilitat oradebug. El paràmetre heapdump 2 indica
que es tracta de la SGA heap.
Tenim un conjunts de 154 semàfors per a la instancia

7
 Chunk 078800058 sz= 48 R-freeable "reserved stoppe"
Chunk 078800088 sz= 212808 R-free " "
Chunk 078833fd0 sz= 48 R-freeable "reserved stoppe"
Chunk 078834000 sz= 3981160 perm "perm "
Chunk 078bfff68 sz= 152 free " "
EXTENT 2 addr=0x79400000
Chunk 079400058 sz= 48 R-freeable "reserved stoppe"
5.3 Subpools i durations Chunk 079400088 sz= 212808 R-free " "

Una vegada generada la traça procedint a analitzar- Chunk 079433fd0 sz= 48 R-freeable "reserved stoppe"
la. El bolcat ha de mostrar 3 subpools amb quatre Chunk 079434000 sz= 3962920 perm "perm "
durations cadascuna. Si extraiem les capçaleres on Chunk 0797fb828 sz= 16416 perm "perm "
trobem la definició dels heaps obtenim:
Chunk 0797ff848 sz= 1976 free " "
HEAP DUMP heap name="sga heap" desc=0x60001188
EXTENT 3 addr=0x7a000000
HEAP DUMP heap name="sga heap(1,0)" desc=0x60050908
Chunk 07a000058 sz= 48 R-freeable "reserved stoppe"
HEAP DUMP heap name="sga heap(1,1)" desc=0x60052160
Chunk 07a000088 sz= 212808 R-free " "
HEAP DUMP heap name="sga heap(1,2)" desc=0x600539b8 Chunk 07a033fd0 sz= 48 R-freeable "reserved stoppe"
HEAP DUMP heap name="sga heap(1,3)" desc=0x60055210 Chunk 07a034000 sz= 3975920 perm "perm "
HEAP DUMP heap name="sga heap(2,0)" desc=0x6005a1d0 Chunk 07a3feaf0 sz= 5392 free " "
HEAP DUMP heap name="sga heap(2,1)" desc=0x6005ba28 EXTENT 4 addr=0x7ac00000
HEAP DUMP heap name="sga heap(2,2)" desc=0x6005d280 Chunk 07ac00058 sz= 48 R-freeable "reserved stoppe"
HEAP DUMP heap name="sga heap(2,3)" desc=0x6005ead8 Chunk 07ac00088 sz= 212808 R-free " "
HEAP DUMP heap name="sga heap(3,0)" desc=0x60063a98 Chunk 07ac33fd0 sz= 48 R-freeable "reserved stoppe"
HEAP DUMP heap name="sga heap(3,1)" desc=0x600652f0 Chunk 07ac34000 sz= 3550128 perm "perm "
HEAP DUMP heap name="sga heap(3,2)" desc=0x60066b48 Chunk 07af96bb0 sz= 430112 perm "perm "

HEAP DUMP heap name="sga heap(3,3)" desc=0x600683a0 Chunk 07afffbd0 sz= 1072 free " "

Es tracta d'una shared pool amb 3 subpools i 4 EXTENT 5 addr=0x7c800000

durations. Chunk 07c800058 sz= 48 R-freeable "reserved stoppe"
Chunk 07c800088 sz= 4076176 R-perm "perm "

5.4 Extensions Chunk 07cbe3318 sz= 117944 R-free " "

Chunk 07cbfffd0 sz= 48 R-freeable "reserved stoppe"
A continuació analitzarem la primera primera
subpool del primer duration: EXTENT 6 addr=0x7d000000

HEAP DUMP heap name="sga heap(1,0)" desc=0x60050908 Chunk 07d000058 sz= 48 R-freeable "reserved stoppe"

extent sz=0xfe0 alt=248 het=32767 rec=9 flg=-126 opc=0 Chunk 07d000088 sz= 212808 R-free " "

parent=(nil) owner=(nil) nex=(nil) xsz=0x400000 heap=(nil) Chunk 07d033fd0 sz= 48 R-freeable "reserved stoppe"

fl2=0x20, nex=(nil) Chunk 07d034000 sz= 1491824 perm "perm "

latch set 1 of 3 Chunk 07d1a0370 sz= 2409016 perm "perm "

durations enabled for this heap Chunk 07d3ec5a8 sz= 71712 perm "perm "

reserved granules for root 0 (granule size 4194304) Chunk 07d3fddc8 sz= 8760 free " "

EXTENT 0 addr=0x77800000 EXTENT 7 addr=0x7e400000

Chunk 077800058 sz= 48 R-freeable "reserved stoppe" Chunk 07e400058 sz= 48 R-freeable "reserved stoppe"

Chunk 077800088 sz= 212808 R-free " " Chunk 07e400088 sz= 212808 R-free " "

Chunk 077833fd0 sz= 48 R-freeable "reserved stoppe" Chunk 07e433fd0 sz= 48 R-freeable "reserved stoppe"

Chunk 077834000 sz= 3981312 perm "perm " Chunk 07e434000 sz= 3976208 perm "perm "

EXTENT 1 addr=0x78800000 Chunk 07e7fec10 sz= 5104 free " "

8
EXTENT 8 addr=0x7e800000 ....
Chunk 07e800058 sz= 48 R-freeable "reserved stoppe" Bucket 43 size=376
Chunk 07e800088 sz= 212808 R-free " " Chunk 07ebffe88 sz= 376 free " "
Chunk 07e833fd0 sz= 48 R-freeable "reserved stoppe" ....
Chunk 07e834000 sz= 3980936 perm "perm " Bucket 128 size=1056
Chunk 07ebffe88 sz= 376 free " " Bucket 129 size=1064
Total heap size = 37747944 Bucket 130 size=1072
Chunk 07afffbd0 sz= 1072 free " "
La mida del grànul en la nostra instància es de 4MB: ....
Bucket 196 size=1960
Chunk 0797ff848 sz= 1976 free " "
Bucket 197 size=2008
....
Bucket 242 size=4120
Chunk 07a3feaf0 sz= 5392 free " "
Chunk 07e7fec10 sz= 5104 free " "

Les línies que comencen per chunk identifiquen els Bucket 243 size=8216
chunks de memòria dins de l'extensió, l'adreça de Bucket 244 size=8696
memòria on comença i la mida en bytes. Bucket 245 size=8704
Cada chunk és d'una classe (free, perm ...) i ens Bucket 246 size=8712
indica si el chunk està lliure, si és permanent si és Bucket 247 size=8720
recreable o si es pot alliberar. Els que van precedits
Chunk 07d3fddc8 sz= 8760 free " "
d'una R vol dir que són per la reserva, part de la
memòria que es reserva per si no es troben chunk Bucket 248 size=9368
lliures en les llistes lliures (free list). Bucket 249 size=9376

Que un chunk sigui freeable vol dir que pot ser Bucket 250 size=12352
alliberat però només si el pare (parent) fa la crida per Bucket 251 size=12360
alliberar-lo. Bucket 252 size=16408
Es pot veure que existeixen parells de chunks R- Bucket 253 size=32792
freeable de 48 bytes flanquejant chunks R-free, són Bucket 254 size=65560
els límits que impedeixen que el chunk R-free sigui
Total free space = 22832
inserit en la llista correcta encara que seus chunks
adjacents siguin alliberats.
Es pot veure que existeixen diverses mides de
chunks lliures dins de la llista. Aquesta estratègia
5.5 Llistes lliures (free list) serveix per optimitzar la necessitat de trobar una
Les llistes lliures emmagatzemen informació sobre mida exacta en l’assignació de memòria.
chunck lliures, quan es fa una nova petició per
La mida del chunk es va incrementant en 8 bytes
assignar memòria dins de la shared pool s'ha de
fins arribar a un llindar, en el nostre cas el bucket
cerca un chunk que pugui contenir l'objecte.
196, a partir d’aquest punt la mida s’incrementa de
La llista lliure de la primera subpool és la següent: forma no lineal per poder atendre peticions menys
FREE LISTS: comunes.
Bucket 0 size=32 El espai total lliure és de 22.832 bytes.
Bucket 1 size=40
Bucket 2 size=48 5.6 Reserved free list
Chunk 078bfff68 sz= 152 free " "
La llista de lliure reservada és igual que una llista
Bucket 16 size=160 lliure però els chunks que content pertanyen a la

9
memòria reservada. La llista lliure reservada del Chunk 07faf1d58 sz= 1072 recreate "KQR PO "
primer subpool és la següent: Chunk 07faf0d58 sz= 1072 recreate "KQR PO "

RESERVED FREE LISTS: .....

Reserved bucket 0 size=32 Chunk 0755dd2e0 sz= 4096 recreate "SQLA^db4b04d9 "
Reserved bucket 1 size=4400
Reserved bucket 2 size=8216 SEPARATOR
Reserved bucket 3 size=8696
Chunk 07f881de0 sz= 1072 recreate "KQR PO "
Reserved bucket 4 size=8704
Reserved bucket 5 size=8712 Chunk 07f882210 sz= 1072 recreate "KQR PO "
Reserved bucket 6 size=8720
Reserved bucket 7 size=9368 Chunk 07f88b570 sz= 1072 recreate "KQR PO "
Reserved bucket 8 size=9376 Chunk 07f977fd0 sz= 1072 recreate "KQR PO "
Reserved bucket 9 size=12352
Reserved bucket 10 size=12360 Chunk 07f979888 sz= 1072 recreate "KQR PO "
Reserved bucket 11 size=16408 Chunk 07f9ff2f8 sz= 1072 recreate "KQR PO "
Reserved bucket 12 size=32792
Reserved bucket 13 size=65560 Chunk 07f907bd0 sz= 1072 recreate "KQR PO "
Chunk 077800088 sz= 212808 R-free " "
Chunk 075276540 sz= 4096 recreate "KGLH0^df923b4 "
Chunk 078800088 sz= 212808 R-free " "
Chunk 079400088 sz= 212808 R-free " " Chunk 07fa3a980 sz= 1072 recreate "KQR PO "
Chunk 07a000088 sz= 212808 R-free " "
....
Chunk 07ac00088 sz= 212808 R-free " "
Chunk 07cbe3318 sz= 117944 R-free " " Chunk 07fafa2e0 sz= 56 recreate "fixed allocatio"
Chunk 07d000088 sz= 212808 R-free " "
Chunk 07e400088 sz= 212808 R-free " " Chunk 07fa39f20 sz= 1072 recreate "KQR PO "
Chunk 07e800088 sz= 212808 R-free " " Chunk 075322000 sz= 4096 recreate "CCUR^9d1660bd "
Reserved bucket 14 size=1990604
Total reserved free space = 1820408 Chunk 075211540 sz= 4096 recreate "CCUR^cb0a064e "
Chunk 07520f540 sz= 4096 recreate "CCUR^551f47f6 "
Tenim 8 chunks reservats amb 1.820.408 bytes
d'espai lliure. Unpinned space = 2636192 rcr=623 trn=646

5.7 La llista LRU Tenim unes 2.5MB d'espai recrable de les quals
623 chunks són recurrents i 646 son transitoris.
Només el chunks recreables (recreatable) estan en la
llista LRU, quan estan fixats (pinned) se’ls treu Els transitoris estan ubicats al principi de la
temporalment. llista, fins el separador (separator), a
UNPINNED RECREATABLE CHUNKS (lru first): continuació estan els recurrents. Quan un nou
Chunk 0751da310 sz= 4096 recreate "KGLH0^c95fe42c " element és inserit en la llista s’ubica al
Chunk 0753a4000 sz= 4096 recreate "KGLH0^3ef2e58 " començament de la llista transitòria, si és
Chunk 0751d9310 sz= 4096 recreate "PCUR^fe83a388 "
reutilitzat es mou cap la llista recurrent. En tot
això podem trobar una similitud amb el
Chunk 07f9ddec0 sz= 512 recreate "KGLHD "
mecanismes utilitzats a la buffer cache
Chunk 0753f6000 sz= 4096 recreate "PCUR^12224b27 "
Chunk 0756e9d88 sz= 4096 recreate "KGLS^1a430833 "
Chunk 07576fb58 sz= 4096 recreate "KGLS^1a430833 "
5.8 Chunks permanents
Chunk 0757e9000 sz= 4096 recreate "KGLS^1a430833 " Finalment es pot trobar informació sobre els
Chunk 07f8e1970 sz= 528 recreate "KGLHD " chunks permanents:
Chunk 0751d4310 sz= 4096 recreate "PCUR^d56c8cee " PERMANENT CHUNKS:

Chunk 0751d1310 sz= 4096 recreate "PCUR^da040054 " Chunk 077834000 sz= 3981312 perm "perm "
Chunk 07f9ed0c8 sz= 512 recreate "KGLHD " Chunk 0797fb828 sz= 16416 perm "perm "
Chunk 0752bf540 sz= 4096 recreate "PCUR^661a149a " Chunk 078834000 sz= 3981160 perm "perm "
Chunk 07f8eb030 sz= 528 recreate "KGLHD " Chunk 079434000 sz= 3962920 perm "perm "
Chunk 07f8e88a0 sz= 528 recreate "KGLHD " Chunk 07d3ec5a8 sz= 71712 perm "perm "
Chunk 07f9dd740 sz= 512 recreate "KGLHD " Chunk 07af96bb0 sz= 430112 perm "perm "
Chunk 07f983020 sz= 1072 recreate "KQR PO " Chunk 07a034000 sz= 3975920 perm "perm "
Chunk 07f9842e8 sz= 1072 recreate "KQR PO " Chunk 07ac34000 sz= 3550128 perm "perm "
Chunk 07faf9798 sz= 1072 recreate "KQR PO "

10
 Chunk 07d1a0370 sz= 2409016 perm "perm "
Chunk 07c800088 sz= 4076176 R-perm "perm "
Chunk 07d034000 sz= 1491824 perm "perm "
Chunk 07e434000 sz= 3976208 perm "perm "
Chunk 07e834000 sz= 3980936 perm "perm "
Permanent space = 35903840

Aquests chunks ocupen un total aproximadat de

35MB d'espai a la subpool.

11