Flashback Automatico em Banco Standby

Um dos recursos do Oracle 19, 21c é que, quando um flashback ou uma recuperação pontual é executada no banco de dados principal em um Oracle Data Guard, a mesma operação também é executada no banco de dados standby.

Após uma operação de flashback ou PITR, o banco de dados principal é aberto com a opção RESETLOGS.

O RESETLOGS leva a uma nova encarnação do primário ou do PDB no primário.

O que há de novo no Oracle 19c?

O processo MRP no standby detecta a nova encarnação e move o banco de dados standby para a um novo redo desta nova encarnação e, em seguida, faz o flashback do banco de dados standby ou no pluggable database para o mesmo ponto no tempo que o primário ou o PDB no primário.

Em versões anteriores, tínhamos que obter o RESETLOGS SCN# no primário e então emitir manualmente um comando FLASHBACK DATABASE no banco de dados standby para habilitar a recuperação gerenciada e continuar com o processo de redo apply.

Além disso, outro novo recurso do Oracle 19c é que, quando criamos um ponto de restauração no banco de dados principal, ele também cria automaticamente um ponto de restauração no banco de dados de Standby

Esses pontos de restauração são chamados de Replicated Restore Points e têm o nome do ponto de restauração com o sufixo “_PRIMARY”.

No banco de dados primário, criaremos um ponto de restauração garantido.

SQL> select flashback_on from v$database;

FLASHBACK_ON
------------------
YES

SQL> create table simduts.objects as select * from all_objects;

Table created.

SQL> select count(*) from simduts.objects;

  COUNT(*)
----------
     71296


SQL> create restore point rec_grp guarantee flashback database;

Restore point created.

SQL> select name from v$restore_point;

NAME
--------------------------------------------------------------------------------
REC_GRP

Observe que o banco de dados standby, o ponto de restauração foi criado automaticamente e o nome tem o sufixo “_PRIMARY”

SQL> select flashback_on from v$database;

FLASHBACK_ON
------------------
YES

SQL>  select count(*) from simduts.objects;

  COUNT(*)
----------
     71296

SQL> select name from v$restore_point;

NAME
--------------------------------------------------------------------------------
REC_GRP_PRIMARY

No banco de dados primário, podemos ver que a coluna REPPLICATED tem o valor NO para o ponto de restauração, enquanto no banco de dados em standby o valor é SIM

Banco de dados Primário

SQL> select NAME,REPLICATED from v$restore_point;

NAME			       REP
------------------------------ ---
REC_GRP	       		NO
Banco de dados Standby

SQL> select NAME,REPLICATED from v$restore_point;

NAME			       REP
------------------------------ ---
REC_GRP_PRIMARY	       YES

Agora simulamos um caso em que um erro foi cometido e agora precisamos executar uma operação de flashback no banco de dados primário para resolver o erro. O flashback é executado no ponto de restauração criado anteriormente e, em seguida, abrimos o banco de dados com a opção RESETLOGS.

SQL> truncate table simduts.objects;

Table truncated.

SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.

SQL> startup mount;
ORACLE instance started.

Total System Global Area 1241513488 bytes
Fixed Size		    8896016 bytes
Variable Size		  335544320 bytes
Database Buffers	  889192448 bytes
Redo Buffers		    7880704 bytes
Database mounted.

SQL> flashback database to restore point rec_grp;

Flashback complete.

SQL> alter database open resetlogs;

Database altered.

O banco de dados standby é colocado no modo MOUNT e veremos que o processo MRP no banco de dados em espera iniciará e executará a operação automática de flashback no banco de dados em standby também.

SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.

SQL> startup mount;
ORACLE instance started.

Total System Global Area 1241513488 bytes
Fixed Size		    8896016 bytes
Variable Size		  318767104 bytes
Database Buffers	  905969664 bytes
Redo Buffers		    7880704 bytes
Database mounted.
 
