Oracle 19c Restore Point Replication From Primary To Standby

Oracle 19c Restore Point Replication From Primary To Standby

Primary Side:-

~~~~~~~~~~~~

SQL> SELECT database_role, open_mode FROM v$database;

DATABASE_ROLE        OPEN_MODE
—————-               ——————–

PRIMARY                      READ WRITE

SQL> create restore point FB_Restore_poiint  guarantee flashback database;
Restore point created.

SQL> select SCN, GUARANTEE_FLASHBACK_DATABASE, TIME, NAME, REPLICATED from v$restore_point;

SCN     GUARANTEE_FLASHBACK_DATABASE  TIME NAME  REPLICATED
———- —————————— —————————————- ————————-
2443446     YES  20-OCT-19 04.15.22.000000000 PM FB_Restore_poiint NO

PRIMARY - Alertlog
~~~~~~~~~~

2022-11-20T16:15:22.184171+05:30
Created guaranteed restore point FB_Restore_poiint

Standby Side:-

~~~~~~~~~~~~~

SQL> SELECT database_role, open_mode FROM v$database;

DATABASE_ROLE                 OPEN_MODE
—————-                        ——————–
PHYSICAL STANDBY      READ ONLY WITH APPLY

SQL> select SCN, GUARANTEE_FLASHBACK_DATABASE, TIME, NAME, REPLICATED from v$restore_point;

SCN     GUARANTEE_FLASHBACK_DATABASE  TIME NAME  REPLICATED
———- —————————— —————————————- ————————-
2443446 NO  20-OCT-19 04.15.22.000000000 PM FB_Restore_poiint_PRIMARY YES

SQL> select status,instance_name,database_role,protection_mode ,flashback_on from v$database,v$instance;

STATUS INSTANCE_NAME DATABASE_ROLE PROTECTION_MODE  FLASHBACK_ON
———— —————- —————- —————————————————————————-
OPEN               delhi       PHYSICAL STANDBY                         MAXIMUM AVAILABILITY  YES
 
    

        The naming convention for a replicated restore point uses the name of the restore point on the primary database suffixed with _PRIMARY. 

        If a replicated restore point with the same name exists on the standby database, then a replicated restore point is not created. 

    For example, when you create a restore point named PRE_MYTBS on the primary database, the replicated restore point is named FB_Restore_poiint_PRIMARY. 

    When you delete a restore point on the primary, the corresponding replicated restore point on the standby is also deleted.

 

Automatic Flashback of a Mounted Standby After a Primary RESETLOGS Operation

 

Automatic Flashback of a Mounted Standby After a Primary RESETLOGS Operation

A standby database that is in a mounted state can automatically follow the primary database after a RESETLOGS operation on the primary. 

This simplifies standby management after a RESETLOGS operation on the primary.

When flashback or point-in-time recovery is performed either on a primary database or a PDB in the primary database, the primary database or PDB is moved to a previous point in time and the primary is then opened with the RESETLOGS option.

 A new incarnation of the primary or the PDB in the primary is created. For the standby to automatically follow the primary, the MRP performs the following actions:

• detects the new incarnation

• flashes back the standby or the PDB on the standby to the same point in time as that of the primary or the PDB on the primary

• restarts the standby recovery and moves the standby to the new branch of redo

The flashback operation will succeed only when the standby database has sufficient flashback data.

If you do not want the standby to automatically follow the primary, either keep the standby database in OPEN mode or stop the MRP process on the standby.

If the standby database is open in read only mode, the corresponding error messages are recorded in the alert log. When you restart the MRP after closing the physical standby, the recovery process automatically flashes back the standby database and continues to apply the new branch of redo.

REFER:-

https://docs.oracle.com/en/database/oracle/oracle-database/19/sbydb/managing-oracle-data-guard-physical-standby-databases.html#GUID-252097AC-3070-43B6-88D8-919AE27F97AD

Oracle 19c Restore Point Replication From Primary To Standby

Oracle 19c Restore Point Replication From Primary To Standby   

Oracle Database Release 19c New Feature

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

• The process of flashing back a physical standby to a point in time that was captured on the primary is simplified by automatically replicating restore points from primary to the standby.
• These restore points are called replicated restore points.
• Irrespective of whether a restore point on the primary database is a guaranteed restore point or a normal restore point, the corresponding replicated restore point is
  always a normal restore point.

NOTE: Starting from 19c, be aware that standby can automatically perform flashback in response to similar operation on primary. Refer:

