Antes de explicar cómo activar Oracle ISM Daemon, vamos a comenzar explicando qué es Dynamic Intimated Shared Memory y Por qué nos Interesa, así que vamos a ver un poco de historia de Solaris
Intimitad Shared Memory
Es una característica que incorporó Solaris 2.2, aunque será a partir de la versión 2.4 cuando se puedan utilizar páginas de 4Mb en UltraSPARC. ISM, nos aporta las siguientes características
- Permite a la aplicación compartir el segmento de memoria
- Bloquea las páginas en memoria y hace que éstas estén fuere de los pageouts y por lo tanto no bajan a disco.
- Comparte la PTEs (page table entries) entre los procesos, por lo tanto son necesarios menos búsquedas en la traducción de direcciones de memoria.
- Usa 4 MB de tamaño de página, por lo tanto, disminuye el número de traducciones de memoria.
Traducido de http://www.adp-gmbh.ch/unix/solaris/ism.html
Pero no todo es perfecto, debemos tener en cuenta que ISM está diseñado para sistemas con tareas específicas, como Databases, WebServers, AppServer, ..., pero no para sistemas donde el usuario pueda lanzar cualquier applicación arbritaria. Además, usará páginas de 4MB tantas como sea posible, para el restro, utilizará páginas de 8KB disminuyendo su rendimiento.
Solaris 8 1/01 Dynamic Intimated Shared Memory
Como evolución a la tecnología ISM, se introduce la variante de configuración dinámica, pensada para Bases de Datos, aunque no será hasta Oracle 9i cuando se pueda aplicar dimensionado dinámico de la SGA
Solaris 9 y Dynamic Reconfiguration
En Solaris 9 se introduce la característica de Dynamic Reconfiguration que nos permite que los módulos de Memoria, CPU e I/O sean intercambiables en caliente y por lo tanto se elimina el downtime. Es a partir de Solaris 9 cuando se utiliza MPO
Solaris 10
Incorpora todas las evoluciones y mejoras de sus predecesores he incorpora mejoras en la gestión de Memoria y Zonas
Configurar Oracle 10g
Para activar Oracle DISM daemon, simplemente deberemos editar el archivo init$ORACLE_SID.ora y modificar el parámetro sga_max_size con un valor mayor al de sga_target, donde el valor de sga_max_size deberá ser el mayor tamaño que podamos asignar nunca superando TOTAL_MEM + TOTAL_SWAP, vamos a verlo con un ejemplo
$ cd $ORACLE_HOME/dbs/Para que este cambio sea efectivo, es necesario reiniciar la base de datos, para ello simplemente bajaremos la base de datos y la iniciaremos con el nuevo pfile utilizando el siguiente comando:
$ vi init$ORACLE_SID.ora
*.sga_target=5000M
*.sga_max_size=6000M
:wq
$ sqlplus / as sysdbaSi queremos que el cambio sea permanente, entonces crearemos el spfile desde el pfile, utilizando el siguiente comando:
SQL*Plus: Release 10.2.0.4.0 - Production on Thu Oct 8 20:23:30 2009
Copyright (c) 1982, 2007, Oracle. All Rights Reserved.
Connected to an idle instance.
SQL> startup pfile='?/dbs/initOLTP1.ora'
SQL> create spfile from pfile;Y con esto, la próxima vez que iniciemos nuestro Oracle tendrá los valores que hemos definido en nuestro pfile
Comprobar su funcionamiento
Para comprobar que el daemon DISM está en funcionamiento, simplemente debemos buscar el proceso ora_dism_$ORACLE_SID, de la siguiente forma
$ ps -ef|grep ora_dis|grep -v grepYa tenemos nuestro Oracle utilizando DISM, pero ... y ahora qué?
root 24506 19564 0 06:14:18 ? 0:06 ora_dism_OLTP1
Buena pregunta, hemos hecho esto para poder redimensionar nuestra SGA en caliente, y permitir a Oracle+Solaris gestionar mejor el uso de la memoria, por ejemplo, imaginemos la siguiente problemática:
Nuestro servidor de base de datos necesita ejecutar muchos Jobs que no estaban contenplados y estos hacen uso de mucho espacio de sort, shared, etc. sin embargo, nuestro tamaño de SGA está dimensionado para que pueda absorver los 500 clientes que se conectan de 09:00h a 15:00h contra la base de datos. Sin embargo, durante la noche no existen clientes y la carga de las conexiones dedicated es mínima. Nuestro DBA nos dice que necesita más SGA durante la noche y la que tiene durante el día (para no hacer swaping), qué hacemos?
Pues bien, una vez activado DISM, podemos utilizar la siguiente instrucción
SQL> alter system set db_cache_size=150M;Conclusión
Sistema modificado.
SQL> show sga
Total System Global Area 578813952 bytes
Fixed Size 2042336 bytes
Variable Size 394270240 bytes
Database Buffers 176160768 bytes
Redo Buffers 6340608 bytes
SQL> show parameter db_cache_size
NAME TYPE
------------------------------------ --------------------------------
VALUE
------------------------------
db_cache_size big integer
152M
SQL>
Como hemos visto, DISM nos aporta una flexibilidad mayor a la hora de configurar nuestra base de datos y poder hacer frente a cambios en la arquitectura (memoria, I/O, CPU) en caliente.
Espero no haberos aburrido,
Referencias
Muy buen post ;), es decir, si aunmentamos el db_cache_size usando dism ¿evitamos swap?
ResponderEliminar