Distribución de la memoria

Componentes esenciales de una instancia Oracle:

• Área global de memoria compartida (SGA)

• Conjunto de procesos en segundo plano (Background process)

• Conjunto de procesos de servidor (Foreground o server process)

Estructuras principales de la SGA:

• Caché de buffer de la base de datos (Database Buffer Cache)

• Buffer de log (Redo Log Buffer)

• Piscina compartida (Shared Pool)

Estructuras opcionales de la SGA:

• Piscina de objetos grandes (Large Pool)

• Piscina de objetos Java (Java Pool)

• Piscina de flujo de objetos (Streams Pool)

Database Buffer Cache

El caché buffer de la Base de Datos es donde se ejecuta el SQL. Cuando se actualizan los datos, las sesiones de usuarios no actualizan directamente los datos en el disco. Los bloques de datos que contienen el dato de interés, son primero copiados en la caché buffer de la Base de Datos. Los cambios son aplicados a las copias de los bloques de datos que están en la caché buffer de la Base de Datos.

Los bloques permanecerán en la caché durante algún tiempo después, hasta que el buffer que están ocupando sea necesario para almacenar otro bloque

En una consulta SQL de datos, los datos también van a la Caché Buffer De La Base de Datos. Las sesiones calculan que bloques contienen las filas de interés y los copian en el caché buffer, las filas relevantes son transferidas a la PGA de la sesión para un procesamiento adicional. Y el bloque permanece en el caché de buffer de la Base de Datos durante un tiempo después.

Los ficheros de datos son formateados en bloques de tamaño fijo. Las filas de las tablas y otros objetos de datos como son las claves indexadas, son almacenados en estos bloques. El caché buffer de la Base de Datos es formateado en el mismo tamaño que los ficheros de datos para poder sostener un bloque. A diferencia de los bloques, las filas son de longitud variable, la longitud de una fila dependerá del número de columnas definidas en la tabla.

Según el tamaño de los bloques (que es elegido por el DBA) y el tamaño de la fila (que es dependiente del diseño y uso de la tabla) pueden haber varias filas por bloque o posiblemente una fila puede ocupar varios bloques.

Idealmente, todos los bloques del disco que contienen datos que con frecuencia son consultados, estarán en el caché buffer, por lo tanto minimizando la necesidad de entrada y salida del disco:

• La mayoría de las bases de datos operaran bien con un tamaño de caché de cientos de megabytes hasta unos pocos gigabytes.

• El tamaño de caché buffer de la Base de Datos puede ajustarse dinámicamente y puede ser manejado automáticamente.

• Cuando los bloques de datos llevan un tiempo en el caché buffer, estos bloques son leidos por el proceso background DBWn (La n indica que puede existir más de un proceso) y escribe la información en los ficheros de datos, haciendo los cambios permanentes.

• La asignación de espacio para esta área se realiza cuando se inicia la instancia, aunque posteriormente puede ser dimensionado mediante los parámetros DB_CACHE_SIZE y DB_nK_CACHE_SIZE.

Redo Log Buffer

El Log Buffer es un área de organización pequeña, para vectores de cambio antes de que ellos sean escritos en el Redo Log del disco. Un vector de cambio es una modificación aplicada a algo, ejecutando declaraciones DML que genera vectores de cambio aplicados a los datos.

Cuando se realiza una modificación los datos del fichero de datos viajan al Caché Buffer de la Base de Datos y es aquí donde se les cambia a su nuevo valor, y el antiguo valor es almacenado en el Log Buffer para garantizar un posible Rollback. Posteriormente con el tiempo, los datos del Log Buffer son guardados en ficheros (Redo Log File)

El Redo Log es la garantía de que los datos nunca serán perdidos, siempre que un bloque de datos sea cambiado, los vectores de cambio aplicados al bloque son escritos en el Redo Log.

Los vectores de cambio que están en el Log Buffer pasan a los Ficheros Redo Log Redo gracias al proceso background LGWR y generalmente cuando se ejecuta una declaración COMMIT.

