ESTRUCTURAS DE LA MEMORIA

Las estructuras de memoria bsicas asociadas con Oracle son:

SGA (System Global Area): est formada por un conjunto de estructuras de memoria que
contienen datos e informacin de control de la instancia. La SGA es compartida por todos
los procesos servidores y por los procesos de respaldo.
PGA (Program Global Area): es un rea de memoria no compartida que contiene datos e
informacin de control exclusivamente de un proceso de Oracle. La PGA se crea cuando el
proceso de Oracle arranca. Existe una PGA por cada proceso servidor y por cada proceso de
respaldo.
El conjunto de todas las PGA recibe el nombre de PGA total de la instancia o PGA de la
instancia. Los parmetros de inicializacin determinan el tamao total de la instancia de la
PGA, no de las PGA individuales.
UGA (User Global Area): esta memoria est asociada a cada sesin del usuario.
rea de cdigo: son porciones de memoria utilizadas para almacenar cdigo que se est
ejecutando o que puede ejecutarse. El cdigo de Oracle se almacena en un rea de software
que generalmente se encuentra en una ubicacin diferente de la de los programas de usuario.

PGA
La PGA es una memoria especfica para un proceso o un hilo que se comparte con otros procesos o
hilos del sistema, por lo que nunca se guarda en la SGA.
La PGA es una pila de memoria que contiene variables dependientes de la sesin necesarias para un
proceso servidor, ya sea dedicado o compartido. Es el propio proceso servidor el que reserva las
estructuras de memoria que necesita la PGA.
Es posible utilizar los parmetros de inicializacin para establecer el tamao mximo objetivo de la
PGA de la instancia, de tal forma que las PGA individuales pueden crecer hasta alcanzar este
tamao mximo.
Componentes dela PGA
La PGA se subdivide en varias reas, cada una con un objetivo diferente . No todos los
componentes de la PGA existen en todos los casos.
rea de SQL privada
El rea de SQL privada mantiene informacin acerca de las sentencias SQL parseadas y otra
informacin de sesin especca. Cuando un proceso servidor ejecuta cdigo SQL o PL/SQL,
utiliza esta zona de memoria para guardar las variables asociadas, la informacin de estado de la
ejecucin de la consulta y las reas de trabajo de la ejecucin de la consulta.
No hay que confundir el rea de SQL privada, que est en la PGA, con el rea de SQL compartida,
que almacena los planes de ejecucin en la SGA. Varias reas de SQL privadas, en la misma o en
diferentes sesiones, pueden apuntar a un nico plan de ejecucin en la SGA. Las reas de SQL
privadas para cada ejecucin no son compartidas y pueden contener distintos valores e informacin.
Un cursor es un nombre o un manejador de un rea de SQL privada especfica. Puede pensarse en
un cursor como un puntero en la parte del cliente y un estado en la parte del servidor. Puesto que los
cursores estn asociados con las reas de SQL privadas, a veces los trminos son intercambiables.
Las reas de SQL privadas se dividen en las siguientes subreas:

rea de ejecucin (Run-Time Area): contiene informacin de estado sobre la ejecucin de la

consulta como el nmero de las recuperado en full scan de la tabla. Oracle crea un rea de
ejecucin como el primer paso para ejecutar una peticin. Para las sentencias DML, el rea
de ejecucin se libera cuando la sentencia SQL se cierra.
rea persistente (Persistent Area): contiene los valores de la variable asociada que se
proporciona a una sentencia SQL en tiempo de ejecucin cuando se ejecuta la sentencia.
Esta rea se libera solo cuando se cierra el cursor.

El proceso cliente es el responsable de gestionar las reas de SQL privada. La asignacin y

liberacin del rea de SQL privada depende enormemente de la aplicacin, aunque el nmero de
reas SQL privadas que el proceso cliente puede manejar est limitado por el parmetro de
inicializacin OPEN_CURSORS.
En general, las aplicaciones deben cerrar todos los cursores abiertos que no se volvern a usar para
liberar memoria y minimizar la memoria requerida por los usuarios de la aplicacin.

reas de trabajo SQL (SQL Work Areas)

Un rea de trabajo es un rea de memoria dentro de la PGA empleada para operaciones
especialmente intensivas en trminos de memoria. Por ejemplo, una operacin de ordenacin utiliza
el rea de ordenacin para ordenar un conjunto de filas.
Si el total de los datos procesados por los operadores no caben en el rea de trabajo, Oracle divide
los datos de entrada en fragmentos ms pequeos. De esta manera, la base de datos procesa ciertos
fragmentos de la informacin en memoria mientras escribe el resto en almacenamiento temporal
para procesarlos ms tarde.
La base de datos automticamente ajusta los tamaos de las reas de trabajo cuando la gestin
automtica de la PGA est activa. Tambin se puede controlar y ajustar el tamao del rea de
trabajo.
Generalmente, mayores reas de trabajo suponen una mejora en las prestaciones del operador a
costa de un mayor consumo de memoria. La situacin ptima es que el tamao de un rea de trabajo
sea suciente para albergar los datos de entrada y las estructuras de memoria auxiliares que lleva
asociado el operador SQL. En caso contrario, el tiempo de respuesta aumenta porque parte de los
datos de entrada deben cachearse en disco. En el caso extremo, si el tamao de un rea de trabajo es
demasiado pequeo comparado con el tamao de los datos de entrada, la base de datos debe realizar
varios pasos sobre los fragmentos de datos, incrementando dramticamente el tiempo de respuesta.
SGA
La SGA es un rea de memoria de lectura y escritura que, junto con los procesos de respaldo,
constituye la instancia de la base de datos. Todos los procesos servidores que se ejecutan en nombre
de los clientes pueden leer informacin de la SGA de la instancia, aunque solamente algunos de
ellos pueden escribir en ella.
Los procesos servidores y los procesos de respaldo no residen en la SGA, sino que existen en un
espacio de memoria separado.
Cada instancia de la base de datos tiene su propia SGA. Oracle automticamente asigna memoria a
la SGA durante el arranque de la instancia y la libera durante la parada de la misma. Cuando se
arranca la instancia, se muestra el tamao de la SGA.
La SGA consiste en varios componentes de memoria. Todos los componentes de la SGA, excepto el
buffer de redo log, pueden asignar y liberar unidades contiguas de memoria llamadas grnulos. El
tamao de grnulo es especfico de la plataforma y es funcin del tamao total de la SGA. Se puede
obtener informacin de los componentes de la SGA consultando la vista V$SGA.
La SGA tiene tres componentes obligatorios (database buffer cach, buffer de redo log y shared
pool) y tres componentes opcionales (pool de Java, pool de streams y large pool).
Shared pool: Guarda (Cachea) la versin ms reciente de las sentencias SQL lanzadas por los
usuarios.
Database buffer cach: Guarda los los bloques de datos utilizados ms frecuentemente.
Buffer de redo log: Guarda informacin sobre transacciones para la recuperacin de la instancia.

