Archivo de parámetros en Oracle Rac

Días atrás, recibí un requerimiento: debía cambiar el UNDO TABLESPACE de una base de datos hacia una nueva ubicación en el almacenamiento donde se aloja. La razón, simplemente tener un mejor orden en las rutas de los datafiles. La tarea era algo de rutina que ya había hecho varias veces y que no requiere más que el tiempo en que la base de datos deja de utilizar los segmentos UNDO anteriores y comienza a utilizar los nuevos.

Sin embargo, no había tomado algo en cuenta. Esta base de datos no era una instancia única, era parte de un RAC.

En un ambiente RAC, cada nodo (instancia) trabaja de manera independiente y se comunica con una misma base de datos. La lógica nos dice que: cómo cada instancia es independiente, las transacciones que se ejecuten dentro de cada una son independientes también, por lo tanto, requieren de un UNDO TABLESPACE individual. La estructura sería algo similar a esto:

El parámetro UNDO_TABLESPACE indica el nombre de tablespace que se utilizara para llevar a cabo la tarea de “UNDO” en la instancia. Si el valor de UNDO_TABLESPACE se almacena en el archivo de parámetros, ¿Cómo funciona el spfile en un ambiente RAC?

En términos generales, el archivo de parámetros (SPFILE - server parameter file) es un archivo binario que contiene los valores de cada parámetro dentro de una instancia y se crea junto con la base de datos si se utiliza el asistente (DBCA) para esta tarea, si por el contrario creamos la base de datos manualmente debemos crearlo a partir del PFILE utilizado (SQL> create spfile from pfile).

En un ambiente RAC, se utiliza un mismo archivo de parámetros para todas las instancias y debe estar ubicado en un volumen que pueda ser alcanzado por todas los nodos de nuestro RAC, generalmente un ambiente RAC utiliza ASM como manejador de archivos por lo que esto no debiera ser un problema. 

Esquema de un SPFILE en Oracle RAC

Explicación:

En realidad cada nodo utiliza un archivo estático init<INTANCENAME>.ora dentro del cual el único parámetro visible será SPFILE=’path’. El valor de este parámetro indicara el archivo SPFILE utilizado por todas las instancias y debe estar ubicado en un volumen compartido por todos los nodos.

Ejemplo: El siguiente escenario fue extraído de un ambiente RAC real.

Nodo1:

$ cd $ORACLE_HOME/dbs/ $ls init.ora                    initCRRAC1.ora $cat initCRRAC1.ora SPFILE=’+DATA/CRADM/spfileCR_RAC.ora’

Nodo2:

$ cd $ORACLE_HOME/dbs/ $ls init.ora                    initCRRAC2.ora $cat initCRRAC1.ora SPFILE=’+DATA/CRADM/spfileCR_RAC.ora’

Podemos ver que ambos nodos apuntan al mismo archivo de parámetros ubicado en un ASM al cual ambos tienen acceso.

¿Cómo resolvemos entonces el conflicto  del parámetro UNDO_TABLESPACE? Es sencillo, en un ambiente RAC los parámetros en un SPFILE distinguen entre instancias mediante un prefijo que hace referencia al nombre de la instancia: <sid>.<parameter>

Las entradas en un SPFILE pueden tomar valores similares a:

• <sid>.<PAR_NAME> = VALOR
• *.<PAR_NAME> = VALOR

Cuando el parámetro esta precedido por un asterisco (*) en lugar del nombre de la instancia, el parámetro toma el mismo valor para todos los nodos en el RAC.

Si el valor de un parámetro está precedido con <sid> y también con * en el mismo archivo, <sid> toma precedencia sobre (*) y aplicara el valor para la instancia indicada.

Con esta forma de definir valores, encontramos que existen parámetros que deben tener el mismo valor y parámetros que por el contrario deben tener valor diferente para cada instancia.

Parámetros que requieren valores iguales en todas las instancias

La mayoría se explica por sí mismos y no entrare en detalle de su valor.

• ACTIVE_INSTANCE_COUNT
• ARCHIVE_LAG_TARGET
• COMPATIBLE
• CLUSTER_DATABASE/CLUSTER_DATABASE_INSTANCES
• CONTROL_FILES
• DB_BLOCK_SIZE
• DB_DOMAIN
• DB_FILES
• DB_NAME
• DB_RECOVERY_FILE_DEST/DB_RECOVERY_FILE_DEST_SIZE
• DB_UNIQUE_NAME
• INSTANCE_TYPE (RDBMS or ASM)
• PARALLEL_EXECUTION_MESSAGE_SIZE
• REMOTE_LOGIN_PASSWORD_FILE
• UNDO_MANAGEMENT

