Estoy en el proceso de reemplazar el hardware de un clúster RAC de 3 nodos existente. Este sistema también es primario para una base de datos de reserva de RAC de 2 nodos. Para reemplazar el hardware, mi plan es extender temporalmente el clúster a una configuración de 6 nodos, 3 servidores antiguos y 3 servidores nuevos. Una vez que tenga las instancias ejecutándose en el nuevo hardware y mis aplicaciones se conecten a las nuevas instancias, eliminaré las instancias antiguas y retiraré los servidores antiguos, volviendo a una configuración de 3 nodos.
Después de extender el clúster a los seis nodos, el fin de semana pasado inicié las nuevas instancias en los nuevos nodos. Para facilitarme la vida, aproveché DBCA para este trabajo. Después de activar DBCA, elegí trabajar en una base de datos RAC y luego elegí Administración de instancias y luego Agregar nueva instancia. Al recorrer el asistente, dejé que DBCA se encargara de todos los detalles por mí. Suena simple.
Esta mañana, recibí mi informe de retraso de archivo habitual. Se parece a lo siguiente:
INSTANCE_NAME APPLY_LAG CURR_TIME
---------------- -------------------- -------------------
orcs1 +01 21:40:47 2012-12-03 08:00:01
Envío esto a mi bandeja de entrada dos veces al día. Un vistazo rápido me ayuda a determinar si mi standby está recibiendo y aplicando transacciones del primario. He configurado todas mis bases de datos en espera con un retraso de aplicación de cuatro horas. Y mi principal tiene ARCHIVE_LAG_TARGET establecido en una hora. Esto significa que el retraso en la aplicación será de al menos 4 horas, pero no debe ser superior a 5 horas. Como podemos ver arriba, tenemos dos bases de datos en espera que han superado con creces el retraso máximo de aplicación de 5 horas. Arriba, ¡tengo el modo de espera con un retraso de aplicación de 1 día 21 horas! Así que inmediatamente supe que algo andaba mal. Y no hacía falta ser un genio para saber que agregar la nueva instancia a la principal probablemente contribuyó al problema.
Como dije al comienzo de esta publicación, tengo un sistema de reserva RAC de 2 nodos. Una instancia es la "instancia de aplicación" y la otra instancia se encuentra allí relativamente inactiva. En mi registro de alerta de instancia de aplicación, vi los siguientes mensajes de error:
Sat Dec 01 14:25:40 2012
Recovery created file /u01/app/oracle/oradata/orcl/data04/undotbs04.dbf
Successfully added datafile 342 to media recovery
Datafile #342: '/u01/app/oracle/oradata/orcl/data04/undotbs04.dbf'
No OMF destination specified, unable to create logs
Errors with log /u01/app/oracle/admin/orcs/arch/3_89914_677462342.dbf
MRP0: Background Media Recovery terminated with error 1264
Errors in file /u01/app/oracle/diag/rdbms/orcs/orcs2/trace/orcs2_pr00_29759.trc:
ORA-01264: Unable to create logfile file name
Recovery interrupted!
Sat Dec 01 14:25:51 2012
Recovered data files to a consistent state at change 192271576009
Sat Dec 01 14:25:51 2012
MRP0: Background Media Recovery process shutdown (orcs2)
Dado que mi base de datos en espera está establecida en STANDBY_FILE_MANAGEMENT=AUTO, la primera parte de los mensajes tiene sentido. Cuando agrega una nueva instancia a una base de datos RAC, debe proporcionar un espacio de tabla de deshacer solo para esa instancia y también debe proporcionar grupos de registro de rehacer en línea dedicados al subproceso de esa instancia. El DBCA me hizo específicamente preguntas relacionadas con las estructuras de archivos de deshacer y rehacer. En el contenido del registro de alerta anterior, podemos ver que el archivo de datos en espera agregó con éxito 342, que es mi espacio de tabla Deshacer. Pero el modo de espera no pudo agregar los registros de rehacer en línea. Si desea que el modo de espera pueda agregar automáticamente los registros de rehacer en línea, debe especificar los parámetros OMF, lo cual me resisto a hacer. Dado que la adición del archivo de registro de rehacer en línea resultó en un error, el modo de espera detuvo la recuperación de medios. El modo de espera sigue recibiendo registros.
No encontré mucho en Metalink o haciendo búsquedas en Google sobre cómo resolver este problema, pero estos son los pasos que tomé para que Media Recovery volviera a funcionar. En la base de datos en espera (Hice esto en la instancia de aplicación, pero debería ser viable en cualquier instancia en la base de datos en espera de RAC):
1. alter database recover managed standby database cancel;
alter database recover managed standby database cancel
*
ERROR at line 1:
ORA-16136: Managed Standby Recovery not active
Esto no debería ser una sorpresa porque sabemos que Managed Recovery se anuló. Pero para completar, incluí este paso. Si tiene que agregar registros de rehacer a un dispositivo en espera que actualmente está aplicando transacciones, necesitará este paso.
2. alter system set standby_file_management='MANUAL' scope=memory;
System altered.
3. alter database add logfile thread 4 group 40 '/u01/app/oracle/oradata/orcl/redo01/redo40.log' size 536871424;
Database altered.
Lo anterior es exactamente lo que se ejecutó en el primario. Es necesario agregar el registro de rehacer en el modo de espera exactamente como se hizo en el principal. Repita para cada grupo de registro de rehacer agregado en el principal. Dado que agregué 3 instancias a mi base de datos RAC principal, tengo que agregar tres subprocesos aquí.
4. alter system set standby_file_management='AUTO' scope=memory;
System altered.
5. alter database recover managed standby database disconnect from session;
Database altered.
Inicie la recuperación administrada. Todo debería estar bien ahora y podemos verificar en el registro de alertas de la instancia de aplicación:
alter database recover managed standby database disconnect from session
Attempt to start background Managed Standby Recovery process (orcs2)
Mon Dec 03 13:32:38 2012
MRP0 started with pid=47, OS id=13232
MRP0: Background Managed Standby Recovery process started (orcs2)
started logmerger process
Mon Dec 03 13:32:44 2012
Managed Standby Recovery not using Real Time Apply
Mon Dec 03 13:32:49 2012
Parallel Media Recovery started with 4 slaves
Waiting for all non-current ORLs to be archived...
All non-current ORLs have been archived.
Mon Dec 03 13:32:49 2012
Completed: alter database recover managed standby database disconnect from session
Mon Dec 03 13:32:50 2012
Media Recovery Log /u01/app/oracle/admin/orcs/arch/1_87840_677462342.dbf
Media Recovery Log /u01/app/oracle/admin/orcs/arch/2_88542_677462342.dbf
Media Recovery Log /u01/app/oracle/admin/orcs/arch/3_89914_677462342.dbf
Media Recovery Log /u01/app/oracle/admin/orcs/arch/4_1_677462342.dbf
También podemos verificar que la demora de aplicación se está acortando. En espera, emita lo siguiente:
select i.instance_name,d.value as apply_lag,
to_char(sysdate,'YYYY-MM-DD HH24:MI:SS') as curr_time
from v$instance i,v$dataguard_stats d
where d.name='apply lag';
Para obtener información básica sobre cómo administrar registros de rehacer en línea para su base de datos física en espera, consulte la nota de Metalink 740675.1 Registros de rehacer en línea en una base de datos en espera.