Oracle llg gestiona los componentes de la SGA dinmicamente. La memoria de la SGA se asigna en
unidades contiguas de memoria llamadas grnulos, cuyo tamao depende del parmetro
MEMORY_MAX_TARGET. Si el valor de MEMORY_MAX_TARGET es mayor de 1.024 MB, el
tamao del grnulo puede ser 16 MB o 4 MB. LA asignacin mnima es de 3 grnulos, uno para
cada uno de los componentes obligatorios.
El tamao de los componentes de la SGA se obtiene de las vistas V$SGA y V$SGAINFO. Los
componentes que tienen en la columna RESIZABLE de esta ltima vista el valor Yes son los que se
pueden manejar dinmicamente.
A continuacin se introduce cada uno de los componentes de la SGA en detalle.
Database buffer cach
La database buffer cach es el rea de memoria que guarda las copias de los bloques de datos ledos
de los ficheros de datos. Sus principales funciones son las siguientes:

Optimizacin de la E/S fsica: la base de datos actualiza los bloques de datos de la cach y
guarda metadatos sobre los cambios en el buffer de redo log. Despus de un COMMIT, la
base de datos escribe los redo buffers en el disco, pero no escribe inmediatamente los
bloques de datos en disco. En su lugar, el DBWn lleva a cabo una escritura perezosa de los
mismos.
Mantener los bloques que son accedidos ms frecuentemente en la database buffer cach y
escribir los que se acceden con menos frecuencia en disco.

Estados del buffer

La database buffer cach es compartida entre todos los usuarios conectados a la base de datos.
Existen tres tipos de buffers:

DIRTY: contienen bloques de datos que deben escribirse en los ficheros de datos, ya que se
corresponden con informacin que todava no se ha escrito en disco.
FREE: no contienen datos o pueden sobrescribirse. Cuando Oracle lee datos de disco, los
carga en estos buffers.
PINNED: son buffers que estn siendo utilizados o que deben retenerse explcitamente para
su futuro uso.

La base de datos emplea un sofisticado algoritmo para garantizar que el acceso a los buffers es
eficiente. Se utiliza el algoritmo LRU (Least Recently Used), que clasifica a los buffers en calientes
(es accedido frecuentemente y usado recientemente) y fros (no ha sido utilizado recientemente).
E/S del buffer
Una E/S lgica o E/S del buffer hace referencia a las lecturas y escrituras de buffers en la database
buffer cach. Cuando un buffer solicitado no est en memoria la base de datos lleva a cabo una E/S
fsica para copiar dicho buffer desde disco a memoria y despus hace una E/S lgica para leer la
database buffer cach.

El proceso DBWn efecta escrituras peridicas de los buffers fros en estado DIRTY a disco. Estas
escrituras se producen en las siguientes condiciones:
* Un proceso servidor no puede encontrar un buffer en estado CLEAN para leer nuevos
bloques en la database buffer cach.
A medida que los buffers se ensucian (DIRTY), el nmero de buffers libres disminuye. Si el
nmero de buffers disminuye por debajo del umbral interno, y se necesitan buffers FREE, el
proceso servidor le solicita al DBWn que escriba en disco.
La base de datos utiliza la lista LRU para determinar cules de los buffers DIRTY escribir.
Cuando los buffers DIRTY alcanzan el extremo fro de la lista LRU, la base de datos los
mueve a una cola de escritura y los saca de la lista. El DBWn escribe los bloques de la cola en
disco, utilizan escrituras multibloque si es posible. Este mecanismo evita que el final de la cola
LRU se obstruya con buffers DIRTY y permite que los buffers FREE que se encuentren se
puedan reutilizar.
* La base de datos debe avanzar el checkpoint, que es la posicin en el hilo de redo desde la
que comienza la recuperacin de la instancia. El checkpoint puede ocurrir explcitamente
(porque se fuerce con la sentencia adecuada) o implcitamente. Un checkpoint implcito se
produce, por ejemplo, cuando un espacio de tablas cambia al estado off-line o al estado de solo
lectura. En este caso, el DWBn escribe en disco los bloques de datos DIRTY que contengan
bloques de los cheros de datos implicados.
* Cada 3 segundos, independientemente del volumen de actividad.
En cuanto a la lectura, cuando el nmero de buffers FREE es bajo, la base de datos debe borrar
los buffers de la database buffer cach. La base de datos reutiliza y sobrescribe los buffers
FREE en funcin de sus necesidades. Si el buffer sobrescrito se necesita ms tarde, la base de
datos deber recuperarlo de disco.
Cuando a un proceso servidor le llega una peticin de un proceso cliente, busca en la database
buffer cache el buffer. Un cache hit ocurre si la base de datos encuentra el buffer en memoria. El
orden de bsqueda es el siguiente:

