Arquitectura de una Base de Datos Oracle

La Arquitectura de la Base de Datos Oracle

El Oracle Server consiste en dos entidades:

• La Instancia: Es un conjunto de Procesos y Estructuras de Memoria.
• La Base de Datos: Es un conjunto de Archivos en Disco.

Durante la creación, se crea primero la instancia y después la Base de Datos. Es decir, primero se levanta la instancia y posteriormente se abre la Base de Datos.

Las estructuras lógicas (tablas, índices, etc) no están directamente conectadas con las estructuras físicas (archivos).

La instancia consiste en un conjunto de procesos y estructuras de memoria que existen en la RAM y en el CPU. Cuando se apaga la instancia, ambos procesos y estructuras de memoria terminan de ejecutarse al mismo tiempo, mientras la Base de Datos prevalece en disco.

A pesar de que la instancia vive en memoria, puede ser detenida o iniciada. En cambio, la Base de Datos persiste indefinidamente hasta que se borren los archivos del disco.

Los procesos que hacen la instancia son llamados Background Process. Las estructuras de memoria son implementadas en segmentos de memoria compartida proveídas por el Sistema Operativo. Esta área de memoria compartida se conoce como SGA (System Global Area).

A los procesos de servidor también se les conoce como Foreground Process. A cada proceso de servidor se le asocia con una PGA (Program Global Area).

Un PGA es un área de memoria no compartida. Es decir un área de memoria privada a la cual solo puede accesar el proceso de servidor a la cual está asociado.

Las sesiones consisten de un proceso de usuario que corre localmente en el ordenador del usuario ligado a un proceso de servidor que corre localmente en el servidor.

Las estructuras físicas que conforman a una base de datos se llaman:

• Data Files
• Control File
• Redo Logs

La Base de Datos garantiza completa abstracción entre las estructuras físicas y las estructuras lógicas. Es decir, no hay manera en que se pueda saber en qué bit yace que información.

Los datos se guardan en los datafiles, es decir que estos ficheros son como un banco de información que no tiene límite en tamaño. La abstracción se refiere a que los archivos físicos podrían moverse, cambiar de tamaño, etc. Y los usuarios no se enterarían.

La relación entre las estructuras físicas y lógicas se mantiene y documenta en el Diccionario de Datos, ya que este contiene los metadatos que describen a toda la Base de Datos.

El redo log es un archivo que contiene todos los change vectors. Un change vector es una alteración hecha por un comando DML.

Cuando una sesión efectúa cambios en la información, la información en los data blocks cambia y el vector change se escribe el el redo log.

Entonces, cuando se daña un datafile, Oracle extraerá los vectores relevantes del redo log y los aplicará en los bloques.

Los Control Files guardan información acerca de las estructuras de la Base de Datos.

Cuando una instancia abre alguna Base de Datos, primero abre el Control File. En el Control File se encuentra la información para que la instancia se pueda conectar a la Base de Datos y al Diccionario de Datos.

Es imposible para cualquier proceso de usuario tener contacto con la Base de Datos, todos los accesos deben ser mediados por los procesos del servidor.

En un ambiente de una sola instancia, una sola instancia abre la Base de Datos, mientras que en un ambiente distribuido existen varias maneras de agrupar las instancias con las Bases de Datos.

Ejemplos de Sistemas Distribuidos:

• Real Application Clustering
• Streaming
• Data Guard

Una instancia consiste en un bloque de memoria compartida conocida como SGA y un conjunto de procesos BackGround.

Existen como mínimo 3 estructuras de memoria en el SGA:

• Database Buffer Cache
• Log Buffer
• Shared Pool

Las sesiones de usuario también necesitan memoria en el servidor. Esta memoria privada se conoce como PGA. Entonces así, cada sesión tendrá su propio PGA.

El Database Buffer Cache, se encarga de ejecutar SQL. Cuando se hace una operación DML, se toman los data blocks que contienen la información solicitada y se copian al Database Buffer Cache. Posteriormente, los cambios son aplicados a las copias de los data blocks que se encuentran en el Database Buffer Cache.

Cuando se requiere consultar información, los datos también son procesados a través del cache. La sesión obtiene los data blocks que contienen la información de interés y los copia al Database Buffer Cache; los registros relevantes son posteriormente transferidos al PGA de la sesión para un procesamiento próximo.

 Cabe decir que estos bloques se mantendrán en el buffer por cierto tiempo. Todos los datafiles, están formateados en data blocks, mientras el Database Buffer cache estará formateado en memory buffers. Cada memory buffer se acoplará al tamaño de de un data block.

Un memory buffer que guarda un bloque en cache, cuya información es diferente al bloque en disco, se conoce como dirty buffer. Un buffer estará limpio(es decir será un clean buffer) cuando se le ingrese un bloque por primera vez ó cuando los datos del buffer se copien a los datafiles.

Un buffer se convertirá en dirty buffer cuando el bloque que contiene es actualizado. Los bloques deben ser copiados a los Data Files eventualmente, de esto se encarga el proceso DBWR. Cuando esto ocurre, los buffers vuelven a ser clean buffers nuevamente.

El Log Buffer Cache es un área para montar los vector changes antes de que se registren en el redo log. Un vector change es cualquier cambio aplicado a la información por alguna instrucción DML.

Las sesiones escriben los redos en memoria y posteriormente se transcriben en los redo logs. De esto se encarga un proceso llamado LGWR.

LGWR copia la información del buffer al redo log en forma de batches, y conforme se va liberando la información del buffer, este puede ser sobrescrito por más vector changes.

El Shared Pool es la más compleja de las áreas del SGA, ya que se divide en docenas de subestructuras. Algunas de ellas son:

• Library Cache
• Data Dictionary Cache
• Área PL/SQL
• Cache para Resultado de Funciones y Queries

El Library Cache es utilizado para guardar el código ejecutado recientemente en su forma parseada. Parsing significa transformar todo el código escrito por los programadores a una unidad ejecutable, cosa que Oracle hace bajo demanda. El código parseado en el Shared Pool puede ser reutilizado sin tener que volver a ser convertido a una entidad ejecutable. Esto para poder incrementar el performance de la Base de Datos.

...