Parámetros que requieren valores únicos en todas las instancias

• THREAD: cada instancia tiene su propio set de Online Redo Log Groups, estos grupos son llamados “threads de online redo log”. En una instancia single, cada base de datos tiene un único thread para el manejo de transacciones por lo que no es necesario numerarlos. En un ambiente RAC cada instancia posee un thread y cada thread contiene sus  grupos y cada grupo sus miembros de grupo.

• ROLLBACK_SEGMENTS: indica el segmento para operaciones rollback, se ignora este parámetro si UNDO_MANAGEMENT = AUTO.

• INSTANCE_NAME: el nombre de la instancia debe ser único para cada nodo dentro del clúster.

• ASM_PREFERRED_READ_FAILURE_GROUPS: especifica grupos de fallo que contienen discos de lectura preferido en caso de falla.

• INSTANCE_NUMBER: identificador único que puede ir desde 1 hasta el número de nodos en nuestro RAC. 

• UNDO_TABLESPACE: indica el tablespace de tipo UNDO utilizado por cada instancia.

• CLUSTER_INTERCONNECTS: utilizado para indicar interconexión de clúster disponible para el uso de tráfico de datos. Utilizado para sobrescribir la interconexión por default en un ambiente RAC.

El resto de parámetros fuera de estos listados pueden tomar valores ya sean iguales para toda la instancia o independientes unos de otros.

Modificando parámetros en un ambiente RAC 

Para modificar un parámetro hacemos uso de la instrucción ALTER SYSTEM acompañada de la siguiente variación:

ALTER SYSTEM SET <dpname> SCOPE=MEMORY sid='<sid|*>';

Podemos usar la definición de un parámetro señalado como *.<dpname> para asignar el mismo valor a una instancia en particular:

ALTER SYSTEM RESET <dpname> SCOPE=MEMORY sid='<sid>';

Y para remover un parámetro del SPFILE y establecerlo a su valor default (si aplica) usamos:

ALTER SYSTEM RESET <dpname> SCOPE=SPFILE sid='<sid|*>';

Finalmente, a modo de ejemplo podemos ver la estructura de un SPFILE en el ambiente que usamos de ejemplo:

CRRAC1.__db_cache_size=1140850688 CRRAC2.__db_cache_size=2063597568 CRRAC1.__java_pool_size=50331648 CRRAC2.__java_pool_size=50331648 CRRAC1.__large_pool_size=67108864 CRRAC2.__large_pool_size=67108864 CRRAC1.__oracle_base='/u01/app/cr_rac'#ORACLE_BASE set from environment CRRAC1.__pga_aggregate_target=1073741824 CRRAC2.__pga_aggregate_target=1073741824 CRRAC1.__sga_target=3254779904 CRRAC2.__sga_target=3254779904 CRRAC1.__shared_io_pool_size=0 CRRAC2.__shared_io_pool_size=0 CRRAC1.__shared_pool_size=1862270976 CRRAC2.__shared_pool_size=939524096 CRRAC1.__streams_pool_size=0 CRRAC2.__streams_pool_size=0 *.audit_file_dest='/u01/app/cr_rac/admin/CR_RAC/adump' *.audit_trail='NONE' *.cluster_database=true *.compatible='11.2.0.4.0' *.control_files='+DATA/cr_rac/controlfile/current.277.902142813', '+FRA/cr_rac/controlfile/current.326.902142813' *.db_block_size=8192 *.db_create_file_dest='+DATA' *.db_domain='' *.db_name='CR_RAC' *.db_recovery_file_dest='+FRA' *.db_recovery_file_dest_size=7111442432 *.diagnostic_dest='/u01/app/cr_rac' *.dispatchers='(PROTOCOL=TCP) (SERVICE=CR_RACXDB)' CRRAC1.instance_number=1 CRRAC2.instance_number=2 *.open_cursors=300 *.pga_aggregate_target=1073741824 *.processes=350 *.remote_listener='' *.remote_login_passwordfile='exclusive' *.sessions=390 *.sga_target=3246391296 CRRAC2.thread=2 CRRAC1.thread=1 CRRAC1.undo_tablespace='UNDOTBS1' CRRAC2.undo_tablespace='UNDOTBS2'

Para consultar la forma en que finalmente cambie el UNDO_TABLESPACE de la instancia, pudes consultar: http://oraclehomegt.blogspot.com/2016/05/migrando-el-undotablespace-en-un-oracle.html