El proceso servidor busca el buffer completo en la database buffer cach. Si lo encuentra

(cache hit), lleva a cabo una lectura lgica del mismo.
Si el proceso no encuentra el buffer en memoria (cache miss), copia el bloque desde un
fichero de datos a memoria (lectura fsica) y lleva a cabo una lectura lgica del buffer ledo
y que ahora est en memoria.

En general, el acceso a los datos a travs un cache hit es ms rpido que a travs de un cache miss.
La tasa de cache hit del buffer mide la frecuencia con la que la base de datos encuentra los bloques
solicitados en la database buffer cach sin necesidad de leerlo del disco. Una database buffer cach
bien ajustada tiene una tasa de cache hit del 90%.

Pool de buffers
Un pool de buffers es una coleccin de buffers. Para mejorar la gestin de la database buffer cach,
Oracle llg proporciona tres pools de buffers. Es posible asignar objetos del esquema especficos al
pool de buffer apropiado para controlar cmo caducan en la cach.
Los pools de buffers existentes son:

Pool DEFAULT: es donde se suelen cachear los bloques de datos. A menos que se
configuren los pools separados, ste es el nico pool que est disponible. Adems, es
obligatorio.
Pool KEEP: est pensado para los bloques que son accedidos con mayor frecuencia, pero
que han caducado en default pool por falta de espacio. El objetivo de este pool es retener los
objetos en memoria y evitar E/S. Si no se quiere que algunos datos caduquen en memoria,
con la sentencia ALTER TABLE puede indicarse explcitamente que los bloques de la tabla
se guarden en el pool Keep.
ALTER TABLE equipo STORAGE (BUFFER_POOL KEEP);

Pool RECYCLE: est pensado para los bloques que apenas se usan y su objetivo es evitar el
constuno innecesario de espacio en la cach.

Dimensionando adecuadamente el pool KEEP es posible mantener all los bloques frecuentemente
utilizados durante ms tiempo. El pool RECYCLE los borrar de memoria tan pronto como no se
necesiten.
Dimensionamiento de la database buffer cach
El tamao de la database table cach es crtico para las prestaciones. Debe ser lo suficientemente
grande como para albergar todos los bloques de datos utilizados frecuentemente, pero no tanto
como para que quepan aquellos que raramente se usan.
Una cach pequea supone una actividad de disco excesiva porque la cach se llena rpidamente y
el DBWn se ve forzado a guardar los bloques DIRTY en los ficheros de datos.
Una cach muy grande, en principio, no es malo, salvo que cause problemas de paginacin de
memoria virtual en el sistema operativo. Sin embargo, el arranque de la instancia se hace ms lento.
La mayora de las bases de datos trabajan con una database cach buffer de entre cientos de MB y
unos pocos GB.

Buffer de redo log

El buffer de redo log es un buffer circular que almacena las entradas de redo (rehacer) que describen
los cambios que se han producido en la base de datos. Las entradas de redo son vectores de cambios
que contienen la informacin necesaria para reconstruir los cambios hechos en la base de datos por
sentencias DML o DDL. Durante la recuperacin de la base de datos se aplican las entradas de redo
a los cheros de datos para reconstruir los cambios perdidos.
E1 parmetro LOG_BUFFER establece el tamao del buffer de redo log.
SQL> show parameters LOG_BUFFER
NAME
TYPE
VALUE
------------------------------------ ----------- -------------log_buffer
integer
4419584
Los procesos servidores copian las entradas de redo al buffer de redo log de la SGA. Estas entradas
estn en un orden secuencial y continuo en el buffer. El proceso LGWR escribe el contenido del
buffer de redo log en los cheros de on-line redo log del grupo de redo activo en disco.

El LGWR escribe las entradas de redo secuencialmente en el disco, mientras que el DBWn escribe
los bloques de datos en disco sin ningn tipo de orden. Estas escrituras dispersas tienden a ser
mucho ms lentas que las escrituras secuenciales. Puesto que el LWGR permite a los usuarios evitar
esperar a que el DBWn termine de escribir, la base de datos consigue unas mejores prestaciones.

SHARED POOL
El shared pool cachea distintos tipos de datos del programa que se aseguran durante el arranque de
la instancia. Se divide en varios componentes, los ms importantes son: Cach de librera, Cach del
diccionario de datos y Cach de resultados del servidor. Todas las estructuras de memoria del shared
pool se gestionan dinmicamente.

Cach de librera
La cach de librera es una pool de memoria compartida que almacena cdigo SQL y PL/SQL
ejecutable, en su forna parseada (p_code), y estructuras de control como los cerrojos. Cuando se
ejecuta una sentencia SQL, la base de datos intenta reutilizar el cdigo ejecutado con anterioridad.
Si existe una representacin parseada de una sentencia SQL en la cach de librera y sta puede
compartirse, la base de datos reutiliza el cdigo. Esto es lo que se conoce como parseado suave o
library cache hit. En caso contrario, la base de datos debe construir una versin ejecutable del
cdigo de la aplicacin (parseo duro o library cache miss).

