El Área Global de Sistema SGA por sus siglas en inglés (System Global Area) es un grupo de estructuras de memoria compartida, conocidas como componentes SGA las cuales contienen datos e información de control para una instancia de Oracle Database. En el siguiente artículo entenderás para qué sirve y cuáles son sus componentes.
Qué es una Instancia Oracle
Como ya dijimos anteriormente el SGA hace parte una instancia Oracle y está es la combinación de los procesos en background y las estructuras de memoria. Para acceder a los datos contenidos en la base de datos, hay que iniciar la instancia. Cada vez que se inicia una instancia se asigna un área global del sistema (SGA) y se inician los procesos en background Oracle.
Te puede interesar: Oracle Linux – DBA Experts
Para qué sirve el SGA
El SGA sirve para facilitar la transferencia de información entre usuarios y también almacena la información estructural de la Database que se requiera más frecuentemente. Los ejemplos de datos almacenados en el SGA incluye: bloques de datos almacenados en caché y áreas SQL compartidas. El SGA se mantiene en memoria virtual del computador en el que reside la instancia Oracle. Si dentro de la instancia existe la posibilidad de que más de un usuario se encuentre conectado simultáneamente, los datos dentro de la SGA de la instancia son compartidos entre todos los usuarios.
¿De qué está compuesta la SGA?
La SGA está compuesta de tres componentes requeridos que son: Shared Pool, Database Buffer Cache y Redo Log Buffer; también consta de tres componentes opcionales que son: Java Pool, Largue Pool y Streams Pool.
Componentes requeridos:
1. Piscina compartida – Shared Pool:
Se trata de una zona de memoria utilizada para acelerar la ejecución de las instrucciones SQL y PL/SQL. 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 esta área. Dentro de este caché tenemos: Primero la Área SQL compartida (Shared SQL area) que 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. Segundo, la Área SQL privada, sabemos que 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 caché:
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 específica.
-
Área fija:
Es una zona pequeña donde se almacenan los datos necesarios para la carga inicial de la SGA en memoria.
2. Caché de Búferes de Datos – Database Buffer Cache:
Está dividida en bloques que más ocupan en la SGA. Oracle Database 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 (concretamente 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.
3. Rehacer Búfer de registro – Redo Log Bufer:
Se trata de un búfer circular. se van utilizando los bloques y, cuando se han usado todos, se vuelven a reutilizar los primeros en caso necesario y así continuamente. su función es almacenar la información acerca de los últimos cambios (DML confirmados y DDL) realizados sobre la base de datos. esta información se vuelca continuamente, mediante el proceso LGWR, a los archivos de datos. los redo log son necesarios para recuperar los datos que no han podido ser grabados definitivamente en disco (normalmente por ocurrir una situación de excepción antes de un checkpoint).
Componentes opcionales:
4. Piscina de Java – Java Pool:
Caché de memoria que almacena los objetos JAVA más recientemente usados y código de aplicación cuando se usa la opción Oracle JVM. Esta memoria es usada de diferentes maneras dependiendo del modo en el que la base de datos esté corriendo.
5. Gran piscina – Large Pool:
Caché de memoria que contiene para grandes operaciones como recuperación y respaldo con Recovery Manager (RMAN) y componentes de Shared Server.
6. Piscina corriente – Streams Pool:
Caché de memoria que almacena datos asociados con requerimientos de colas de mensajes cuando se instala la opción Advanced Queuing en el Servidor.
El tamaño de los componentes de la SGA pueden ser administrados manualmente o automáticamente. Si se escoge administrar manualmente estos componentes, se debe especificar el tamaño de cada uno de ellos aumentando o disminuyendo el tamaño de ellos según las necesidades de la aplicación. Si los estos componentes son administrados automáticamente, la instancia por sí misma monitorea la utilización de cada componente de la SGA y ajusta sus tamaños.
