What Happens with Standby When Primary Database Is Flashback

Many times we get a request from the application team to flashback the database and during that
time several questions comes in our mind like :
 How to flashback a database
 If the database has a standby database, then what will happen with standby database
 If the database has standby database, then which database we’ll flashback first primary or
standby
 How the standby database will start behave after flashback
Prior to the release of oracle 19c Database if somehow, we’ve to flashback the database, then we’ve
to follow the old method of flashback the primary first and then standby.

If your database is running till 12c version then please follow Doc ID 2338328.1

from oracle 19c onward since oracle has provided the feature of automatic creation of
restore point in standby database, So the flashback will also be done automatically in standby side
whenever we flashback our primary database even though we’ve to remember certain point prior
to start flashback database at a container level.
In this post, we’ll try to create one datafile and flashback the Primary database and will also
observe that the standby database will automatically get flashback up to the scn of guarantee
restore point as soon as we open the primary database with resetlogs option.

Step 1st: Perform some basic checks & create guarantee restore point

Prior to create guarantee restore point make sure that the flashback must be ON in both
primary & standby database otherwise automatic flashback will not occur

NAME TYPE VALUE

------------------------------------ ----------- --------------------------
db_unique_name string US_PRIM
SQL> select name,database_role,open_mode,flashback_on from v$database;
NAME DATABASE_ROLE OPEN_MODE FLASHBACK_ON
--------- ---------------- -------------------- ------------------
US_PRIM PRIMARY READ WRITE YES
SQL> set lines 300 colsep '|'

SQL> col tablespace_name for a30

SQL> col file_name for a80

SQL> col bytes 999999.99999

SQL> col bytes for 999999.99999

SQL> col con_id for 9999

SQL> select con_id,tablespace_name,file_name,bytes/1024/1024 "SIZE_IN_MB" from

cdb_data_files where tablespace_name='USERS';

CON_ID|TABLESPACE_NAME |FILE_NAME
|SIZE_IN_MB

------|------------------------------|-------------------------------------------------
---------------------------------------------------|----------

1|USERS
|/u01/app/oracle/oradata/US_PRIM/datafile/o1_mf_users_lrj30xtc_.dbf
| 5

3|USERS
|/u01/app/oracle/oradata/US_PRIM/0D40A9D4D52D26BDE0630901A8C0E8F7/datafile/o1_mf_users_
lrj559wq_.dbf | 5

SQL> create restore point FLSHBK_DB guarantee flashback database;

Restore point created.
SQL> col name for a15
SQL> col time for a40

SQL> col preserved for a15

SQL> col GUARANTEE_FLASHBACK_DATABASE for a25

SQL> col con_id for 99999

SQL> select con_id,name,time,preserved,GUARANTEE_FLASHBACK_DATABASE from

v$restore_point;
CON_ID|NAME |TIME |PRESERVED |GUARANTEE_FLASHBACK_DATABSE

------|------------|----------------- ------------- |-------------|----------------

0|FLSHBK_DB |24-DEC-23 11.03.29.000000000 PM |YES |YES

SQL> alter tablespace users add datafile

'/u01/app/oracle/oradata/US_PRIM/datafile/USERS02.dbf' size 10m;

Tablespace altered.

SQL> select con_id,tablespace_name,file_name,bytes/1024/1024 "SIZE_IN_MB" from

cdb_data_files where tablespace_name='USERS';

CON_ID|TABLESPACE_NAME |FILE_NAME
|SIZE_IN_MB

------|------------------------------|----------------------------------------------------------

3|USERS
|/u01/app/oracle/oradata/US_PRIM/0D40A9D4D52D26BDE0630901A8C0E8F7/datafile/o1_mf_users_lrj559wq_
.dbf | 5
 1|USERS
|/u01/app/oracle/oradata/US_PRIM/datafile/o1_mf_users_lrj30xtc_.dbf |
5

1|USERS |/u01/app/oracle/oradata/US_PRIM/datafile/USERS02.dbf
| 10

Step 2nd: Verify if the guarantee restore point created on the standby side too & you can also
verify that the datafile also got created in standby database only if standby_file_management
parameter is set to AUTO
SQL> select con_id,name,time,preserved,GUARANTEE_FLASHBACK_DATABASE from
v$restore_point;
CON_ID|NAME |TIME |PRESERVED |GUARANTEE_FLASHBACK_DATABSE

------|------------|----------------- ------------- |-------------|----------------

0|FLSHBK_DB_PRIMARY |24-DEC-23 11.03.29.000000000 PM |NO |NO

The downside of automatic restore point is that it’ll create as a normal restore point in
standby side which means that after some time it’ll remove from the standby database, so we
need to keep in mind about restore point whenever the role transition will happen

SQL> select con_id,tablespace_name,file_name,bytes/1024/1024 "SIZE_IN_MB" from

cdb_data_files where tablespace_name='USERS';

CON_ID|TABLESPACE_NAME |FILE_NAME
|SIZE_IN_MB