El Log Buffer es pequeño (en comparación con otras estructuras de memoria) porque es un área de almacenaje de corto plazo. Los vectores de cambio son insertados dentro de él, y son derramados al disco prácticamente en tiempo real. No hay necesidad para que sea más de unos pocos megabytes como máximo, y haciéndolo más grande que el valor por defecto puede ser seriamente malo para la interpretación. El valor por defecto, es determinado por el servidor de Oracle y está basada en el número de CPUs en el nodo del servidor.

No es posible crear un buffer log más pequeño que el por defecto. Si lo intenta, se modificaria automáticamente al valor por defecto. Es posible crear un buffer log más grande que el defecto, pero no es a menudo una buena idea. El problema es que cuando una declaración COMMIT es publicada, parte del proceso commit implica escribir el contenido del Log Buffer en los Ficheros Redo Log del disco. Esta escritura ocurre en tiempo real, y mientras él está en progreso, la sesión que publico el COMMIT estará colgada.

El procesamiento de un COMMIT es una parte critica de la arquitectura de Oracle. La garantía de que una transacción commit nunca será perdida se basa en que el mensaje de un commit completo no es retornado a la sesión hasta que los bloques de datos en la caché hayan sido cambiados (esto significa que la transacción ha sido completada) y los vectores de cambio hayan sido escrito en el Redo Log en el disco (y por lo tanto la transacción podría ser recuperada si fuese necesaria).

Un Log Buffer grande significa que potencialmente hay más para escribir cuando un COMMIT es publicado, y por lo tanto puede tomar un largo tiempo antes de que el mensaje de commit completo pueda ser mandado, y la sesión pueda reanudar el trabajo. El Log Buffer es asignado al arranque de la instancia y nunca puede ser cambiado posteriormente sin reanudarla. El tamaño del Buffer Log es estático, fijado al arrancar la instancia y no puede ser manejado automáticamente.

Shared Pool

El Shared Pool es la más compleja de las estructuras SGA. Está dividido en docenas de subestructuras, las cuales son manejadas internamente por el servidor de Oracle. Las 4 más importantes son:

• Library Cache (Caché de Libreria).

• Data Dictionary Cache (Caché de Diccionario de Datos).

• Result Cache (El caché de los resultados de las consultas SQL y funciones PL/SQL).

• Área PL/SQL.

El tamaño del Shared Pool y de todas sus estructuras es dinámico y pueden ser manejado automáticamente. La Shared Pool se puede dimensionar globalmente mediante el parámetro de iniciación SHARED_POOL_SIZE.

Library Cache

El Caché de la Libreria es un área de memoria para almacenar códigos ejecutados recientemente, en su forma analizada.

El análisis sintáctico es la conversión del código escrito por programadores en algo ejecutable, y es un proceso que Oracle hace a petición. El rendimiento mejora enormemente cuando se almacena el código analizado en la Library Cache, de forma que pueda ser utilizado sin realizar otra operación de análisis del código SQL ya que conlleva tiempo.

El objetivo del Caché de la Libreria del Shared Pool es almacenar declaraciones en su forma analizada, lista para la ejecución. La primera vez que una declaración es publicada, tiene que ser analizada antes de la ejecución, este análisis conlleva operativa como saber si existen índices, si es más rápido usar estos índices o recorrer toda la tabla entera, etc. La segunda vez, puede ser ejecutado inmediatamente. Esto ahorra una cantidad de tiempo enorme.

Data Dictionary Cache

En esta área se almacena toda la información relativa a las definiciones de objetos recientemente usados descripciones de tablas, columnas, índices, usuarios y derechos, información de almacenamiento así como otros metadatos. Se guardan en la memoria SGA donde son inmediatamente accesibles por todas las sesiones, así no tiene que leerlo del Diccionario de Datos.

