Captulo II Explorando la arquitectura de la base de datos

Arquitectura Instancia Simple(Single Instance Arquitecture)

Un sistema de base de datos Oracle consta de 2 partes, la base de datos en s y una instancia de la base de datos.
La base de datos consta de estructuras fsicas y lgicas, mientras que la instancia consta de estructuras de memoria
y de procesos asociados con dicha instancia.

Cada vez que se arranca una instancia, se reserva un espacio de memoria (SGA) y se arrancan una serie de
procesos. Despus de arrancar la instancia de la base de datos, el software de la base de datos se encarga de
asociarla con una base de datos especfica, lo que se denomina montar la base de datos. A partir de este momento
la base de datos est lista para ser abierta, lo que permite a los usuarios conectarse a ella.

Estructura de la memoria
Como comentbamos anteriormente, una instancia de base de datos consta de un rea de memoria y una serie de
procesos que se hacen llamar procesos de background. Cada vez que una instancia se levanta, se reserva un rea
de memoria denominada SGA (System Global Area), y se ejecutan los procesos asociados.

Existen 2 estructuras bsicas de memoria en una instancia de base de datos:

System Global Area (SGA): Esta estructura de memoria es una memoria compartida, ya que tanto el servidor
como los procesos de background tienen acceso a dicha rea de memoria.
Program Global Area (PGA): Esta regin de memoria es una memoria privada, que solo es accesible por los
procesos del servidor o de background. La PGA por tanto no es una memoria compartida, cada proceso tiene su
propia PGA.
 SGA
Database Buffer Cache: Como sabemos Oracle trabaja con bloques de datos (mnima cantidad de informacin que
almacena Oracle y que por defecto suelen ser 8 kb) y no con filas. 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 sentencias DML (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.
 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 denominada User 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.

Estructura de los procesos

System Monitor (SMON):

Tiene asignada la tarea de abrir la base de datos.
Valida que los datos que se dan en el controlfile sean correctos
Se encarga de localizar espacio libre en los datafiles para guardar ms datos.

Process Monitor (PMON)

Se encarga de localizar problemas con los procesos de servidor.
Si alguno de estos procesos falla, el PMON se encarga de destruir el proceso de servidor y liberar
la memoria que ocupa.

Database Writer (DBWn)

Los procesos de servidor no escriben directamente sobre los ficheros de datos, sino en la database
buffer cache.
Es el Database Writer el encargado de escribir a disco estos datos.
Una instancia puede tener ms de un DBWn funcionando. A cada uno se les llama: DBW0, DBW1,
etc.
Con DBWn nos referimos a todos los Database Writer que hayan.
El nmero de DBWn que suelen haber es 1 por cada 8 CPUs aproximadamente.

Log Writer (LGWR)

Este proceso es el encargado de escribir los cambios que hay en el log buffer a los log files de
disco.
Como los procesos de servidor escriben los cambios en el log buffer de memoria y, la memoria
puede borrarse, el objetivo es que el LGWR escriba estos datos en los log files lo antes posible.
Es uno de los cuellos de botella de la arquitectura de Oracle.

Checkpoint process (CKPT)

Va asignando checkpoints dentro de los buffers de cambio, para poder recuperar la base de datos
en caso de fallo.

Manageability Monitor (MMON)

MMON se dedica a capturar estadsticas del funcionamiento de la base de datos y las almacena
en el diccionario de datos.
Con esta informacin, la herramienta ADDM (Automatic Database Diagnostic Monitor) da
recomendaciones sobre cmo mejorar el rendimiento de Oracle.

Manageability Monitor Light (MMNL)

Es un proceso que sirve de ayuda al MMON.

Memory Manager (MMAN)

 Gestiona la memoria de la SGA y la PGA.
Permite que se puedan hacer redimensionamientos de memoria con la base de datos en marcha.

Archiver (ARCn) y Recoverer Process (RECO)

Estructura de la base de Datos

Estructura fsica de la base de datos:

Ficheros de datos: contienen los datos reales de la base de datos. Los datos se almacenan en tablas definidas por el
usuario, pero tambin contienen el diccionario de datos, ndices y otros tipos de estructuras.
Los ficheros de datos tienen las siguientes caractersticas:
o Un fichero de datos exclusivamente est asociado con una sola base de datos Oracle.
o Uno o ms ficheros de datos forman una unidad lgica de almacenamiento de base de datos llamada tablespace.
Ficheros Redo Log: contienen los cambios efectuados en la base de datos para poder recuperar ante fallos.
Los ficheros de Control, contienen la informacin necesaria para mantener y verificar la integridad de la base de datos.
Por ejemplo, un fichero de control se usa para identificar los ficheros de datos y redo log. Una base de datos Oracle
necesita al menos un fichero de Control.
Una instancia slo podr abrir y utilizar una base de datos a la vez, aunque una base de datos podra ser utilizada por
varias instancias, como ocurre en el sistema de alta disponibilidad de Oracle Real Application Cluster (RAC).

Estructura lgica de la base de datos:

Un administrador debe conocer las estructuras fsicas y las lgicas.

El programador trabaja con estructuras lgicas, como por ejemplo, tablas.
Una tabla tiene asociado:
filas con la informacin
ndices. Son un mecanismo para acceder ms rpidamente a la informacin.
Informacin de undo. Por si queremos que la tabla vuelva a un estado anterior.
Toda esta informacin, se dice que se guarda en segmentos.

Un tablespace es

A nivel lgico, un conjunto de segmentos. Por lo que puede contener varias tablas.
A nivel fsico, uno o ms datafiles. Una tabla puede estar distribuida en uno o ms
datafiles.
En un datafile pueden haber datos de ms de una tabla.

Al instalar Oracle, se crean tambin una serie de segmentos que forman el diccionario de datos.
Estos segmentos se guardan en 2 tablespaces:

SYSTEM
SYSAUX
Cada uno de estos tablespace tienen un datafile asignado.

Un segmento, a su vez, est formado por una serie de bloques. Los datafiles tienen un formato
basado en bloques. Los segmentos tienen una serie de bloques asignados. Como gestionar el
espacio de bloque en bloque puede ser muy costoso, los bloques que van seguidos se agrupan en
extents.
DICCIONARIO DE DATOS
 Se almacena en el conjunto de segmentos que forman los tablespaces de SYSTEM y SYSAUX.

Los datos que almacena son una descripcin de los contenidos fsicos y lgicos que tiene la base
de datos: Definicin de usuarios Informacin de seguridad Restricciones de integridad Etc.
No podemos acceder al diccionario de datos directamente, a no ser que nos conectemos como
usuario DBA. Si hacemos modificaciones directamente sobre el diccionario de datos, podemos
daar de forma irreparable la base de datos y Oracle no nos dara soporte.
Oracle, sin embargo, nos proporciona una serie de vistas con las que podemos consultar alguna
informacin. Estas vistas empiezan por: DBA_, ALL_ o USER_. Por ejemplo, si nos
conectamos como HR y hacemos select * from user_tables, tendremos todas las tablas que son
propiedad de este usuario.