------|------------------------------|-------------------------------------------------
---------------------------------------------------|----------

3|USERS
|/u01/app/oracle/oradata/IND_DR/0D40A9D4D52D26BDE0630901A8C0E8F7/datafile/o1_mf_users_l
rj9vyp7_.dbf | 5

1|USERS
|/u01/app/oracle/oradata/IND_DR/datafile/o1_mf_users_lrj9r4n0_.dbf
| 5
1|USERS
|/u01/app/oracle/oradata/IND_DR/datafile/o1_mf_users_lrjv1qy9_.dbf
| 10

Step 3rd: Create Blackout at the database level for both primary & standby
In a real time environment, we’ve to create blackout for primary & standby database both, so that
we’ll not get the unnecessary database’s alert because in a business the alert noise also plays a
major role since on the basis of that we also try to figure it out that how our database,alerts & their
jobs are streamline , So creating a blackout is one the most important step while flashback a
database.

Step 4th: Verify If Standby database Is In Sync With Primary Or Not

THREAD |Last Sequence Received|Last Sequence Applied|Difference
---------- |----------------------|---------------------|----------
1 | 25 | 25 | 0
Step 5th: If DB is in sync, then bring the standby database in mount mode

If the database is running in read-only mode then cancel the MRP and start the standby in
mount mode,otherwise just stop the MRP

NAME TYPE VALUE

------------------------------------ ----------- ------------------------------

db_unique_name string IND_DR

SQL> select name,database_role,open_mode,flashback_on from v$database;

NAME DATABASE_ROLE OPEN_MODE FLASHBACK_ON

--------- ---------------- -------------------- ------------------

US_PRIM PHYSICAL STANDBY READ ONLY WITH APPLY YES

SQL> shut immediate

Database closed.
Database dismounted.
ORACLE instance shut down.
SQL>
SQL> startup mount
ORACLE instance started.
Total System Global Area|1728050736|bytes
Fixed Size | 9135664|bytes
Variable Size | 402653184|bytes
Database Buffers |1308622848|bytes
Redo Buffers | 7639040|bytes
Database mounted.

SQL> alter database recover managed standby database cancel;

Database altered.

Step 6th: If DB is in sync, then bring down primary database & start it in mount mode
SQL> shut immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.
Total System Global Area|1728050736|bytes
Fixed Size | 9135664|bytes
Variable Size | 436207616|bytes
Database Buffers |1275068416|bytes
Redo Buffers | 7639040|bytes
Database mounted.

Step 7th: Flashback the primary database

Note A. Prior to start flashback operation cross verify that we should have latest L0 backup so
that in case of any issue at least we can restore our database using backup.
Note B. In Case Of RAC, please shutdown all the database’s instance and bring up only one
instance to perform flashback

SQL> flashback database to restore point FLSHBK_DB;

Flashback complete.

Alert log of Primary Database

flashback database to restore point FLSHBK_DB

2023-12-24T23:11:44.274007+05:30

Flashback Restore Start

Deleted file /u01/app/oracle/oradata/US_PRIM/datafile/USERS02.dbf

Flashback: deleted datafile #13 in tablespace #4 of pdb #1 from control file.

Flashback Restore Complete

Flashback Media Recovery Start

Started logmerger process

2023-12-24T23:11:45.576374+05:30

Incomplete Recovery applied until change 2207231 time 12/24/2023 23:03:29

2023-12-24T23:11:45.620124+05:30

Flashback Media Recovery Complete

Completed: flashback database to restore point FLSHBK_DB

Step 8th: Once Flashback is done in the primary database then login Into Standby database &
Start the MRP.
SQL> alter database recover managed standby database cancel;
Database altered.
Step 9th: Since flashback is an incomplete recovery, start the primary database
with open resetlogs option.
SQL> alter database open resetlogs;
Database altered.

As soon as we open the primary database with resetlogs we can see in the alert log of standby
database that the flashback also performed in standby database automatically.

Alert Log of Standby Database

Flashback Restore Start

2023-12-24T23:18:37.472870+05:30

-----

Deleted Oracle managed file /u01/app/oracle/oradata/IND_DR/datafile/o1_mf_users_lrjv1qy9_.dbf

Flashback: deleted datafile #13 in tablespace #4 of pdb #1 from control file.

Flashback Restore Complete

Flashback Media Recovery Start

2023-12-24T23:19:24.731575+05:30

Setting recovery target incarnation to 2

2023-12-24T23:19:28.898160+05:30

Incomplete Recovery applied until change 2207230 time 12/24/2023 23:03:29

2023-12-24T23:19:57.146216+05:30

Flashback Media Recovery Complete

2023-12-24T23:19:57.441151+05:30

Step 10th: Verify if added datafile has been delete from both primary & standby
SQL> select con_id,tablespace_name,file_name,bytes/1024/1024 "SIZE_IN_MB" from
cdb_data_files where tablespace_name='USERS';

In A real time environment we release the database for the application team after
flashback to validate their data

Step 11th : Make sure services and pdbs are all up and running afer flashback