Banco standby de Data Guard está atrasado con el primario

Organización de Data Guard

Tengo un banco de datos de producción, ORADB, que tiene un standby físico de Data Guard, ORADR.  El proceso de log apply corre en ORADR y aplica los registros (redo y archived logs) que le manda ORADB.

Sin embargo, hay veces que ORADR se atrasa con ORADB.

Primario Standby
ORADB ORADR

Determinar si el banco standby está atrasado con el primario

Esta consulta devuelve el número de horas de atraso del standby.  Hay que correrlo en el standby:

. oraenv
ORACLE_SID = [] ? ORADR
sqlplus / as sysdba

SQL>select  round((sysdate-max(first_time))*(1440/60))
from  V$ARCHIVED_LOG
where
applied=’YES’;

ROUND((SYSDATE-MAX(FIRST_TIME))*(1440/60))
——————————————

                                         4

Si la consulta devuelve un valor mayor al cero, el standby está atrasado.  En este caso, el retraso es de cuatro (4) horas.

Revise el alert log del standby

El alert log del standby tiene información muy útil.  Revíselo primero.

$ORACLE_BASE/diag/rdbms/oradr/ORADR/trace/alert_ORADR.log:

Fetching gap sequence in thread 2, gap sequence 31966-32065
Wed Sep 04 14:45:27 2013
Using STANDBY_ARCHIVE_DEST parameter default value as USE_DB_RECOVERY_FILE_DEST
Using STANDBY_ARCHIVE_DEST parameter default value as USE_DB_RECOVERY_FILE_DEST
Wed Sep 04 14:45:36 2013
Fetching gap sequence in thread 2, gap sequence 31966-32065

El standby necesita aplicar los registros (archived logs) con secuencias entre 31966 y 32065 (inclusivo) en el hilo (thread) 2.

¿Están en el servidor del standby?:
/ORADR/archivelog/2013_09_04):>ls  -lt *31966*

Los registros (archived logs) no fueron enviados del banco primario al standby.  ¿Por qué?

  • ¿Está activo el proceso de log apply?
    • ps -ef | grep mrp
      • debe devolver: ora_mrp0_ORADR.
    • Si no, aquí yace el problema.
    • Reactive el proceso de log apply
      • sqlplus / as sysdba (en standby)
      • alter database recover managed standby database using current logfile disconnect;
  • Si el proceso de log apply está activo, asegúrese de que los registros (archived logs) estén disponibles en el sistema primario.
    • Si no están, necesitarán ser restaurados.  Mi sistema usa RMAN para respaldar los registros (archived logs) cada tres horas.
    • Restaure los registros (archived logs) en el banco primario:
      • Conéctese a RMAN
        • rman target / catalog rman/****@RMANCAT
      • Restaure los registros (archived logs)
        • rman>restore archivelog sequence between 31966 and 32065 thread 2;
      • Revise que los mensajes de “Fetching gap sequence . . .”  en el alert_ORADR.log del standby hayan desaparecido.

CONSEJO: Para que RMAN no borre los registros  (archived logs) del primario antes de que sean aplicados al standby, añada esta instrucción a la configuración del primario en RMAN:

rman target / catalog rman/****@RMANCAT
rman>CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY;

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s