Después de un corte de energía reciente en nuestro sitio DR, descubrí que un dispositivo de reserva había dejado de aplicar registros. Aparentemente, en los registros de rehacer archivados había una transacción que generó un archivo de datos, pero el disco en el sitio en espera no tenía suficiente espacio en disco para permitir que se completara esa transacción. Entonces, la recuperación administrada finalizó en modo de espera, como debería ser.
Normalmente mantenemos los registros de rehacer archivados durante 7 días. Desafortunadamente, cuando descubrí esta situación, habían pasado 15 días y los registros de rehacer archivados "faltaban". Sin registros de rehacer archivados para aplicar, la única solución era reconstruir la base de datos desde cero. Esta base de datos tiene un tamaño aproximado de 7 TB, por lo que reconstruir desde cero no es un asunto trivial.
La principal es una base de datos RAC 11.2.0.2 de 3 nodos que se ejecuta en Linux. El standby es una base de datos RAC de dos nodos, obviamente las mismas versiones de Oracle y OS.
Así es como logramos reconstruir el standby:
- Pusimos el principal en modo de copia de seguridad activa y tomamos una instantánea basada en disco de la base de datos.
- La instantánea se copió en un medio externo. Nota:el envío a través de la WAN requería demasiado tiempo.
- Los medios externos se llevaron personalmente al sitio de DR.
- El LOG_ARCHIVE_DEST_STATE_n para el standby se configuró en DEFER.
- La base de datos en espera se eliminó de la configuración de DG Broker: ELIMINAR BASE DE DATOS en espera CONSERVAR DESTINOS;
- Se borraron los puntos de montaje de la base de datos en espera. Después de todo, la base de datos era esencialmente inútil en este momento.
- Se crearon nuevos puntos de montaje y la instantánea se escribió en el disco en el sitio DR.
- Después de que se completaron las transferencias de archivos (alrededor de 5 días), le indicamos a nuestro almacenamiento que actualizara la instantánea en el sitio de DR con una instantánea más actual. Esto se realizó a través de la WAN ya que solo se enviaban los cambios, que era mucho, mucho más pequeña que la base de datos.
- Se creó un archivo de control en espera: ALTER DATABASE CREATE STANDBY CONTROLFILE AS '/dir/path';
- Para simplificar las cosas, queríamos usar una instancia única en espera hasta que lo pusiéramos en marcha. Así que creamos un PFILE a partir del RAC SPFILE del standby y luego usamos un editor de texto para modificar el archivo de parámetros y eliminar cualquier parámetro compatible con RAC. Eliminamos CLUSTER_DATABASE, configuramos un parámetro UNDO_TABLESPACE específico de la instancia para que se use para todas las instancias "*.", eliminamos los parámetros THREAD, etc. Nuestra base de datos en espera normal tiene dos instancias, STANDBY1 y STANDBY2. En el nodo 1, colocamos el pfile en $ORACLE_HOME/dbs/initstandby.ora en lugar de initstandby1.ora para que la base de datos de instancia única pueda encontrar su archivo de parámetros. Hicimos algo similar para el archivo de contraseñas.
- Copiamos el archivo de control en espera del paso 9 sobre los archivos de control en la instantánea de la base de datos.
- Con el archivo pfile y pswd en su lugar para una base de datos de una sola instancia, hicimos un MONTAJE DE INICIO.
- Creamos todos los registros de rehacer en espera que necesitaríamos. En nuestro caso, el principal también tiene registros de rehacer en espera para facilitar las operaciones de cambio y los registros de rehacer en espera del principal no formaban parte de la instantánea. Así que tuvimos que quitar las SRL que no hicieron el viaje.
- En el principal, establezca LOG_ARCHIVE_DEST_STATE_n en ENABLE.
- En las instancias principales, realizó ALTER SYSTEM SWITCH LOGFILE;
- Verificó en los registros de alerta tanto del primario como del standby que el standby estaba recibiendo registros, es decir, verificó que el transporte de registros estaba funcionando.
- Activado en espera gestionada:ALTERAR BASE DE DATOS RECUPERAR BASE DE DATOS EN ESPERA GESTIONADA DESCONECTAR DE LA SESIÓN;
- Se verificó en el registro de alertas del standby que los registros se estaban aplicando, es decir, la aplicación verificada ahora funcionaba.
En este punto, teníamos una base de datos en espera en funcionamiento. Creamos una tabla simple en el primario e insertamos una fila de datos en ella, realizamos los cambios de registro nuevamente y luego abrimos el modo de espera en modo de SOLO LECTURA para verificar que la transacción se reprodujo en el modo de espera como debería. Una vez que estuvimos satisfechos de que la base de datos en espera estaba funcionando, necesitamos convertirla en una base de datos RAC. Bueno, ya está todo listo para que esto sea una base de datos RAC como lo fue alguna vez. Para finalizar el trabajo, simplemente apagamos la base de datos en espera de instancia única (CIERRE ANULADO) en SQL*Plus y luego usamos srvctl para iniciar la base de datos en espera como una base de datos RAC:
srvctl iniciar base de datos -d en espera -o montar
Lo único que quedaba en este punto era volver a agregar el standby a la configuración de DG Broker (en DGMGRL): ADD DATABASE standby
Cuando esto sucedió por primera vez, estaba nervioso por cómo sería una base de datos tan grande. Ninguna de las operaciones anteriores depende del tamaño, aparte de copiar los archivos hacia y desde los medios. Pero todo salió bien.
Para asegurarnos de que no nos encontremos con esta situación en el futuro, agregamos alertas a nuestro Oracle Enterprise Manager Grid Control. Ahora recibiré una alerta de ADVERTENCIA cuando el envío de registros o la aplicación de registros tengan un retraso de 12 horas y una alerta CRÍTICA cuando tengan un retraso de 24 horas. Eso debería darnos mucho tiempo para solucionar cualquier problema antes de que los registros de rehacer archivados se eliminen automáticamente después de 7 días o, como mínimo, cambiar el proceso para retener más días de registros de rehacer archivados hasta que rectifiquemos la situación.
