Oracle 19c New Feature Restore Point Replication and Automatic Flashback of Standby Database!
Hi DBA Connections,
In this video, Coolest new features in Oracle 19c is that either when a flashback or point-in-time recovery is performed on the primary database in an Oracle Data Guard configuration, the same operation is also performed on the standby database as well.
Another new Oracle 19c feature is that when we create a Restore Point on the primary database, it will automatically create a restore point as well on the standby database.
Let us have a look at this feature in action in this video.
Steps here:
Following a flashback or PITR operation, the primary database is then opened with the RESETLOGS option.
The RESETLOGS leads to a new incarnation of the primary or the PDB in the primary.
What’s new then in Oracle 19c?
The MRP process on the standby detects the new incarnation and moves the standby database to the new ‘branch’ of redo and then flashes back the standby or the pluggable database on the standby to the same point in time as that of the primary or the PDB on the primary.
In earlier releases, we had to obtain the RESETLOGS SCN# on the primary and then manually issue a FLASHBACK DATABASE command on the standby database to enable managed recovery and continue with the redo apply process.
Another new Oracle 19c feature is that when we create a Restore Point on the primary database, it will automatically create a restore point as well on the standby database.
These restore points are called Replicated Restore Points and have the restore point name suffixed with a “_PRIMARY”.
Let us have a look at this feature in action.
On the primary database we will create a guaranteed restore point.
SQL> select flashback_on from v$database;
SQL> create table test.allobjects as select * from all_objects;
SQL> select count(*) from test.allobjects;
SQL> create restore point SRLABPLUG_GRP guarantee flashback database;
SQL> select name from v$restore_point;
Note that on the standby database, the restore point has been automatically created and the name has the suffix _PRIMARY
SQL> select flashback_on from v$database;
SQL> select count(*) from test.allobjects;
SQL> select name from v$restore_point;
On the primary database we can see that the REPLICATED column has the value NO for the restore point while on the standby database the value is YES
SRLAB_Primary:
SQL> select NAME,REPLICATED from v$restore_point;
SRLAB_Standby:
SQL> select NAME,REPLICATED from v$restore_point;
We now simulate a case where a human error has been made and we now need to perform a flashback operation on the primary to resolve the human error.
Flashback is performed to the restore point created earlier and we then open the database with the RESETLOGS option.
SQL> truncate table test.allobjects;
SQL> shutdown immediate;
SQL> startup mount;
SQL> flashback database to restore point SRLABPLUG_GRP;
SQL> alter database open resetlogs;
The standby database is placed in MOUNT mode and we will see that the MRP process on the standby database will start and perform the automatic flashback operation on the standby database as well.
SQL> shutdown immediate;
SQL> startup mount;
Check the alert log for both side (primary and standby)
When we see the message “Flashback Media Recovery Complete” in the standby database alert log, we can now open the standby database.
SQL> ALTER DATABASE OPEN; It will be opened read only mode for checking flashback database as well as the table, before that we need to stop MRP
Regards,
Ramesh
Please follow me on:
DBA BLOG:https://www.sachinrameshoracledbablog.com
YOUTUBE: https://www.youtube.com/oraclef1
TWITTER: https://twitter.com/sachinrameshdba
FACEBOOK: https://www.facebook.com/rameshkumar.krishnamoorthy.9
LINKEDIN:https://www.linkedin.com/in/ramesh-kumar-krishnamoorthy-3a67ba69/
Email: oralclehelplines@gmail.com
Post a Comment: