EBS - DR - Dataguard - switchover tests & flashback

Normally EBS dataguard switch over tests including the application tier switch over and switch back operations can be done using the document:

"Business Continuity for Oracle E-Business Release 12.1 Using Oracle 11g Release 2 Physical Standby Database (Doc ID 1070033.1)" , this is for R12 (12.1)

The section named "Role Transitions" is easy to implement and the documentation is accurate.

The one thing to consider is the need for running the apps tier postclone/adcfgclone.pl in case all the required steps is not done in preparing the DR environment, but except that, the documentation is perfect.

Here in this post, I will share you an alternative disaster test method, which is based on the Oracle 's Flasback database technology.

In this method, we can test our DR environments, without doing a Dataguard switchover. So it is easier to implement and it may be needed in some cases.

Here is the action plan(more or less) for accomplishing that;

On Primary DB tier:

Stop the log shipping;

alter system set log_archive_dest_state_2=defer;

On Standby DB tier:

alter database recover managed standby database cancel;

alter database flashback on;

create restore point OPEN_STANDBY guarantee flashback database;

alter database activate standby database;

alter database open;

sqlplus apps/apps_password
exec fnd_conc_clone.setup_clean;
commit;

cd $ORACLE_HOME/appsutil/bin

perl adbldxml.pl tier=db appsuser=apps

sh adconfig.sh

On Standby Apps tier:

cd $ADMIN_SCRIPTS_HOME
perl adcfgclone.pl appsTier

Start the services.

--update conc request queues and wf mailer conf. if necessary

Fail/Switch Back:
On Standby DB tier:

sqlplus "/as sysdba"
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;

FLASHBACK DATABASE TO RESTORE POINT OPEN_STANDBY;

DROP RESTORE POINT OPEN_STANDBY;

ALTER DATABASE CONVERT TO PHYSICAL STANDBY;

SHUTDOWN IMMEDIATE;
STARTUP NOMOUNT;
ALTER DATABASE MOUNT STANDBY DATABASE;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

On Primary DB Tier:
alter system set log_archive_dest_state_2=enable scope=both;

This procedure reflects the actual work that is need to be done(more or lesss), in case of a DR test.
What we do in this procedure is, we stop the managed recovery, create guaranteed flashback restore point, then activate our standby database and then configure our application tier (standby app tier) to this newly activated database and let our functional teams to test the DR environment. After the test, we restore our restore point, start the managed recovery and get back where we start.

This routine may be changed/enhanced according to the needs of the environment, but the important thing is that you get the idea...