Re-sincronizando o Data Guard

Re-sincronizando o Data Guard

Quando utilizamos Standby Databases, um erro que pode acontecer (mas não deve) é que em algum momento você pode ter os chamados “GAPs” nas threads de REDO log e então nosso Data Guard para de funcionar e no alert.log você poderá ver uma mensagem como essa.

Fetching gap sequence in thread 1, gap sequence 13809-13820

Explicando melhor, isso acontece porque o Data Guard funciona a partir das threads de REDO log que são enviadas do banco de dados principal para o banco de dados standby sempre que ocorre um switch de log.

Se por algum motivo a comunicação entre os servidores for interrompida, durante esse tempo de inatividade o banco de dados principal vai trabalhar e gerar os archive logs normalmente e quando a comunicação for re-estabelecida, esses archive logs serão utilizados para sincronizar as bases.

Agora imagine se por algum motivo você fica 24 horas ou mais sem a comunicação entre os servidores, para fazer esse sincronismo os dois servidores serão sobrecarregados devido ao alto volume de informações que precisam ser enviadas de um lado para outro, além disso, imagine se quando a comunicação for re-estabelecida, um backup já tenha sido executado no servidor primário com a opção “BACKUP DATABASE PLUS ARCHIVELOG DELETE ALL INPUT” ou algo parecido?

Agora você não tem mais os archive logs no seu servidor e no alert.log do servidor Standby você vai receber a mensagem:

Fetching gap sequence in thread 1, gap sequence 13809-13820

Para resolver esse tipo de situação, podemos utilizar um backup incremental para re-sincronizar as bases de dados, mais aí vem a pergunta:

Pergunta: Um backup incremental a partir de onde?

Resposta: A partir do último SCN (System Change Number) do banco de dados Standby, pois será exatamente a partir da ultima informação que foi gravada no servidor Standby e para fazer isso execute o passo a passo abaixo:

1 – Se o processo de Redo Apply (MRP media recovery process) estiver ativo pare-o:

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

2 – Verifique no servidor Standby qual foi o ultimo SCN com o select abaixo:

SQL>  SELECT CURRENT_SCN FROM V$DATABASE;
CURRENT_SCN
-----------
8885952

3 – Agora que você tem o valor do ultimo SCN do banco de dados Standby, no banco de dados principal faça um backup incremental a partir dele:

RMAN> run {
allocate channel d1 type disk;
allocate channel d2 type disk;
backup incremental from scn 8885952 database format '/tmp/dba/bkups/GAPDB_%U';
release channel d1;
release channel d2;
}

4 – Terminado o backup, crie um standby control file no servidor primario:

SQL> ALTER DATABASE CREATE STANDBY CONTROL FILE AS ‘/tmp/dba/bkups/STD_CONTROL.ctl’

5 – Copie os arquivos de backup junto com o novo standby control file para o servidor standby, nos mesmos diretórios onde foram criados no servidor primário.

6 – Re-inicie o servidor standby em modo mount e em seguida acesse o RMAN e execute os comandos “CATALOG START WITH” e “RECOVER DATABASE NOREDO”.

sqlplus / as sysdba
SQL*Plus: Release 11.2.0.2.0 Production on Mon Jul 16 11:39:22 2012
Copyright (c) 1982, 2010, Oracle.  All rights reserved.
Connected to an idle instance
SQL> startup mount;
ORACLE instance started.
Total System Global Area 2137886720 bytes
Fixed Size                  2228200 bytes
Variable Size             503316504 bytes
Database Buffers         1627389952 bytes
Redo Buffers                4952064 bytes
Database mounted.
SQL> exit

rman target /
Recovery Manager: Release 11.2.0.2.0 - Production on Mon Jul 16 11:39:48 2012
Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.
connected to target database: BPMPRD01 (DBID=572426427, not open)
RMAN> CATALOG START WITH '/tmp/dba/bkups/';
RMAN> RECOVER DATABASE NOREDO;

7 – Se não houve nenhum erro em todo neste processo, os servidores já estão re-sincronizados, agora basta re-ativar o processo de Redo Apply (MRP media recovery process) para que tudo possa a voltar ao normal.

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;