SGA (Área Global del Sistema) es una estructura básica de memoria de Oracle que facilita la transferencia de información entre usuarios y almacena la información estructural de la base de datos requerida con mayor frecuencia.
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 reserva automáticamente memoria para el área global del sistema cuando se inicia una instancia, y el sistema operativo reclama la memoria cuando esta se apaga. Cada instancia tiene su propia SGA.
Contenido del SGA
El tamaño de la memoria Oracle SGA está determinado por los siguientes parámetros:
Shared_Pool_Size: tamaño en bytes del área destinada a sentencias SQL compartidas y sentencias PL/SQL. Db_Block_Size: tamaño en bytes de un solo bloque de datos. Db_Block_Buffers: número de búferes que se deben ubicar en memoria. Log_Buffer: número de bytes asignados al Redo Log Buffer.
La relación entre estos parámetros es:
SGA = Shared_Pool_Size + (Db_Block_Size * Db_Block_Buffers) + Log_Buffer
La SGA está compuesta por:
Redo Log Buffers Database Buffers Shared SQL Pool
Componentes de la SGA
Redo Log Buffer
Es un búfer circular que mantiene todos los cambios realizados sobre la base de datos mediante operaciones INSERT, UPDATE, DELETE, CREATE, ALTER y DROP. Las entradas de este búfer contienen toda la información necesaria para reconstruir los cambios realizados en la base de datos mediante cualquier sentencia del DDL o del DML, como el bloque modificado, la posición del cambio y el nuevo valor.
El uso del Redo Log Buffer es estrictamente secuencial. En este sentido, pueden entrelazarse cambios en los bloques de datos producidos por transacciones diferentes. El tamaño de este búfer también puede configurarse para mejorar el rendimiento de la instancia y de las aplicaciones que se ejecutan sobre ella.
Los registros redo describen los cambios realizados en la base de datos y se escriben en los archivos redo log para que puedan utilizarse en las operaciones de recuperación hacia adelante, o roll-forward, durante las recuperaciones de la base de datos. Antes de escribirse en los archivos redo log, se almacenan en una caché de la SGA denominada redo log buffer. El servidor escribe periódicamente estos registros en los archivos redo log.
El tamaño del redo log buffer se establece mediante el parámetro LOG_BUFFER.
Buffer Cache o Database Buffer Cache
thumb|derecha|120px|Proceso de la SGA
Su función es mantener los bloques de datos leídos más recientemente de los archivos de datos. Esto permite mejorar el rendimiento, ya que, si los datos vuelven a ser requeridos por un usuario, su acceso es más rápido.
Cuando se procesa una consulta, el servidor busca los bloques de datos requeridos en esta estructura. Si el bloque no se encuentra, el proceso servidor lo lee desde la memoria secundaria y coloca una copia en el búfer. De esta forma, otras peticiones que requieran ese bloque de datos no necesitarán acceder a la memoria secundaria mediante lecturas físicas.
Los bloques pueden contener datos modificados que todavía no se han escrito permanentemente en el disco. Oracle los administra de manera consistente para atender la concurrencia de los usuarios conectados a la base de datos, quienes comparten el acceso a esta área. Los bloques modificados se denominan bloques sucios.
El tamaño del búfer caché se establece mediante el parámetro DB_BLOCK_BUFFERS del archivo init.ora.
Como el tamaño del búfer suele ser insuficiente para almacenar todos los bloques de datos leídos, su gestión se realiza mediante el algoritmo LRU.
Área SQL compartida o Shared SQL Pool
En esta zona se encuentran las sentencias SQL que ya han sido analizadas. El análisis sintáctico de las sentencias SQL requiere tiempo, por lo que Oracle mantiene las estructuras asociadas a cada sentencia analizada durante el mayor tiempo posible para intentar reutilizarlas.
Antes de analizar una sentencia SQL, Oracle comprueba si existe otra sentencia exactamente igual en el área SQL compartida. Si la encuentra, no vuelve a analizarla y ejecuta directamente la que mantiene en memoria. De esta manera se favorece la uniformidad en la programación de las aplicaciones. La igualdad se considera lexicográfica e incluye los espacios en blanco y las variables.
La base de datos Oracle asigna memoria al shared pool cuando se analiza una nueva instrucción SQL. El tamaño de esta memoria depende de la complejidad de la instrucción. Si todo el shared pool ya ha sido asignado, la base de datos puede liberar elementos hasta que exista suficiente espacio para nuevas sentencias. Al liberar un elemento, la sentencia SQL asociada debe recompilarse y reasignarse a otra área SQL compartida la próxima vez que se ejecute.
El área SQL compartida contiene:
Las sentencias SQL y PL/SQL, incluido el texto de la sentencia. El plan de ejecución de la sentencia SQL. La lista de objetos referenciados.
Los pasos de procesamiento de cada petición de análisis de una sentencia SQL son:
Comprobar si la sentencia se encuentra en el área compartida. Comprobar si los objetos referenciados son los mismos. Comprobar si el usuario tiene acceso a los objetos referenciados. Si no se cumplen estas condiciones, la sentencia se considera nueva, se analiza y sus datos de análisis se almacenan en el área SQL compartida.
Esta caché también se administra mediante el algoritmo LRU. Su tamaño es gestionado internamente por el servidor, aunque forma parte del shared pool. El tamaño está determinado por el parámetro SHARED_POOL_SIZE.
Reutilización de memoria
En general, cualquier elemento del área SQL compartida o del dictionary row cache permanece en la memoria hasta que es descargado. La memoria asignada a elementos que no se utilizan con frecuencia se libera cuando es requerida por nuevos elementos que deben asignarse a un espacio del shared pool.
El algoritmo LRU permite que los elementos compartidos entre varias sesiones permanezcan en memoria mientras sean útiles, incluso si el proceso que los creó originalmente termina.
Oracle descarga la información contenida en el shared pool por cualquiera de las siguientes razones:
Si un objeto del esquema referenciado en una sentencia SQL es modificado posteriormente, el área SQL compartida se invalida y la sentencia debe recompilarse la próxima vez que se ejecute. Si se cambia el nombre global de la base de datos, se descarga toda la información del shared pool. El administrador puede desalojar manualmente toda la información del área compartida para evaluar el rendimiento esperado después del inicio de la instancia, sin apagar la instancia actual. Para ello se utiliza la sentencia ALTER SYSTEM FLUSH SHARED_POOL.
El shared pool se divide en los siguientes componentes:
Library Cache
Incluye las áreas comunes de SQL, las áreas privadas de SQL —en una configuración de servidor compartido—, los procedimientos y paquetes PL/SQL y las estructuras de control, como los bloqueos.
Data Dictionary Cache
También conocido como Dictionary Cache o Row Cache, almacena la información utilizada más recientemente sobre el diccionario de datos. Es una colección de tablas y vistas que contienen información relacionada con la base de datos, como los nombres y tipos de datos de las columnas de las tablas, los usuarios, las contraseñas y los privilegios.
Durante la fase de compilación, esta información es necesaria para resolver los nombres de los objetos utilizados en un comando SQL y validar los privilegios de acceso.
Otros componentes de la SGA
Large Pool
El administrador de la base de datos puede configurar esta área opcional de memoria para proporcionar espacios más amplios destinados a:
Memoria de sesiones. Procesos de entrada y salida del servidor. Copias de seguridad de la base de datos y operaciones de recuperación.
Al asignar espacios dentro del large pool para un servidor compartido, Oracle puede utilizar el shared pool principalmente para almacenar en caché las sentencias SQL compartidas y evitar la sobrecarga causada por la reducción de la caché SQL compartida.
Además, la memoria destinada a las copias de seguridad, las operaciones de recuperación y los procesos de entrada y salida del servidor se asigna en búferes de algunos cientos de kilobytes. Por ello, el large pool puede satisfacer esta demanda de memoria con mayor facilidad que el shared pool.
Java Pool
La memoria Java Pool se utiliza en la memoria del servidor para todas las sesiones que emplean código Java y datos de la JVM. Esta memoria se utiliza de distintas maneras dependiendo del modo en que se ejecute la base de datos.
Streams Pool
Esta memoria es utilizada exclusivamente por los flujos de Oracle. Almacena colas de mensajes y proporciona memoria para que los flujos de Oracle capturen y apliquen procesos.
Salvo que se configure específicamente, el tamaño de esta memoria comienza en cero. El tamaño del streams pool aumenta dinámicamente cuando es necesario y se utilizan los flujos de Oracle.
Procesos que acceden a la SGA
Procesos de primer plano
Los procesos de primer plano ejecutan actividades como verificar si un usuario tiene permiso para acceder a los datos, generar un plan de ejecución para las consultas enviadas por el usuario y recuperar o modificar bloques de datos del búfer caché.
Entre sus funciones se encuentran:
Verificación de los permisos del usuario. Elaboración del plan de ejecución de las sentencias. Recuperación de datos de la caché. Recuperación en caso de fallos. Gestión de bloqueos.
Procesos de segundo plano
A diferencia de los procesos de primer plano, los procesos de segundo plano permanecen activos desde que se inicia la base de datos hasta que esta se apaga.
Los principales procesos de segundo plano son:
Database Writer Log Writer Archiver Procesos de checkpoint
centro|300px|Estructura de procesos de la SGA
System Monitor, SMON
El SMON es el supervisor del sistema y se encarga de las recuperaciones que sean necesarias durante el arranque. Esto puede ocurrir si la base de datos se detuvo inesperadamente debido a un fallo físico, lógico o de otra clase.
Este proceso realiza la recuperación de la instancia de la base de datos a partir de los archivos redo log. Además, limpia los segmentos temporales no utilizados y compacta los espacios libres contiguos en los archivos de datos. Se activa regularmente para comprobar si debe intervenir.
Process Monitor, PMON
Este proceso restaura las transacciones no validadas de los procesos de usuario que se interrumpen, liberando los bloqueos y los recursos de la SGA. Asume la identidad del usuario cuyo proceso ha fallado, libera todos los recursos de la base de datos que estuviera utilizando y anula la transacción cancelada.
El proceso se activa regularmente para comprobar si su intervención es necesaria.
Database Writer, DBWR
El proceso DBWR es responsable de gestionar el contenido de los búferes de datos y de la caché del diccionario. Lee los bloques de los archivos de datos y los almacena en la SGA. Posteriormente, escribe en los archivos de datos los bloques cuyo contenido ha cambiado.
La escritura de los bloques en el disco se difiere para mejorar la eficiencia de las operaciones de entrada y salida. Es el único proceso que puede escribir en la base de datos, lo que asegura su integridad.
Log Writer, LGWR
El proceso LGWR se encarga de escribir los registros redo log en los archivos redo log. Estos registros contienen siempre el estado más reciente de la base de datos, ya que el DBWR puede tener que esperar para escribir los bloques modificados desde el búfer de datos hacia los archivos de datos.
Checkpoint, CKPT