Tips para administración de memoria en una base de datos Oracle 11GR2


Gestión de memoria en Oracle 11gR2

Constantemente recibo peticiones para establecer el tamaño ideal de memoria para una instancia de base de datos. Aunque el mejor consejo es manejar un estándar para toda las bases de datos, a veces el valor estándar no es suficiente o es demasiado, todo depende de los recursos con los que contemos y la funcionalidad que tendrá la base de datos.

Aunque Oracle recomienda utilizar servidores dedicados para base de datos, en las organizaciones no siempre siguen ese consejo, esto sucede mucho en servidores de desarrollo, pruebas o QA, donde el servidor soporta: aplicación, base de datos, es repositorio de fuentes y hasta servidor ftp (he visto casos).

La memoria es uno de los recursos mas valiosos de un servidor, pero, ¿por que rompernos la cabeza buscando un valor ideal para nuestros segmentos de memoria si Oracle puede hacerlo automáticamente y de forma eficiente?

A continuación veremos algunos tips para administración eficiente de memoria en una instancia de base de datos. 

Comenzaremos dando un rápido repaso a los segmentos de memoria en una instancia:


El SGA (Systen Global Area) es un segmento de memoria compartida que soporta las estructuras;
  • Database Buffer Cache: Contiene bloques de datos desde disco que han sido recientemente usados y sirven para satisfacer sentencias SELECT y DML.
  • Large Pool: área opcional que cumple varias funciones. Entre ellas manejo de transacciones distribuidas, operaciones paralelas de consultas y backup's and restore's.
  • Java Pool; Utilizado por el Java Virtual Machine para código y datos Java dentro de una sesión.
  • Streams Pool: soporta datos y controla estructuras de la caracteristica Oracle Streams.
  • Redo Log Buffer Cache: estructura circular que almacena los cambios mas recientes a los bloques de datos en los datafiles, es el paso previo a escritura a los online redo log files.
  • Shared Pool: estructura que almacena otro conjunto de estructuras que facilitan la ejecución de sentencias y el uso del diccionario de datos.
El PGA (Program Global Area) es un segmento de memoria privada para cada sesión y soporta datos necesarios para cada una. Stack de procesos, información esencial de cada proceso de usuario entre otras.

Gestión automática de memoria (Automatic Memory Management - AMM)

Cuando utilizamos AMM el tamaño del SGA y PGA sera balanceado automáticamente y la suma de los dos segmentos estará entre un valor establecido previamente mayor a 0 hasta un valor máximo definido. Los parámetros que nos ayudaran a activar esta característica son MEMORY_TARGET y MEMORY_MAX_TARGET.

Activando AMM:
SQL> alter system set memory_target = 500m scope=both;

El parametro MEMORY_MAX_TARGET establece un limite para el parámetro MEMORY_TARGET y es estático, por lo que para establecer su valor debemos reiniciar la base de datos.

La siguiente tabla nos ayudara a entender el comportamiento del SGA y PGA segun sus valores al momento de activar AMM:

Si los parámetros están establecidos como…

SGA_TARGET con un valor > 0 PGA_AGREGATE_TARGET con un valor > 0
El SGA y PGA no podrán ser menores ese valor establecido; MEMORY_TARGET automáticamente tuneara el valor entre los limites (SGA_TARGET + PGA_AGGREGATE_TARGET) y MEMORY_MAX_TARGET
SGA_TARGET con un valor > 0
PGA_AGGREGATE_TARGET = 0
Ambos parámetros siguen siendo tuneados automáticamente pero el valor inicial de PGA_AGGREGATE_TARGET será (MEMORY_TARGET – SGA_TARGET)
SGA_TARGET = 0
PGA_AGGREGATE_TARGET con un valor > 0
Ambos parámetros siguen siendo tuneados automáticamente pero el valor inicial de SGA_TARGET será MIN(MEMORY_TARGET-PGA_AGGREGATE_TARGET,
SGA_MAX_SIZE)
SGA_TARGET = 0
PGA_AGGREGATE_TARGET = 0
Ambo parámetros serán tuneados automáticamente tomando como valor inicial 60 % para SGA y 40% para PGA de valor de MEMORY_TARGET

En muchas ocasiones, se requiere un mejor control sobre los segmentos internos del SGA por lo que la opción ideal es utilizar la característica Automatic Shared Memory Management o ASMM.

Gestión Automática de Memoria Compartida (Automatic Shared Memory Management - ASMM)

ASMM nos ayuda a tener un mejor control sobre la memoria compartida SGA. Si por ejemplo en nuestro ambiente hemos tenidos errores relacionados con memoria por tamaños muy pequeños en el DATABASE BUFFER CACHE en horas pico de transacciones o si por ejemplo los backups de RMAN requieren mas memoria en el LARGE POOL etc.

ASMM utiliza el proceso background MMAN (Memory Manager) para la gestión automática de valores de memoria. MMAN monitorea el tamaño de cada componente del SGA y realiza ajustes dependiendo del uso, agregando mas memoria de ser necesaria o disminuyendo el valor si no esta en uso.