El Caché del Diccionario de Datos almacena definiciones de objetos de modo que cuando las declaraciones tienen que ser analizadas, ellas puedan ser analizadas rápidamente sin tener que consultar el Diccionario de Datos. Por ejemplo cuando se realiza dos consultas sobre una misma tabla para recuperar registros diferentes, las dos consultas deben ser analizadas por que son declaraciones diferentes, pero el análisis de la primera SELECT habrá cargado la definición y las columnas de la tabla a consultar dentro del Caché del Diccionario de Datos, de forma que el análisis de la segunda consulta será más rápido, porque no es necesario acceder al Diccionario de Datos.

Result Cache

La Caché para el resultado de consultas SQLy PL/SQL, es una funcionalidad que se incluye a partir de Oracle 11g. Permite almacenar el resultado de las consultas en memoria, acelerando su obtención en múltiples ejecuciones.

Suele ocurrir que las mismas consultas son ejecutadas muchas veces. En el Result Cache es donde se almacena los resultados de dichas consultas en la memoria. La próxima vez que la consulta se publique, en vez de ejecutar la consulta en el servidor puede recuperarlo del Result Cache. Por defecto esta desactivado, pero si se activa a menudo puede mejorar la ejecución. El DBA puede especificar un tamaño máximo.

Área PL/SQL

En el Diccionario de Datos se almacenan los objetos de PL/SQL, tal como son los procedimientos, funciones, paquetes de procedimientos y funciones, definición de tipos de objetos, y trigers.

Para prevenir la lectura del Diccionario de datos cuando un objeto de PL/SQL es invocado por una sesión, dichos objetos son almacenados en el área PL/SQL del Shared Pool.

La primera vez que un objeto de PL/SQL es usado, él debe ser leído de las tablas de Diccionario de Datos del disco, pero la llamadas posteriores serán más rápidas, porque el objeto estará disponible en el PL/SQL área del Shared Pool.

SHARED POOL, REDIMENSIONANDO SU TAMAÑO

El tamaño del Shared Pool es crítico para su ejecución. Tiene que ser bastante grande para almacenar todo el código ejecutado con frecuencia y definiciones de objeto, pero no tan grande como para almacenar sentencias ejecutadas solo una vez.

Si el tamaño es muy pequeño no se podrá almacenar todas las sentencias necesarias y si es muy grande tardará mucho en localizar la sentencia adecuada. La memoria en el Shared Pool es asignada por el algoritmo LRU (los menos recientemente usados).

La mayor parte de las bases de datos necesitarán un Shared Pool de cientos de megabytes. Algunas aplicaciones necesitarán más de un gigabyte y pocas funcionarán con menos de 100 megabytes. El tamaño del Shared Pool es dinámico y puede ser automáticamente manejado.

Large Pool

Es un área opcional y si se crea estará usado por varios procesos, y al no existir utilizarían la memoria Shared Pool. Esta área lo utilizan unos procesos compartidos del servidor. Los servidores de ejecución paralelos también utilizaran el Large Pool. En ausencia del Large Pool estos procesos usarian la memoria del Shared Pool.

Si se utilizan servidores compartidos o servidores paralelos se debería crear un Large Pool. Algunos procesos de I-O también pueden usar el Large Pool, como los procesos usado por el Recovery Manager.

Si un proceso necesita el Large Pool, este fallara con un error si esta memoria no está disponible. Además si un proceso está utilizando un Large Pool y no dispone de toda la memoria necesaria no puede volver a utilizar el Shared Pool.

Java Pool

El Pool De Java solo se requiere si una aplicación va a dirigir procedimientos de Java almacenados en la Base de Datos, pero como varias opciones de Oracle son escritas en Java, entonces el Java Pool se considera estándar. El código de Java no está almacenado en el Java Pool, es almacenado en el Shared Pool.

El tamaño óptimo de Java Pool depende de la aplicación de Java y cuantas sesiones lo dirigen. Nunca debería ser insuficiente. Se puede modificar el tamaño sin reiniciar la instancia.

Streams Pool

El mecanismo usado por Streams debe extraer cambio de vector del Redo Log y de esta forma reconstruir las declaraciones que fueron ejecutadas. Su tamaño puede modificarse sin reiniciar la instancia.