SQL Areas
La base de datos representa cada sentencia SQL que se ejecuta en las siguientes reas de memoria:
Shared SQL Area: se utiliza para procesar la primera ocurrencia de una sentencia SQL. Es accesible
para todos los usuarios y contiene el rbol de parseo y el plan de ejecucin. Solo existe un rea SQL
compartida para una sentencia SQL.
Private SQL Area: (No nos referimos a la de la Shared Pool, que es solo para Servidor Compartico) cada sesin
que lanza una sentencia SQL tiene una Private SQL Area en su PGA. Cada usuario que enva la
misma sentencia tiene un rea SQL privada apuntando a la misma rea SQL compartida.
La base de datos automticamente determina cuando las aplicaciones envan sentencias SQL
similares para lo que utiliza tanto las sentencias lanzadas directamente por los usuarios y las
aplicaciones como las sentencias SQL recursivas lanzadas por otras sentencias.
Para ello, se llevan a cabo los siguientes pasos:
l. Comprueba el shared pool para ver si existe una Shared SQL Area para una sentencia
sintcticamente y semnticamente idntica:
Si existe una sentencia idntica, la base de datos utiliza la Shared SQL Area para la
ejecucin de las nuevas instancias de sentencias, reduciendo as el consumo de memoria.
Si no existe ninguna sentencia idntica, la base de datos asigna una nueva Shared SQL Area
en el shared pool.
En cualquier caso, el rea SQL privada del usuario apunta al rea SQL compartida que contiene
la sentencia y el plan de ejecucin.
2. Asigna una Private SQL Area en nombre de la sesin. La ubicacin del rea SQL privada ser la
PGA. (Salvo que sea servidor compartido, en ese caso la parte del rea SQL Privada se mantiene en
la SGA).
Por tanto dos sesiones, que significan dos procesos cliente y dos procesos servidor, pueden lanzar la
misma consulta. El primero provoca que se aloje una copia en su PGA, en el rea de SQL Privada y
al mismo tiempo en el rea SQL Compartida de la Shared Pool. Cuando el segundo landa la misma
consulta, esta ya est en la Shared Pool.
Shared PL/SQL Areas
La cach de librera mantiene todas las formas ejecutables de los programas PL/SQL y las clases
JAVA. Estos elementos se denominan colectivamente unidades de programa y se procesan de forma
similar a las sentencias SQL.
Los procedimientos, funciones, definiciones de tipo de objetos y disparadores se guardan en el
diccionario de datos, tanto en cdigo como compilados. Cuando se invoca un objeto PL/SQL, se lee
del diccionario de datos y se guarda en el rea PL/SQL, de modo que si otra sesin los necesitase ya
se encontrarn en cach. Esto no ocurre con los bloques annimos, que se compilan dinmicamente.
La base de datos procesa las sentencias SQL individuales embebidas dentro de un programa
PL/SQL de la misma manera.

Asignacin y reutilizacin de memoria en el shared pool

La base de datos asigna memoria del shared pool cuando se parsea una nueva sentencia SQL. El
tamao de la memoria depende de la complejidad de la sentencia.
En general, un elemento en el shared pool permanece all hasta que es borrado de acuerdo con un
algoritmo LRU. La base de datos permite que los elementos del shared pool utilizados por varias
sesiones permanezcan en memoria mientras sean tiles, incluso si el proceso que los cre termina.
Este mecanismo minimiza la sobrecarga y el procesamiento de sentencias SQL.
Si se necesita espacio para nuevos elementos, la base de datos libera memoria a costa de los
elementos que menos se usen. Una shared SQL puede eliminarse del shared pool incluso si
corresponde a un cursor abierto si ste no ha sido utilizado durante algn tiempo. Si el cursor
abierto es utilizado posteriormente para ejecutarse Oracle lo reparsea y lo aloja en una nueva Shared
SQL Area.
La base de datos tambin elimina un rea SQL compartida del shared pool en las siguientes
circunstancias:

Si se recopilan estadsticas de la tabla, cluster o ndice, entonces, por defecto, la base de

datos borra gradualmente las shared SQL reas que contienen sentencias que hagan
referencia al objeto analizado durante un cierto perodo de tiempo. La prxima vez que una
sentencia borrada se ejecute, la base de datos la parsear en una Shared SQL Area para
reflejar las nuevas estadsticas de un objeto del esquema.
Si el objeto del esquema se rerferencia en una sentencia SQL, y este objeto se modifica
posteriormente en una sentencia DDL, la base de datos invalida la Shared SQL Area. El
optimizador reparsear la sentencia la prxima vez que se ejecute.
Si cambia el nombre global de la base de datos, sta borrar toda la informacin del shared
pool.

Se puede utilizar la sentencia ALTER SYSTEM FLUSH SHARED POOL para borrar manualmente
el shared pool para verificar las prestaciones que pueden esperarse despus de reiniciar la instancia.
La memoria en el shared pool se asigna segn un algoritmo LRU: cuando Oracle necesite espacio,
sobrescribir el objeto que haya estado ms tiempo sin usarse.
Cach del diccionario de datos
El diccionario de datos es una coleccin de tablas y vistas que contiene informacin de referencia
sobre la base de datos, sus estructuras y sus usuarios. Oracle accede al diccionario de datos
frecuentemente durante el parseo de las sentencias SQL.
Todos los procesos servidores comparten estas cachs para acceder a la infonnacin del diccionario
de datos y reducir el tiempo de parseo.

Cach de resultados del servidor

A diferencia de lo que ocurre con los pools de buffers, la cach de resultados del servidor mantiene
los resultados y no los bloques de datos. Contiene la cach de resultados de sentencias SQL y la
cach de resultados de funciones PL/SQL, que comparten la misma infraestructura:

Cach de resultados de sentencias SQL: la base de datos puede almacenar resultados de

consultas de consultas y utilizarlos para futuras consultas.
Cach de resultados de una funcin PL/SQL: guarda los resultados de funciones PL/SQL
para un valor determinado de los parmetros de entorno. Si la cach contiene el resultado de
invocacin previa de la funcin con los mismos valores de los parmetros, se devuelve el
resultado cacheado. En caso contrario, se ejecuta el cuerpo de la funcin y se aade el
resultado (para estos valores de los parmetros) a la cach antes de devolver el control a
quien lo invoc.

Pool reservado
El pool reservado es una zona de memoria en la memoria compartida que Oracle puede utilizar para
albergar grandes porciones de memoria contigua.