...
...
 rfs (PID:21384): Primary database is in MAXIMUM PERFORMANCE mode
2023-03-08T22:00:30.671381+06:00
 rfs (PID:21384): Selected LNO:6 for T-1.S-3 dbid 1240291890 branch 1013527366
2023-03-08T22:00:34.853803+06:00
ARC0 (PID:22457): Archived Log entry 10 added for T-1.S-3 ID 0x6bcedc52 LAD:1
2023-03-08T22:00:34.930249+06:00
 rfs (PID:22500): Primary database is in MAXIMUM PERFORMANCE mode
2023-03-08T23:00:35.073538+06:00
 rfs (PID:22500): Selected LNO:6 for T-1.S-4 dbid 1240291890 branch 1013527366
2023-03-08T22:00:35.909833+06:00
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT  NODELAY
2023-03-08T22:00:35.910522+06:00
Attempt to start background Managed Standby Recovery process (duts)
Starting background process MRP0
2023-03-08T22:00:35.932806+06:00
MRP0 started with pid=96, OS id=25505 
2023-03-08T22:00:35.935882+06:00
Background Managed Standby Recovery process started (duts)
2023-03-08T22:00:40.940224+06:00
Serial Media Recovery started

...
...

MRP0 (PID:25505): Recovery coordinator performing automatic flashback of database to SCN:0x00000000001fcce6 (2084069)
Flashback Restore Start
Flashback Restore Complete
Flashback Media Recovery Start
2023-03-08T22:01:01.852650+06:00
Setting recovery target incarnation to 2
2023-03-08T22:01:01.852994+06:00
Serial Media Recovery started
stopping change tracking
2023-03-08T22:01:01.976765+06:00
Media Recovery Log /u01/app/oracle/fast_recovery_area/DUTS_SB/archivelog/2023-03-08/o1_mf_1_9_bkn8pkx6.arc
2023-03-08T22:01:02.142326+06:00
Resize operation completed for file# 3, old size 522240K, new size 552960K
Restore point REC_GRP_PRIMARY propagated from primary already exists
2023-03-08T22:01:02.215320+06:00
Media Recovery Log /u01/app/oracle/fast_recovery_area/DUTS_SB/archivelog/2023-03-08/o1_mf_1_10_bkn9pnf3.arc
2023-03-08T22:01:02.657960+06:00
Media Recovery Log /u01/app/oracle/fast_recovery_area/DUTS_SB/archivelog/2023-03-08/o1_mf_1_11_bkn10s6g2.arc
2023-03-08T22:01:02.795226+06:00
Media Recovery Log /u01/app/oracle/fast_recovery_area/DUTS_SB/archivelog/2023-03-08/o1_mf_1_12_bkn11cxvl.arc
2023-03-08T22:01:02.956167+06:00
Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT  NODELAY
2023-03-08T22:01:04.624321+06:00
Incomplete Recovery applied until change 2094050 time 08/03/2023 21:47:15
Flashback Media Recovery Complete

Quando vemos a mensagem “Flashback Media Recovery Complete” no banco de dados standby no alert.log, agora podemos abrir o banco de dados standby.

Observe que a configuração do Data Guard Broker não está mostrando nenhum erro e não precisamos executar nenhuma etapa manual no banco de dados standby para habilitar a configuração após o flashback do banco de dados primário.
 

SQL> ALTER DATABASE OPEN;

Database altered.

DGMGRL> show configuration;

Configuration - duts_dg

  Protection Mode: MaxPerformance
  Members:
  duts    - Primary database
    duts_sb - Physical standby database 

Fast-Start Failover:  Disabled

Configuration Status:
SUCCESS   (status updated 54 seconds ago)

Espero que este artigo ajude !!!

Disclaimer: “The postings on this site are my own and don’t necessarily represent may actual employer positions, strategies or opinions. The information here was edited  to be useful for general purpose, specific data and identifications was removed to allow reach generic audience and to be useful