Una base de datos en ejecucin consta de 3 cosas:

Archivos
o Control (ctl): almacenan informacin acerca de la
estructura de archivos de la base.
o Rollback (rbs): cuando se modifica el valor de alguna
tupla en una transaccin, los valores nuevos y
anteriores se almacenan en un archivo, de modo que
si ocurre algn error, se puede regresar (rollback) a
un estado anterior.
o Redo (rdo): bitcora de toda transaccin, en muchos
dbms incluye todo tipo de consulta incluyendo
aquellas que no modifican los datos.
o Datos (dbf): el tipo ms comn, almacena la
informacin que es accesada en la base de datos.
o Indices (dbf) (dbi): archivos hermanos de los datos
para acceso rpido.
o Temp (tmp): localidades en disco dedicadas a
operaciones de ordenamiento o alguna actividad
particular que requiera espacio temporal adicional.
Memoria
o Shared Global Area (SGA): es el rea ms grande de
memoria y quizs el ms importante
Shared Pool: es una cach que mejora el
rendimiento ya que almacena parte del
diccionario de datos y el parsing de algunas
consultas en SQL
Redo Log Buffer: contiene un registro de todas
las transacciones dentro de la base, las cuales
se almacenan en el respectivo archivo de Redo y

en caso de siniestro se vuelven a ejecutar

aquellos cambios que an no se hayan reflejado
en el archivo de datos (commit).
Large Pool: espacio adicional, generalmente
usado en casos de multithreading y esclavos de
I/O.
Java Pool: usado principalmente para almacenar
objetos Java
o Program Global Area (PGA): informacin del estado de
cursores/apuntadores
o User Global Area(UGA): informacin de sesin,
espacio de stack

Procesos
o Threading
o System Monitor: despierta peridicamente y realiza
algunas actividades entre las que se encuentran la
recuperacin de errores, recuperacin de espacio libre
en tablespaces y en segmentos temporales.
o Process Monitor: limpia aquellos procesos que el
usuario termina de manera anormal, verificando
consistencias, liberacin de recursos, bloqueos.
o Database Writer: escribe bloques de datos
modificados del buffer al disco, aquellas
transacciones que llegan a un estado de commit.
o Log Writer: escribe todo lo que se encuentra en el
redo log buffer hacia el redo file
o Checkpoint: sincroniza todo lo que se tenga en
memoria, con sus correspondientes archivos en disco

SGA
Database Buffer Cache: En esta parte de memoria se almacenan imgenes de los bloques de datos fsicos
(de disco) utilizados para realizar consultas o que han sido modificados por una sentencia. Siempre que un
proceso necesite una determinada informacin buscar dichos datos en el Database Buffer Cache. Si
encuentra la informacin aqu podr leer los datos directamente desde memoria (cache hit). Si por lo
contrario, el proceso no encuentra la informacin solicitada en el buffer, tendr que hacer un acceso a disco y
traerse los bloques de datos necesarios a memoria. (cache miss). Cuando Oracle modifica los datos, lo hace
directamente sobre el Database Buffer Cache. Estos bloques modificados se denominan bloques sucios o
Dirty Blocks. La actualizacin de los bloques en el Database Buffer Cache se realiza por el algoritmo LRU.
Redo Log Buffer: El Redo Log Buffer se podra definir como una bitcora. Esta parte de la memoria acta
como un buffer circular y es donde se registrarn todos los cambios que se produzcan en la base de datos,
entendiendo por cambios la ejecucin de las sentenciasDML (Insert, Update, Delete, Merge) y DDL
(Create, Alter, Drop, Truncate). Estas entradas de redo se almacenarn por si fuese necesario una
recuperacin de la base de datos. Segn los procesos vayan haciendo cambios, se irn generando nuevas
entradas de redo que se irn escribiendo en la SGA. Estas entradas se irn almacenando de forma secuencial

