Visualizando los datos de la SGA

El SGA (Área Global del Sistema) es una estructura básica de memoria de Oracle que sirve para facilitar la transferencia de información entre usuarios y también almacena la información estructural de la base de datos más frecuentemente requerida.

El área global del sistema y un conjunto de procesos de la base de datos constituyen una instancia de una base de datos Oracle. La base de datos Oracle automáticamente reserva memoria para el área global del sistema cuando se inicia una instancia, y el sistema operativo reclama la memoria cuando se apaga dicha instancia. Cada instancia tiene su propia SGA.

Su espacio se divide en:

Área de asignación fija.

Área de asignación compartida.

Pool Compartido (Shared Pool).

Pool Grande (Large Pool).

Pool de Java.

Pool Stream.

Database Buffer.

Redo Log Buffer.

Área de asignación compartida.

Shared Pool: Su espacio se divide en:

Caché de biblioteca (Library Cache). Almacena código ejecutable de SQL y PL/SQL. Siempre que se ejecuta una nueva instrucción (SQL o PL/SQL), se comprueba si la ejecución de la misma está disponible en este área. Dentro de este caché tenemos:
Área SQL compartida (Shared SQL área). Contiene el plan de ejecución de la instrucción y el árbol de análisis de la misma. De esta forma se ahorra memoria cuando se repiten las instrucciones. También los elementos PL/SQL son cacheados de esta forma.

Área SQL privada. Normalmente los datos privados de los usuarios, referidos a información sobre su sesión, necesarios para que una instrucción se ejecute correctamente, se almacenan en la PGA (como se puede comprobar en el apartado anterior). Pero en el modo compartido de servidor, se almacena en la SGA, concretamente en la caché de biblioteca en una zona separada del área de SQL compartida.

Caché de Diccionario de Datos (Data Dictionary Cache). Se la conoce también como caché de fila ya que sus datos se almacenan en forma de fila (en el resto de cachés se almacenan en forma de bloques). Contiene información para acelerar el acceso a los metadatos que utilizan las instrucciones (también en la Caché de Biblioteca se guarda información sobre metadatos).

Caché de resultados (Results cache). Tanto para SQL como para:

PL/SQL, almacena fragmentos de consultas SQL y PL/SQL para aprovecharlos en consultas posteriores. El parámetro de sistema RESULT_CACHE_MODE permite establecer si todas las consultas almacenarán fragmentos en caché o sólo las marcadas de forma especifica.

Área fija. Es una zona pequeña donde se almacenan los datos necesarios para la carga inicial de la SGA en memoria.

Large Pool: Área opcional de la SGA que proporciona espacio para los datos necesarios para realizar operaciones que impliquen muchos datos:

Backup y restauración, para copias de seguridad.

Procesos de Entrada/Salida del servidor.

Memoria libre. Para aliviar el trabajo de la instancia.

Consultas en paralelo.

Almacenamiento de la UGA. Normalmente la UGA se almacena en la PGA, pero en modo de servidor compartido se podría almacenar en este área.

Cola de peticiones. Especialmente importante cuando el servidor recibe numerosas peticiones. No se almacenan bloques de datos en este caso.

Cola de respuestas. Tampoco utiliza bloques, sino estructuras más apropiadas para las colas.

Pool de Java: Sólo se usa para los programas que utilizan Java.

Pool de Streams: Lo usa sólo el componente Oracle Streams (utilizado para bases de datos distribuidas) y sirve para almacenar en búferes, datos manejados por dicho componente.

Database Buffer.

Está dividida en bloques y es la estructura que más ocupa espacio en la SGA normalmente. La base de datos Oracle intenta que la modificación de datos en el disco tarde lo menos posible. La estrategia principal es escribir lo menos posible en el disco.

Por ello cuando una instrucción provoca modificar datos, inicialmente esos datos se graban en esta caché. La grabación ocurre tras la confirmación de una transacción. Después, cada cierto tiempo, se grabarán todos de golpe en los ficheros de datos cuando ocurra un checkpoint.

Los datos, aunque no estén grabados realmente en disco, serán ya permanentes y aparecerán en las consultas que se realicen sobre ellos, además esas consultas serán más rápidas al no acceder al disco. Esto último es la segunda idea, que los datos a los que se accede más a menudo, estén en memoria y no se necesite leerlos del disco.

Los búferes de la caché se asignan con un complejo algoritmo basado en LRU (Last Recently Used) que da prioridad a los búferes que se han utilizado más recientemente.

Cada búfer puede estar en uno de estos estados:

Sin uso (Unused). Son bloques que no se están utilizando actualmente, por lo que están libres para cualquier proceso que requiere almacenar datos en ellos.

Limpios (Clean). Son búferes que se han utilizado, pero cuyos datos ya están grabados en disco. El siguiente checkpoint no necesitaria grabar estos datos, por lo que están disponibles si se requiere su reutilización.

Sucios (Dirty). Contienen datos que no se han grabado en disco. Se deben de grabar en el disco en cuanto ocurra un checkpoint, de otro modo podríamos perder información.

Además, con respecto al acceso, los búferes pueden tener dos condiciones:

Libres (Free o Unpinned). Ningún proceso le está utilizando.

Pinned. Están siendo utilizados por un proceso, por lo que otra sesión no puede acceder a este búfer.

Redo Log Buffer.

Es un buffer circular que mantiene todos los cambios que han sido realizados sobre la base de datos por operaciones INSERT, UPDATE, DELETE, CREATE, ALTER y DROP.

Las entradas de este buffer contienen toda la información necesaria para reconstruir los cambios realizados a la base de datos por medio de cualquier sentencia del DDL o del DML (el bloque que ha sido cambiado, la posición de cambio y el nuevo valor).

El uso del Redo Buffer es estrictamente secuencial, en tal sentido pueden entrelazarse cambios en los bloques de datos producidos por transacciónes diferentes.

El tamaño de este Buffer también puede ser configurado para mejorar el rendimiento de la instancia y de las aplicaciones que sobre ellas se ejecutan. Los registros Redo describen los cambios realizados en la BD y son escritos en los ficheros redo log para que puedan ser utilizados en las operaciones de recuperación hacia adelante, roll-forward, durante las recuperaciones de la BD.

Pero antes de ser escritos en los ficheros redo log son escritos en un caché de la SGA llamado redo log buffer. El servidor escribe periódicamente los registros redo log en los ficheros redo log.