Recuperar el antiguo primario como standby tras un failover (REINSTATE)
OracleData GuardComando
# 1) Bring the old primary to MOUNT (sqlplus / as sysdba):
# SQL> STARTUP MOUNT;
# (RAC: srvctl start database -db <old_primary_db_unique_name> -startoption mount)
# 2) From DGMGRL connected to the new primary:
dgmgrl sys@<new_primary_db_unique_name>
REINSTATE DATABASE '<old_primary_db_unique_name>';
# 3) Verify:
SHOW CONFIGURATION;
SHOW DATABASE '<old_primary_db_unique_name>';Qué hace
Lleva el antiguo primario con flashback database a un punto anterior al SCN del failover, lo convierte en physical standby y empieza a recibir redo del nuevo primario; no hace falta reconstruir el standby desde cero.
Cuándo usarlo
Tras un failover, una vez que el servidor/almacenamiento del antiguo primario vuelve a estar accesible; tras un failover automático de FSFO (el observer suele reinstaurarlo por sí mismo).
Precaución
Flashback debe haberse habilitado en el antiguo primario ANTES del failover y los flashback logs deben cubrir el SCN del failover (db_flashback_retention_target, tamaño de la FRA); de lo contrario el reinstate falla y el standby debe reconstruirse con RMAN duplicate. Los datos escritos en el antiguo primario después del failover se pierden definitivamente.
Relacionado
- Mostrar la configuración del broker de Data Guard y el estado de las bases de datos (DGMGRL)
- Comprobar con SQL el rol primary/standby y la preparación para switchover
- Medir el lag de transporte/aplicación, la velocidad de aplicación y los procesos de Data Guard en el standby
- Validar el standby con el broker antes de un switchover/failover (VALIDATE DATABASE)
- Realizar un switchover planificado (DGMGRL, cambio de rol sin pérdida de datos)
- Realizar un failover tras perder el primario (DGMGRL)