Automatic Flashback of a Mounted Standby After a Primary RESETLOGS Operation

Automatically replicates restore points from a primary database to the standby database Conditions:-

• COMPATIBLE initialization parameter for both the primary database and the standby database is set to 19.0.0 or higher
• Primary database is open
• A restore point that is created on a primary database when the primary is in mount mode is not replicated. This restriction is because the restore point information is replicated though the redo.

 

CREATE GUARANTEED RESTORE POINT

1. Stop redo transport and redo apply

a)If broker is not configured:

On primary database:
SQL> alter system set log_archive_dest_state_n='defer'; =====>>>>>replace n with the corresponding number for remote destinations

On standby database:
SQL> alter database recover managed standby database cancel;

b)If broker is in place:

DGMGRL> edit database chicago set state = 'TRANSPORT-OFF';
DGMGRL> edit database boston set state = 'APPLY-OFF';

2. Set GRP in standby database

On standby database:
SQL> CREATE RESTORE POINT grp_dg GUARANTEE FLASHBACK DATABASE;

3. Set GRP in primary database

On primary database:
SQL> CREATE RESTORE POINT grp_dg GUARANTEE FLASHBACK DATABASE;

4. Enable redo transport and redo apply

a)If broker is not configured:

On primary database:
SQL> alter system set log_archive_dest_state_n='enable'; =====>>>>>replace n with the corresponding number for remote destinations

On standby database:
SQL> alter database recover managed standby database using current logfile disconnect;

b)If broker is in place:

DGMGRL> edit database chicago set state = 'TRANSPORT-ON';
DGMGRL> edit database boston set state = 'APPLY-ON';

 

FLASHBACK DATABASE TO GUARANTEED RESTORE POINT

1. Stop redo transport and redo apply

a)If broker is not configured:

On primary database:
SQL> alter system set log_archive_dest_state_n='defer'; =====>>>>>replace n with the corresponding number for remote destinations

On standby database:
SQL> alter database recover managed standby database cancel;

b)If broker is in place:

DGMGRL> edit database chicago set state = 'TRANSPORT-OFF';
DGMGRL> edit database boston set state = 'APPLY-OFF';

2. Shutdown Primary Database and start one instance in mount stage

3. Flashback primary database to restore point

On primary database:
SQL> flashback database to RESTORE POINT grp_dg;
SQL> alter database open resetlogs;

4. Shutdown Standby database and start one instance in mount stage

5. Flashback standby database

On standby database:
SQL> flashback database to RESTORE POINT grp_dg;

6. Enable redo transport and redo apply

a)If broker is not configured:

On primary database:
SQL> alter system set log_archive_dest_state_n='enable'; =====>>>>>replace n with the corresponding number for remote destinations

On standby database:
SQL> alter database recover managed standby database using current logfile disconnect;

b)If broker is in place:

DGMGRL> edit database chicago set state = 'TRANSPORT-ON';
DGMGRL> edit database boston set state = 'APPLY-ON';

7. If Active Data Guard licence is used, open read only the standby database

 

DROP GUARANTEED RESTORE POINT

1. Stop redo transport and redo apply

a)If broker is not configured:

On primary database:
SQL> alter system set log_archive_dest_state_n='defer'; =====>>>>>replace n with the corresponding number for remote destinations

On standby database:
SQL> alter database recover managed standby database cancel;

b)If broker is in place:

DGMGRL> edit database chicago set state = 'TRANSPORT-OFF';
DGMGRL> edit database boston set state = 'APPLY-OFF';

2. Drop GRP in primary database

On primary database:
SQL> drop RESTORE POINT grp_dg;

3. Drop GRP in standby database

Ensure the standby database is in mount stage and drop GRP:

SQL> drop restore point grp_dg;

If Active Data Guard licence is used, open read only the standby database after dropping the GRP

4. Enable redo transport and redo apply

a)If broker is not configured:

On primary database:
SQL> alter system set log_archive_dest_state_n='enable'; =====>>>>>replace n with the corresponding number for remote destinations

On standby database:
SQL> alter database recover managed standby database using current logfile disconnect;

b)If broker is in place:

DGMGRL> edit database chicago set state = 'TRANSPORT-ON';
DGMGRL> edit database boston set state = 'APPLY-ON';

https://docs.oracle.com/en/database/oracle/oracle-database/19/sbydb/managing-oracle-data-guard-physical-standby-databases.html#GUID-252097AC-3070-43B6-88D8-919AE27F97AD