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