La asignacin de memoria del Shared Pool se lleva a cabo a trozos o chunks. Esta fragmentacin
permite que objetos grandes (ms de 5 kB) se carguen en la cach sin necesidad de solicitar una
nica zona de memoria contigua. De esta manera, la base de datos reduce la posibilidad de
quedarse sin memoria contigua debido a la fragmentacin.
SGA FIJA
La SGA fija es un rea intema de tareas de mantenimiento. Por ejemplo, contiene:
l. Informacin general sobre el estado de la base de datos y de la instancia a la que los procesos de
respaldo necesitan acceder.
2. Informacin comunicada entre procesos.
El tamao de la SGA fija no se puede cambiar manualmente y puede cambiar entre versiones.

GESTION DE MEMORIA
La gestin de memoria implica el mantenimiento de los tamaos ptimos de la estructura de
memoria de Oracle en funcin de los requisitos de la base de datos en cada momento. Oracle
gestiona la memoria basndose en los parmetros de inicializacin.
Las 5 opciones posibles son:
Gestin automtica de memoria (PGA y SGA)
Gestin automtica de SGA con dos opciones: Automtica de PGA o manual de PGA.
Gestin manual de SGA con las dos posibles opciones anteriores.
Gestin dela SGA
La SGA contiene varias estructuras de memoria que se dimensionan de manera independiente:

Shared pool.
Database buffer cach.
Large pool.
Streams pool.
Java pool.
Log buffer.

Como regla general, la asignacin de memoria para el Large pool, el Java pool y el Streams pool no
es negociable. Si estas estructuras estn infradimensionadas, habr errores. Si, por el contrario,
estn sobredimensionadas, no habr mejoras en las prestaciones.
La asignacin de memoria al Shared pool, Database buffer cach y Log buffer es negociable: si es
menor que el valor ptimo, no habr errores, pero disminuirn las prestaciones.
No hay que malgastar memoria innecesariamente. Un shared pool o log buffer sobredimensionados
pueden daar gravemente las prestaciones. Una database buffer cach demasiado grande es menos
problemtico, salvo que sea tan grande que obligue al sistema a realizar demasiados procesos de
intercambio y paginacin de memoria.
Existen dos opciones a la hora de gestionar la SGA:
Gestin automtica de la memoria compartida (ASMM): la base de datos ajusta la SGA a un
tamao objetivo (TARGET) y ajusta as mismo los componentes de la SGA para alcanzar
dicho tamao.
El DBA establece el tamao total de la SGA (SGA_TARGET) y la instancia dividir ese valor
total entre varias estructuras, asegurando que no se producen errores. Se ajustar el tamao de
los componentes de la SGA bajo demanda, para que si un componente necesita ms memoria
pueda ocupar la de otro componente que en ese momento no la est utilizando. El log bufffer
es el nico componente de la SGA al que se le fija un tamao (LOG_BUFFER) durante el
arranque de la instancia y que no puede gestionarse automticamente.

Observemos valores de spfile y los que ofrece al arrancar:

xe.__db_cache_size=167772160
xe.__java_pool_size=4194304
xe.__large_pool_size=4194304
xe.__pga_aggregate_target=209715200
xe.__sga_target=314572800
xe.__shared_io_pool_size=0
xe.__shared_pool_size=130023424
xe.__streams_pool_size=0
*.memory_max_target=1073741824
*.memory_target=524288000
Sin embargo tienen 0, supongo que porque estamos en gestin automtica de
la memoria al poner un valor a memory_target, y no hace caso de los
valores del spfile. Estn aqu, supongo por si hacemos una gestin
manual.
NAME
TYPE
VALUE
------------------------------------ ----------- ------------sga_target
big integer 0
pga_aggregate_target

big integer 0

memory_target

big integer 500M

ORACLE instance started.

Total System Global Area 1071333376 bytes
Fixed Size
1388352 bytes
Variable Size
897581248 bytes
Database Buffers
167772160 bytes
Redo Buffers
4591616 bytes
Database mounted.
Database opened.

Gestin manual de la memoria compartida (MSMM): se establecen los tamaos de los

componentes de la SGA y se ajustan manualnente. Se tiene un control total sobre los tamaos
de los componentes de la SGA individuales.
Los parmetros que se fijan son:
SHARED_POOL_SIZE.
DB_CACHE_SIZE.
LARGE_POOL_SIZE.
STREAMS_POOL_SIZE.
JAVA_POOL_SIZE.
El valor por defecto de LOG_BUFFER es, probablemente correcto. Un valor mayor podra tener un
impacto negativo en el rendimiento, y si se establece un valor menor, se ignorar.

GESTIN DE LA PGA
Una sesin de usuario es un proceso de usuario conectado a un proceso servidor. El proceso de
usuario genera sentencias SQL y las enva al proceso servidor para su ejecucin. Asociado con el
proceso servidor hay un bloque de memoria no compartida: la PGA. Cuando se ejecuta SQL, el
proceso servidor utiliza la PGA para almacenar datos especficos de la sesin, entre los que se
encuentran:

Tablas temporales.
Filas ordenadas.
Mezclas de mapas de bits.
Variables.
Pila.

Para algunos datos de la PGA, la utilizacin de memoria no es negociable. Por ejemplo si la sesin
necesita ms memoria para la pila de llamadas, sta deber estar disponible. Para otras estructuras
(como el almacenamiento de tablas temporales), el empleo de la PGA no es esencial, pero, si es
necesario que los datos se escriban en disco, las prestaciones disminuirn.
Toda sentencia SQL utiliza la memoria de la SGA (ms concretamente, la Shared SQL Area del
shared pool), pero tambin requerir una parte de la PGA (Private SQL Area) sin la cual no puede
ejecutarse. Aumentar la PGA suele tener como consecuencia una reduccin del tiempo de ejecucin,
aunque esta reduccin no es lineal. Generalmente, hay tres etapas en la asignacin de memoria:

Asignacin ptima: permite que la sentencia se ejecute completamente en memoria, sin

