Arquitectura de una Base de Datos Oracle

...

En conclusión, el propósito del Library Cache es el poder guardar el código de los queries en su forma parseada, listo para su ejecución.

El Data Dictionary Cache guarda las definiciones de objetos usados recientemente: Descripciones de Tablas, Índices, etc. Esto para que cuando las sentencias sean parseadas, sean parseadas de una manera más rápida sin tener que consultar al Diccionario de Datos.

El Área PL/SQL almacena objetos tales como Procedimientos, Funciones, etc. Cuando un objeto PL/SQL es llamado por una sesión, debe ser llamado desde el Diccionario de Datos. Para prevenir llamadas repetitivas al Diccionario de Datos, los objetos son guardados en el área PL/SQL.

El Cache de Resultados permite a Oracle guardar los resultados de los queries en memoria, esto para que cuando se ejecute el query de nuevo, solamente regrese su resultado en vez de tener que volverlo a procesar.

Cuando el Oracle Server necesita espacio, sobreescribirá los objetos que no han sido utilizados por el mayor tiempo, esto gracias a un algoritmo denominado LRU ( Least Recently Used ).

El Large Pool es un área que de ser creada, es utilizada por algunos procesos que de no existir el Large Pool tomarían espacio del Shared Pool.

El Java Pool es un área que es requerida si se van a ejecutar procedimientos java en la Base de Datos. Sin embargo, muchas opciones de Oracle corren bajo java, por lo tanto se podría decir que este pool es considerado un estándar actualmente.

Los background process, son procesos que son lanzados cuando una instancia es iniciada, y se ejecutan hasta que la instancia termine. Existen cinco procesos que han estado por mucho tiempo en la historia de Oracle, estos son:

- System Monitor(SMON)

- Process Monitor(PMON)

- Database Writer (DBWn)

- Log Writer(LGWRn)

- CheckPoint Process (CKPT)

SMON Se encarga de montar y abrir la Base de Datos. SMON monta la base de datos al localizar y validar el controlfile de la Base de Datos y posteriormente la abre al localizar y validar todos los datafiles y los online log files de la misma.

Un server process es lanzado cuando una sesión es creada y es destruido cuando la sesión termina. Cuando una sesión termina de una manera anormal, entonces el espacio utilizado por ese proceso de servidor debe limpiarse. PMON monitorea todos los procesos de servidor y detecta anomalías con las sesiones. Si una sesión ha terminado de una manera irregular, PMON eliminará el proceso de servidor asignado a la sesión y regresará a la memoria utilizada por este al PGA. Después de esto, PMON aplicará un rollback a todas las transacciones incompletas que la sesión haya tenido en progreso.

Las sesiones NO escriben directamente en disco, primero deben escribir en cache y posteriormente los procesos escribirán la información a disco.

El proceso DBWn, escribe dirty buffers en los datafiles, pero no los escribe conforme se van ensuciando. El algoritmo DBWn solamente escribe dirty buffers que no han sido utilizados recientemente. Existen cuatro circunstancias bajo las cuales se escriben los dirty buffers a disco:

- Que exista un gran número Dirty Buffers.

- Que hayan transcurrido 3 segundos.

- Que se ejecute un CheckPoint.

- Que no existen buffers disponibles.

Si un proceso de servidor necesita copiar un bloque al database buffer cache, debe encontrar un free buffer (buffer libre). Un free buffer es un buffer que no es un dirty buffer o pinned buffer (buffer sujeto a otra sesión).

Un dirty buffer no se debe sobreescribir ya que se perdería la información que contiene. Además de esto, un pinned buffer no puede ser sobreescrito ya que los mecanismos de protección de memoria del sistema operativo no lo permitirán.

Cuando un checkpoint ocurre, todos los dirty buffers son escritos al disco. La única razón por la cual se necesita que se ejecute un Checkpoint es cuando se cierra la Base de Datos y se apaga la instancia. Un Checkpoint copia todos los dirty buffers a disco, esto sincroniza el buffer cache con los datafiles y la instancia con la Base de Datos. Un checkpoint ocurre cuando se cerrará la base de datos y se apagará la instancia, pero también puede ser ejecutado de una manera forzada por la instrucción:

SQL> alter system checkpoint

El LGWR escribe los contenidos del log buffer a los online log buffers en disco. Al procedimiento de transferir los log buffers a disco se conoce como flushing.

Es imposible hacer que el código DML se ejecute más rápido que LGWR cuando escribe los vectores al disco. Existen 3 circunstancias bajo las cuales se ejecutará un LGWR:

- Que se ejecute un COMMIT.

- Que el Log Buffer este a un tercio de lleno.

- Que el DBWn este a punto de escribir Dirty Buffers.

Antes de que el DBWn escriba la información en los datafiles, manda una señal al LGWR para que este transfiera toda su información almacenada a los redo logs.

En resumen, después de un crash, todos los vectores refiriéndose a dirty buffers deben ser extraídos del redo log y aplicados a la data blocks, de eso se encarga el CKPT.

MMON se encarga de obtener estadísticas y actividades de rendimiento. A estas estadísticas se les conoce como Snapshots.

MMAN habilita el manejamiento automático de alocación de memoria. Es decir MMAN observa la demanda sobre el PGA y el SGA y distribuye la memoria a las sesiones y estructuras del SGA.

Todos los vector changes aplicados a la información se escriben en los buffers y posteriormene a los online redo logs.

Los online redo logs tienen un tamaño y número fijo. Una vez que se llenen, LGWR los sobreescribirá con más información.

Los Online Redo Log Files deben ser copiados antes de ser sobreescritos, de esto se encarga ARCn. A estas copias se les conoce como Archived Redo Logs.

Oracle Server provee un nivel de abstracción entre las estructuras físicas y lógicas, esta abstracción se lleva a cabo a través de los tablespaces.