USING STANDBY DB FOR TESTING

Figure 1 provides an overview of how a physical standby database can be

temporarily activated as a read/write clone of the primary database and reverted
back to its role as a physical standby database using Flashback Database. This
process can executed any number of times if necessary.

Figure 1: Opening Physical Standby Database in Read/Write for Testing

It is assumed that a primary and one physical standby database is already

configured in order to perform the steps described in this guide. The examples used
in this guide will make use of the Oracle Data Guard configuration described in the
article below:

 Data Guard Configuration Example - (Oracle 10g, Physical Standby)

Enable Flashback Database on the Physical Standby Database

The first step is to configure the physical standby database to use flashback
logging for Flashback Database operations. Although not a requirement for
this exercise, it is best practice to also enable Flashback Database on the the
primary.

1. In order to use Flashback Database, the physical database must be

running in Archive Log Mode. Given the fact that this is a Data Guard
configuration, both the primary and physical standby database will
already be running in archive log mode and no action is required.
 SQL> archive log list
Database log mode Archive Mode
Automatic archival Enabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 208
Next log sequence to archive 0
Current log sequence 210

2. Flashback Database requires that the flashback logs reside in the Flash Recovery
Area (FRA). Although the FRA may already be configured for your environment, the
flashback logs can significantly increase FRA usage. It is not unheard of to double
the size of the FRA to utilize Flashback Database.

If a FRA does not exist, it will need to be created. For example, run the following
statements on the physical standby database to configure a 32GB flash recovery
area in the /u03/flash_recovery_area directory with a retention time of 24 hours:

SQL> alter system set db_recovery_file_dest='/u03/flash_recovery_area';

SQL> alter system set db_recovery_file_dest_size=32g;
SQL> alter system set db_flashback_retention_target=1440;

The size and location of the FRA and the Flashback Database retention policy time
listed above should be modified for your environment.

3. Stop Redo Apply on the physical standby database and verify it is in MOUNT mode.

SQL> alter database recover managed standby database cancel;

SQL> select open_mode from v$database;

OPEN_MODE
----------
MOUNTED

4. Turn on Flashback Logging.

SQL> alter database flashback on;

5. Place the physical standby database back into recovery mode by

starting Redo Apply.

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

Activate the Physical Standby

Database as a Read/Write Clone of
the Primary Database
Perform the following steps to activate the physical standby database as a
production database clone which can be used for QA testing, development
fixes, or reporting purposes. The clone database will be resynchronized back
with the primary database and returned to its original state as a physical
standby database in the next section.

In Oracle Database 10g, all redo application is paused while the

  database is activated. The standby will not receive any redo from the
primary database while it is opened in read/write mode and therefore
cannot provide disaster protection. It is recommended that there be at
least two physical standby databases participating in the configuration
so that the primary database remains protected against data loss.

1. Prepare the physical standby database to be activated.

On the physical standby database, stop Redo Apply and create a

restore point.

SQL> alter database recover managed standby database cancel;

Database altered.

SQL> create restore point before_open_standby guarantee flashback database;

Restore point created.

When you create a guaranteed restore point, you associate an easy-to-

remember name such as before_open_standby with a timestamp or SCN
so that you can later flash back the database to a name instead of
specifying an exact SCN or time.

SQL> select scn, storage_size, time, name from v$restore_point;

SCN STORAGE_SIZE TIME NAME

---------- ------------ --------------------------------- --------------------
3497333 15941632 23-FEB-11 10.43.43.000000000 AM
BEFORE_OPEN_STANDBY

2. Prepare the primary database to have the physical standby be

diverged.
o Prepare the primary database to be split from the physical
standby by archiving the current log file. This step is necessary
in order to write the SCN of the restore point (created in step 1)
to the redo stream and archive it to the physical standby
database. To accomplish this, switch logs on the primary
database.

SQL> alter system archive log current;

 System altered.

o When using standby redo log files, this step is essential to

ensure the database can be properly flashed back to the restore
point.
o On the primary database (on all instances if this is a Real
Applications Cluster), defer the archival of redo data to the
destination associated with the physical standby database that
will be opened, and switch logs one more time to stop redo
transport.

SQL> alter system set log_archive_dest_state_2=defer;

System altered.

SQL> alter system switch logfile;

System altered.

3. Activate the physical standby database.

On the physical standby database, perform the following steps:

o Activate the physical standby database.

SQL> alter database activate standby database;

Database altered.

o Skip the next statement if the physical standby has not been
opened read-only since the instance was last started.

SQL> startup mount force;

ORACLE instance started.

Total System Global Area 1610612736 bytes

Fixed Size 2084296 bytes
Variable Size 385876536 bytes
Database Buffers 1207959552 bytes
Redo Buffers 14692352 bytes
Database mounted.

o The last step is to set the protection mode to maximum

performance and open the database for read/write access.

SQL> alter database set standby database to maximize performance;

 Database altered.

SQL> alter database open;

Database altered.

o If the standby database that was opened read/write temporarily

has remote archive log destinations, you should disable them. In
this way, the read/write testing or reporting database will not
propagate its temporary changes to other standby databases in
the original Data Guard environment.