ningn requerimiento de almacenamiento temporal en disco. Es suficiente para acomodar
todos los datos de entrada y los datos auxiliares que la sentencia debe crear.
Asignacin one-pass: es insuficiente para la ejecucin ptima y, por tanto, fuerza un paso
extra sobre los datos.
Asignacin multipass: es todava ms pequea y significa que sern necesarias varias
pasadas sobre los datos.

Por ejemplo, supongamos una operacin de ordenacin. Si la asignacin ptima no est disponible,
ser necesario dividir las filas en lotes, cada uno de los cuales ser ledo, ordenado y escrito en
disco para luego ser mezclados los resultados parciales de cada lote con el fin de conseguir el
resultado final.

La situacin ideal es que todas las sentencias SQL se ejecuten de manera ptima, pero,
desgraciadamente, es un objetivo imposible de alcanzar.
Oracle recomienda la gestin automtica de la PGA, que consiste en establecer un objetivo para la
memoria de PGA total (PGA_AGGREGATE_TARGET). Cuando una sesin ha terminado de
ejecutar su sentencia, la PGA que estaba utilizando podr asignarse a otra sesin. Este sistema se
basa en el hecho de que, en cualquier momento, solo habr conectadas un cierto nmero de sesiones
que necesitarn una PGA negociable, aunque es cierto que necesitarn una cierta cantidad de PGA
para mantener el estado de la sesin, aunque sta est inactiva.
En ocasiones, resulta imposible conseguir las asignaciones de memoria ptimas porque los
requisitos pueden ser enormes. Las ejecuciones one-pass son perjudiciales y deben evitarse. Las
ejecuciones multipass son desastrosas y, si ocurren, es recomendable ajustar el hardware y las
sentencias SQL.
La gestin automtica de la memoria PGA se basa en dos parmetros:

WORKAREA_SIZE_POLICY: si el valor por defecto es AUTO, lo que indica que Oracle

puede asignar PGA a las sesiones bajo demanda, siempre y cuando se respete el tamao
objetivo de la PGA marcado por el parmetro PGA_AGREGATE_TARGET.
PGA_AGGREGATE_TARGET: indica el tamao objetivo para la PGA de la instancia. La
base de datos ajusta el tamao de la instancia de la PGA a este objetivo y ajusta
dinmicamente los tamaos de los componentes individuales de la PGA. Si no se establece
explcitamente un tamao objetivo, la base de datos configura un valor razonable por
defecto, que suele ser mayor de 10 MB o el 20% del tamao de la SGA.

En algunos sistemas, el PGA_AGGREGATE_TARGET por defecto ser demasiado bajo para un

rendimiento ptimo. Algunos DBA suelen fijarlo al mismo tamao que la SGA y empiezan a ajustar
desde este valor.
Cuando la gestin automtica de memoria est deshabilitada y el PGA_AGGREGATE_TARGET es
cero, la base de datos funciona en gestin manual de la PGA. Aunque Oracle soporta la gestin
manual de la PGA, se recomienda utilizar la gestin automtica.

GESTIN AUTOMATICA DE MEMORIA

En la gestin automtica de memoria, Oracle gestiona la SGA y la PGA de la instancia de una
manera completamente automtica. Este mtodo es el ms simple y el recomendado por Oracle.
El nico parmetro especificado por el usuario es el tamao objetivo de la memoria
(MEMORY_TARGET) y, opcionalmente, el tamao mximo de la memoria
(MEMORY_MAX_TARGET). Oracle se ajusta al tamao objetivo de la memoria,
redistribuyendo la memoria entre la SGA y la PGA de la instancia dinmicamente.
Si una base de datos en ocasiones procesa trabajos enviados por usuarios on-line y otras veces
trabajos por lotes. Utilizando la gestin automtica de memoria, la base de datos ajusta
automticamente y en cada momento el tamao de Large pool y la Database Buffer cach
dependiendo del tipo de trabajos que se estn ejecutando.
La gestin automtica de memoria se habilita para permitir la transferencia entre la SGA y la PGA y
optimizar las prestaciones respetando una restriccin de memoria global.
Para habilitar la gestin automtica de memoria hay que establecer el parmetro
MEMORY_TARGET. No es necesario fijar ningn otro parmetro, con la excepcin del
LOG_BUFFER, aunque este puede dejarse en el valor por defecto.
El parmetro MEMORY_TARGET es dinmico (puede ajustarse sin necesidad de parar la
instancia), pero hay un lmite establecido por el parmetro MEMORY_MAX_TARGET. Este
ltimo es esttico, as que solo puede ser ajustado con la clusula SCOPE=SPFILE y reiniciando la
instancia.

RESUMEN DE LOS METODOS DE GESTIN DE MEMORIA

La tabla resume los distintos tipos de gestin de memoria. Si no habilita la gestin automtica de
memoria, debe configurar un mtodo de gestin de la SGA y un mtodo de gestin de la PGA.
Instancia SGA

PGA

Descripcin

Parmetros

Auto

N/A

N/A

La base de datos gestiona el tamao

de la instancia a partir de un nico
tamao objetivo de la instancia.

MEMORY_TARGET
MEMORY_MAX_TARGET

N/A

Auto

Auto

La base de datos gestiona la SGA

basndose en un objetivo de SGA.

SGA_TARGET
SGA_MAX_SIZE
PGA_AGGREGATE_TARGET

La base de datos gestiona la PGA

basndose en un objetivo de PGA

N/A

Auto

Manual La base de datos gestiona la SGA

basndose en un objetivo de SGA.

SGA_TARGET
SGA_MAX_SIZE

El usuario controla la PGA de forma

manual, estableciendo un tamao
mximo de rea de trabajo para cada
tipo de sentencia SQL.

Parmetros de reas de trabajo PGA

como:
SORT_AREA_SIZE
HASH_AREA_SIZE
BITMAP_MERGE_AREA_SIZE