en el buffer y ser el proceso de background Log Writer (LGWR) el que se encargar de escribir esta
informacin en el fichero fsico de log de redo.
Shared Pool: El rea de memoria que comprende la Shared Pool contiene la library cache, el data
dictionary cache y el result cache.
El data dictionary cache es una especie de metadatos de la base de datos, es en definitiva una coleccin de
tablas y vistas que contienen informacin de la base de datos, sus estructuras y sus usuarios. Es una zona
bastante accedida de la base de datos.
Otra rea es la library cache. Es sin duda otra zona bastante concurrida de la base de datos. Oracle
representa cada sentencia SQL que se ejecuta con una zona SQL compartida, con lo que Oracle es capaz de
reconocer cuando 2 usuarios ejecutan la misma sentencia, y as poder reutilizar la misma rea para ambos
usuarios. Esta zona de memoria compartida contiene el plan de ejecucin, con lo que Oracle ahorra memoria
utilizando la misma rea para las sentencias que se ejecutan en mltiples ocasiones.
En la result cache se almacenan filas y no bloques. En este rea por ejemplo podemos guardar listas de
valores muy utilizadas. Para ello tendremos que definir un tipo de Hint especial en nuestras consultas que
hagan que los resultados obtenidos se almacenen en esta cache.
Large Pool: Esta zona es opcional. El administrador del sistema puede configurarla siempre que quiera
reservar memoria para realizar operaciones de backup o recuperacin de la base de datos o consultas en
paralelo.
Java Pool: Esta zona se utiliza para almacenar cdigo Java almacenado y datos de la JVM. Es a partir de
la versin 8i de Oracle a partir de la cual tenemos disponible esta caracterstica.
Stream Pool: Zona de memoria utilizada para almacenar Oracle Streams. Normalmente se usa en la
configuracin de Data Guards (Replicaciones de datos, donde a partir de este buffer se ir enviando datos a
una base de datos secundaria). A menos que se haya configurado, el tamao de esta zona de memoria ser
de 0 kb.
Keep, Recyble Pools: Estas zonas de memorias son similares a la Database Buffer Cache, pero se difieren
en que son diseados para mantener la informacin ms o menos tiempo de lo que la retendra el algoritmo
LRU.
Con la infraestructura dinmica de la SGA, el tamao de los buffers puede ser alterado sin parar la base de
datos. La base de datos utiliza una serie de parmetros de inicializacin para crear y manejar las estructuras

de memoria. La manera ms simple de controlar la memoria de la base de datos es dejar a la base de datos
que lo haga de forma automtica. Para conseguirlo, lo nico que tendremos que hacer es establecer 2
parmetros de configuracin: MEMORY_TARGET y MEMORY_MAX_TARGET.

PGA
La Program Global Area, es una regin privada de memoria que contiene datos e informacin de control de
los procesos del servidor. Cada proceso tiene su propia PGA, y el acceso a dicha informacin es totalmente
exclusivo.
En un servidor dedicado, cada proceso tendr un espacio de pila y una zona denominadaUser Global
Area (UGA). En un servidor compartido, en el cual mltiples usuarios comparten el mismo proceso servidor,
ste solo tendr el espacio de pila, mientras que la UGA se almacenar en la SGA.
En la UGA nos encontraremos con la siguiente informacin:

Cursores abiertos

Informacin de la sesin (quien eres, el rol que tienes)

reas de trabajo SQL: Consistentes en la realizacin de varias operaciones SQL, como la

ordenacin de las consultas (ORDER BY, GROUP BY). En este ejemplo, en el caso de no haber suficiente
espacio para llevar a cabo dicha operacin esta informacin ser llevada a disco

Si bien el otro da hablaba sobre la arquitectura de una base de datos Oracle, solo tratamos en profundidad la
arquitectura de la memoria. Hoy tratar de explicaros la arquitectura de los procesos. En primer lugar vamos a
establecer una agrupacin de los procesos en 3 grupos:

Procesos de Usuario: Aplicacin o herramienta que se conecta con la base de datos de Oracle

Procesos de Base de Datos:

Donde nos podemos encontrar con los procesos servidores

(aquellos que conectan las aplicaciones con las instancias de base de datos y que se ejecutan cuando se
establece una conexin) y con los procesos de Background (Comienzan cuando se arranca una
instancia).

Demonios: Listeners y Grid

Cuando un usuario ejecuta una aplicacin, como pudiera ser el SQL *Plus o el PL/SQL Developer, est
haciendo correr lo que se denomina un proceso de usuario. Este proceso que puede estar o no en la
misma mquina donde se encuentra la base de datos se conectar en primer lugar a un Listener el cual
crear un proceso servidor que ser el encargado de ejecutar los comandos indicados por el proceso de
usuario. Adems de estos procesos, Oracle cuenta con una serie de procesos, llamados procesos de
background que pertenecen a cada instancia, los cuales interactan entre ellos y con el sistema operativo
para manejar las estructuras de memoria, escribir informacin en disco, y realizar otro tipo de tareas como
veremos ms adelante.
Los procesos servidores son los encargados de realizar las siguientes tareas:

Analizar y ejecutar sentecias SQL transmitidas por el proceso de usuario.

Se encarga de buscar en la Database Buffer Cache (SGA) los bloques necesarios, o de

recuperarlos de los data files (de disco) si no se encuentran en el buffer.

Devolver al proceso la informacin solicitada.

En cuanto a los procesos de background, nos podemos encontrar con los siguientes:

Database write process (DBWn): Se encarga de escribir los bloques sucios del Database Buffer
Cache a disco.

Log writer process (LGWR): Se encarga de transferir la informacin del Redo Log Cache a los
ficheros fsicos de REDO.

Checkpoint process (CKPT): Sincroniza el fichero de control con las cabeceras de los data files.

System monitor process (SMON): Es el monitor del sistema. Monitoriza el sistema, recupera la
instancia si fuera necesario.

Process monitor process (PMON): Es el monitor de procesos. Controla las sesiones, mata las
sesiones que considera, y se encarga del registro dinmico del Listener.