SQL> alter system set log_archive_dest_state_2=defer;

System altered.

After the standby database is activated, its protection mode is downgraded to

the maximum performance mode, because there is no standby database
configured to protect the database against data loss while it is temporarily
activated as a production database. Note that this protection mode setting
does not affect the protection mode of the original primary database, it
affects only the activated standby database.

When the activated standby database is converted back to a physical

standby database, its protection mode is automatically changed to match
that of the original primary database.

Use the Activated Database For

Testing or Reporting
Once the physical standby database has been activated, it is a full-blown
clone of the primary database. You may perform QA testing, run reports, fix
bugs, test new code, or create objects on the new activated database for as
long as needed, independent of the primary database.

While the database is activated, it is not receiving redo data from the
primary database and cannot provide disaster protection. It is recommended
that there be at least two physical standby databases participating in the
configuration so that the primary database remains protected against data
loss.

Also, any results stored in the activated database will be lost when you later
flash back the database to before the activation time. Results that should be
saved must be copied or exported out of the activated database before
flashing it back.
Revert Physical Standby Database
Back To Its Original State
After testing is completed, you need to resynchronize the activated database
with the primary database. Issue the following statements on the activated
database to quickly flash it back to the guaranteed restore point created
earlier (before_open_standby) and resynchronize it with the primary database.

1. Revert Physical Standby Database using Flashback Database.

SQL> startup mount force;

ORACLE instance started.

Total System Global Area 1610612736 bytes

Fixed Size 2084296 bytes
Variable Size 385876536 bytes
Database Buffers 1207959552 bytes
Redo Buffers 14692352 bytes
Database mounted.

SQL> flashback database to restore point before_open_standby;

Flashback complete.

SQL> alter database convert to physical standby;

Database altered.

SQL> startup mount force;

ORACLE instance started.

Total System Global Area 1610612736 bytes

Fixed Size 2084296 bytes
Variable Size 385876536 bytes
Database Buffers 1207959552 bytes
Redo Buffers 14692352 bytes
Database mounted.

SQL> drop restore point before_open_standby;

Restore point dropped.

2. Catch up the standby database to the primary database.

The method you use in this step will depend on how far the activated
standby database lags behind the primary database in its application
of redo data.
 o Let archive gap resolution fetch all missing archived redo
log files and allow Redo Apply to apply the gap.

If the activated database has not fallen too far behind the
original primary database, issue the following statement on the
standby database to resynchronize it with the primary database
and restart Redo Apply. For example:

SQL> alter system set log_archive_dest_state_2=enable scope=both;

System altered.

SQL> alter database recover managed standby database using current

logfile disconnect;

Database altered.

Then, go to step 3.

o Create an incremental backup on the primary and apply it

to the standby.

If the activated database has fallen too far behind the original
primary database (for example, if there are not sufficient log files
available), you can take an incremental backup from the
primary database and apply it to the standby database.

The following guide provides the steps necessary on use an

RMAN incremental backup to roll forward and resynchronize a
physical standby database that lags far behind the primary
database:

 Using RMAN Incremental Backups to Roll Forward a

Physical Standby Database (Oracle 10g)

If the standby database lags very far behind the primary

  database, it may be quicker to apply an incremental
backup created from the primary database.

After you apply an incremental backup to the standby database,

you typically need to apply more redo to the standby database to
activate the physical standby database again for read/write
testing or reporting purposes. More specifically, you might need
to apply the redo generated by the primary database while the
incremental backup was taken. Otherwise, issuing an ALTER
DATABASE ACTIVATE STANDBY DATABASE will return an error.

3. Re-enable archiving to the physical standby database destination.

 On the primary database, issue the following statement to re-enable
archiving to the physical standby database:

SQL> alter system set log_archive_dest_state_2=enable scope=both;

System altered.

SQL> alter database recover managed standby database cancel;

Database altered.

SQL> create restore point before_open_standby guarantee flashback database;

Restore point created.

SQL> select scn, storage_size, time, name from v$restore_point;

SCN STORAGE_SIZE

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

TIME

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

NAME

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

1.0340E+13 1073741824

14-OCT-16 03.08.34.000000000 PM

BEFORE_OPEN_STANDBY

SQL> col TIME format a30

SQL> col NAME format a30

SQL> select scn, storage_size, time, name from v$restore_point;

SCN STORAGE_SIZE TIME

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

NAME

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

1.0340E+13 1073741824 14-OCT-16 03.08.34.000000000 P

BEFORE_OPEN_STANDBY

SQL> set line 200

SQL> select scn, storage_size, time, name from v$restore_point;

SCN STORAGE_SIZE TIME NAME

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

1.0340E+13 1073741824 14-OCT-16 03.08.34.000000000 P

BEFORE_OPEN_STANDBY

SQL> col time format a40

SQL> select scn, storage_size, time, name from v$restore_point;

SCN STORAGE_SIZE TIME NAME

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

1.0340E+13 1073741824 14-OCT-16 03.08.34.000000000 PM

BEFORE_OPEN_STANDBY
SQL>