El usuario controla de forma manual

el tamao de los componentes de la
SGA
La base de datos gestiona la PGA
basndose en un objetivo de PGA.

SHARED_POOL_SIZE
DB_CACHE_SIZE
LARGE_POOL_SIZE
JAVA_POOL_SIZE
STREAMS_POOL_SIZE
PGA_AGGREGATE_TARGET

N/A

Manual Auto

N/A

Manual Manual El usuario controla de forma manual

el tamao de los componentes de la
SGA

El usuario controla la PGA de forma

manual, estableciendo un tamao
mximo de rea de trabajo para cada
tipo de sentencia SQL.

SHARED_POOL_SIZE
DB_CACHE_SIZE
LARGE_POOL_SIZE
JAVA_POOL_SIZE
STREAMS_POOL_SIZE
Parmetros de reas de trabajo PGA
como:
SORT_AREA_SIZE
HASH_AREA_SIZE
BITMAP_MERGE_AREA_SIZE

MEMORY ADVISORS (Esto no se ver por ahora pero si los cambios de

parmetros)
La instancia de Oracle recoge una gran cantidad de informacin relativa a la actividad y las
prestaciones. Estas estadsticas se acumulan en memoria hasta que el MMON las vuelca en el AWR
peridicamente. La disponibilidad de estadsticas permite habilitar los advisors (asesores) de
memoria, que son herramientas que calculan el efecto de variar los tamaos de las estructuras de la
SGA y la PGA. La gestin automtica de memoria utiliza estos advisors para tomar las decisiones
sobre la asignacin de memoria, pero tambin estn disponibles para el DBA a travs de
varias vistas y del Enterprise Manager.
Por ejemplo, la siguiente consulta muestra la informacin recogida por el PGA advisor. La tercera
columna muestra una estimacin de la cantidad de E/S en disco necesaria si el objetivo de PGA
(PGA_AGGREGATE_TARGET) se estableciera al valor mostrado en la primera columna. La
segunda columna muestra esta estimacin como una proporcin respecto a la configuracin actual.
Es decir, PGA_TARGET_FOR_ESTIMATE / Valor actual de PGA_AGGREGATE_TARGET.
La quinta fila muestra informacin sobre la configuracin actual (PGA_TARGET_FACTOR de l).
Como vemos, no es necesario incrementar el valor de PGA_AGGREGATE_TARGET, ya que no
obtenemos una mejora en E/O. Es ms, podramos incluso reducirlo a la estimacin propuesta en la
fila 4, ya que mantenemos una valor ESTD_EXTRA_BYTES_RW igual a cero.
SELECT pga_target_for_estimate, pga_target_factor,
estd_extra_bytes_rw
FROM v$pga_target_advice;
PGA_TARGET_FOR_ESTIMATE PGA_TARGET_FACTOR ESTD_EXTRA_BYTES_RW
----------------------- ----------------- ------------------54001664
0.125
6537216
108003328
0.25
0
216006656
0.5
0
324009984
0.75
0
432013312
1
0
518415360
1.2
0
604818432
1.4
0
691220480
1.6
0
777623552
1.8
0
864026624
2
0
1296039936
3
0
1728053248
4
0
2592079872
6
0
3456106496
8
0
14 filas seleccionadas

El siguiente ejemplo muestra la informacin proporcionada por el SGA advisor. En concreto,

relaciona el tamao de la SGA con un valor estimado para DB_TIMA , que indica el tiempo que
necesita la base de datos para ejecutar sentencias SQL. Minimizar el valor de DB_T IME debe ser
el objetivo de cualquier configuracin. En el ejemplo puede verse que si aumentamos el valor de la
SGA por encima de 612 Mb (valor actual) no conseguimos ninguna disminucin (DB_T IME est
expresado en microsegundos).
SELECT SGA_SIZE, SGA_SIZE_FACTOR, ESTD_DB_TIME
FROM V$SGA_TARGET_ADVICE;
SGA_SIZE SGA_SIZE_FACTOR ESTD_DB_TIME
---------- --------------- -----------153
0.25
396
306
0.5
316
459
0.75
316
612
1
316
765
1.25
316
918
1.5
316
1071
1.75
316
1224
2
316
8 filas seleccionadas

El siguiente ejemplo muestra la informacin proporcionada por el advisor de objetivo de memoria.

Este advisor informa acerca de la gestin total de memoria (SGA ms PGA). Podemos ver como la
memoria asignada actualmente es suficiente para alcanzar el valor optimo. Los incrementos de
memoria estimados por el advisor reflejan que no reduciramos el DB_TIME. De hecho, podramos
incluso reducir el tamao de memoria hasta 512 MB sin que haya ningn impacto.
SELECT MEMORY_SIZE, MEMORY_SIZE_FACTOR, ESTD_DB_TIME
FROM v$memory_target_advice;
MEMORY_SIZE MEMORY_SIZE_FACTOR ESTD_DB_TIME
----------- ------------------ -----------256
0.25
383
512
0.5
317
768
0.75
317
1024
1
317
1280
1.25
317
1536
1.5
317
1792
1.75
317
2048
2
317
8 filas seleccionadas

Los advisor no se habilitarn, salvo que el parmetro STATISTIS_LEVEL tenga el valor TYPICAL
o ALL.
SQL*Plus: Release 11.2.0.2.0 Production on Dom Sep 22 09:42:37
2013
Copyright (c) 1982, 2010, Oracle.

All rights reserved.

SQL> conn / as sysdba

Connected.
SQL> show parameters statistics_level;
NAME
TYPE
VALUE
------------------------------------ ----------- -------------statistics_level
string
TYPICAL
SQL>
Pruebas:
SQL> show parameters memory_target
NAME
TYPE
VALUE
------------------------------------ ----------- ------------memory_target
big integer 1G
SQL> show parameters memory_max_target
NAME
TYPE
VALUE
------------------------------------ ----------- ------------memory_max_target
big integer 1G
SQL> show parameters sga_target
NAME
TYPE
VALUE
------------------------------------ ----------- --------------sga_target
big integer 0
Como vemos estamos haciendo una gestin automtica de memoria.