Para activar esta característica basta con modificar el parámetro MEMORY_TARGET y como el objetivo es establecer un valor  ideal para el SGA debemos modificar también el parámetro SGA_TARGET.

 SQL> alter system set memory_target = 0 scope=both;

SQL> alter system set sga_target= 3G scope=both;

Importante: ambos parámetros son dinámicos por lo que no se requiere reinicio de la instancia, sin embargo sus valores están limitados por MEMORY_MAX_TARGET y SGA_MAX_TARGET respectivamente, que son estáticos. 

Para encontrar el valor ideal del parámetro SGA_TARGET podemos hacer uso de la siguiente consulta:

SQL> select (
1(select sum(value) from v$sga) -
2(select current_size from v$sga_dynamic_free_memory)
3 ) sga_target
4 from dual;

Cuando ASMM esta activo los siguientes parámetros que conforman el SGA serán tuneados automáticamente y para obtener el mejor resultado de esta característica debemos establecerlos como 0:
  • SHARED_POOL_SIZE
  • LARGE_POOL_SIZE
  • JAVA_POOL_SIZE
  • DB_CACHE_SIZE
  • STREAMS_POOL_SIZE
Cuando ASMM esta activo los siguientes parámetros deben ser configurados manualmente y debido a que son estáticos no serán  tuneados automáticamente sin embargo como son parte del SGA el valor establecido sera  descontado del valor de SGA_TARGET:
  • DB_KEEP_CACHE_SIZE
  • DB_RECYCLE_CACHE_SIZE
  • DB_nK_CACHE_SIZE
  • LOG_BUFFER
Estas características nos pueden facilitar mucho la vida y es importante saber cual es el verdadero sentido de modificar los parámetros vistos, entre AMM y ASMM no hay alguna que sea estrictamente recomendable para nuestros ambientes sino como mencionaba al inicio dependerá de las características que tengamos y el uso que queramos darla a nuestra base de datos. 




Comments

Post a Comment

Popular posts from this blog

Cómo extraer Archive Logs desde un Backup Piece

RMAN no es de mis herramientas favoritas en Oracle, quizás porque cada vez que nos vemos las caras es porque ha ocurrido algún desastre. En esta ocasión necesitaba extraer Archive Logs para aplicarlos a una operación de RECOVER pero resulta que los archives estaban catalogados en una ubicación externa y fuera de mi alcance. Cuando al fin logre catalogar los archivos de backup que contenían los Archive Logs era necesario colocarlos en una ubicación local para poder aplicarlos. Así que veamos como extraer los archivos necesarios. Una vez catalogados los archivos de backup en nuestro repositorio de RMAN, podemos visualizar los Archives contenidos con el comando LIST BACKUP OF ARCHIVELOG ALL. RMAN> list backup of archivelog all; using target database control file instead of recovery catalog List of Backup Sets =================== BS Key  Size       Device Type Elapsed Time Completion Time ------- ---------- ----------- ------------ --------
Read more

Ejemplo práctico con SQL Tuning Advisor y SQL Access Advisor

Parte del perfil de un administrador de base de datos es el afinamiento de sentencias SQL, el afinamiento (o tuning) nos ayuda a mejorar el rendimiento de sentencias SQL dentro de nuestras bases de datos, mejorando: tiempos de respuesta de aplicaciones, tiempo de respuesta de procesos batch, consumo de recursos del sistema, escalabilidad de las aplicaciones. En Oracle, la ejecución de una sentencia SQL requiere tres fases: parseo, enlace y ejecución ( parse, bind and execute ). La parte de parseo es la que nos interesa para fines de este artículo. En esta, nuestro servidor interpreta lo que la sentencia significa y cuál es la mejor manera de ejecutarla. El parseo involucra interacción con el segmento de memoria SHARED POOL dentro de la instancia de la base de datos. Las estructuras del SHARED POOL convierten el SQL en algo ejecutable mediante un plan de ejecución. Plan de ejecución: es el resultado de la fase de parseo, indica la forma en cómo se va a acceder a los datos solici
Read more

Guía rápida de uso de Oracle ASMLib

Oracle ASMLib es una herramienta opcional en sistemas Linux, facilita la administración de dispositivos de almacenamiento a nivel de sistema operativo para la manipulación dentro de una instancia ASM. Instalación de ASMLib: para instalar la librería basta con utilizar YUM para descargarla de los repositorios públicos de Oracle. [root@oel-pruebas]# yum install oracleasm-support oracleasmlib .. ..   skipping a bunch of things... .. Resolving Dependencies --> Running transaction check ---> Package oracleasm-2.6.18-194.el5.x86_64 0:2.0.5-1.el6 set to be updated ---> Package oracleasm-support.x86_64 0:2.1.4-1.el6 set to be updated --> Finished Dependency Resolution Dependencies Resolved ================================================================================ Package                      Arch       Version          Repository       Size ===============================================================================
Read more