SQL> show sga

Total System Global Area 1071333376 bytes
Fixed Size
1388352 bytes
Variable Size
645923008 bytes
Database Buffers
419430400 bytes
Redo Buffers
4591616 bytes
(El siguiente parmetro no necesita detener la base de datos, es dinmico, observar que se cambia
en el spfilexe.ora, con lo que queda cambiado permanentemente)
SQL> ALTER SYSTEM SET MEMORY_TARGET=500M;
System altered.
-- del spfilexe.ora:
*.dispatchers='(PROTOCOL=TCP) (SERVICE=XEXDB)'
*.job_queue_processes=4
*.memory_target=524288000
*.open_cursors=300
*.remote_login_passwordfile='EXCLUSIVE'

SQL> show sga

Total System Global Area 1071333376 bytes
Fixed Size
1388352 bytes
Variable Size
792723648 bytes
Database Buffers
272629760 bytes
Redo Buffers
4591616 bytes
SQL>
NAME
TYPE
VALUE
------------------------------------ ----------- -----------memory_target
big integer 500M
SQL>
SELECT MEMORY_SIZE, MEMORY_SIZE_FACTOR, ESTD_DB_TIME
FROM v$memory_target_advice;
MEMORY_SIZE MEMORY_SIZE_FACTOR ESTD_DB_TIME
----------- ------------------ -----------500
1
338
625
1.25
338
750
1.5
338
875
1.75
338
1000
2
338

ATENCIN: Al cambiar el memory_target ha cambiado al iniciar el

memory_max_target. Lo restituiremos:
SQL> alter system set memory_max_target=1G scope=spfile;
System altered.
Ha aadido la lnea:
*.memory_max_target=1073741824
en el spfilexe.ora
Pero an no en:
NAME
TYPE
VALUE
------------------------------------ ----------- ------------------memory_max_target
big integer 500M
SQL>
Despus de hacer shtdown y startup:
SQL> shutdown
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORACLE instance started.
Total System Global Area 1071333376 bytes
Fixed Size
1388352 bytes
Variable Size
864026816 bytes
Database Buffers
201326592 bytes
Redo Buffers
4591616 bytes
Database mounted.
Database opened.
SQL> show parameters memory_max_target;
NAME
TYPE
VALUE
------------------------------------ ----------- ------------------memory_max_target
big integer 1G
NAME
TYPE
VALUE
------------------------------------ ----------- -----------------memory_max_target
big integer 1G
SQL> alter system set memory_target=1G;
System altered.
Esto, por ser dinmico deja alterada el parmetro para los prximos
arranques:
*.memory_max_target=1073741824
*.memory_target=1073741824

PRACTICAS:

Ver el tamao de la SGA de la BD y las cachs que la componen.

Hay varias vistas dinmicas de la BD que nos dan informacin sobre el tamao y la estructura
de la SGA: V$SGAINFO, V$SGA_DYNAMIC_COMPONENTS,
V$MEMORY_DYNAMIC_COMPONENTS
La columna RES de resizeable, es Yes para aquellas partes de la SGA cuyo tamao es gestionado
automticamente por oracle.
SQL> select * from v$sgainfo;
NAME
BYTES RES
-------------------------------- ---------- --Fixed SGA Size
1388352 No
Redo Buffers
4591616 No
Buffer Cache Size
163577856 Yes
Shared Pool Size
134217728 Yes
Large Pool Size
4194304 Yes
Java Pool Size
4194304 Yes
Streams Pool Size
0 Yes
Shared IO Pool Size
0 Yes
Granule Size
4194304 No
Maximum SGA Size
1071333376 No
Startup overhead in Shared Pool
67108864 No
NAME
BYTES RES
-------------------------------- ---------- --Free SGA Memory Available
759169024
12 rows selected.
(La vista V$MEMORY_DYNAMIC_COMPONENTS permite ver como Oracle reparte
toda la memoria (SGA y PGA), detallando las partes que forman la SGA)
SQL> select COMPONENT, CURRENT_SIZE from v$memory_dynamic_components;
COMPONENT
CURRENT_SIZE
---------------------------------------------------------------- -----------shared pool
134217728
large pool
4194304
java pool
4194304
streams pool
0
SGA Target
314572800
DEFAULT buffer cache
163577856
KEEP buffer cache
0
RECYCLE buffer cache
0
DEFAULT 2K buffer cache
0
DEFAULT 4K buffer cache
0
DEFAULT 8K buffer cache
0
DEFAULT 16K buffer cache
0
DEFAULT 32K buffer cache
0
Shared IO Pool
0
PGA Target
209715200
ASM Buffer Cache
0
16 rows selected.

Consultar informacin sobre la base de datos (v$database) y la instancia (v$instance).

SQL> select name, created, log_mode, checkpoint_change#, open_mode, platform_n
e, current_scn from v$database;
NAME
CREATED LOG_MODE
CHECKPOINT_CHANGE# OPEN_MODE PLATFORM_NAME
CURRENT_SCN
-------------------------------------------------------------------------------------------------XE
17/09/13 NOARCHIVELOG
990635
READ WRITE Microsoft Windows IA (32-bit) 995604

SQL> select instance_name,host_name,version,startup_time,

2 status,archiver,logins,database_status from v$instance;
INSTANCE_NAME HOST_NAME
VERSION
STARTUP_ STATUS
ARCHIVE
LOGINS
----------------- -------- ------------ ------- ---------- ----------------xe
ADOLFO-PC
11.2.0.2.0
10/10/13 OPEN
STOPPED
ALLOWED

DATABASE_STATUS
ACTIVE