Validate DR Readiness

Review best practices for disaster recovery readiness and verify your disaster recovery setup for planned and unplanned events.

About DR Readiness

Review best practices for disaster recovery (DR) readiness.

Use Active Data Guard to offload read-only workload to the standby database to provide continuous, application-level validation that the standby is ready for production. This provides a level of assurance in addition to continuous Oracle block-level validation performed by Oracle Data Guard apply processes.

Use a snapshot standby database to create an exact replica of a production database for development and testing purposes. Periodically place the standby in read/write mode (using Data Guard Snapshot Standby) to validate its readiness to support read-write production workloads. A snapshot standby may also be used for a final level of functional and performance testing of patches and upgrades since the DR system size is similar to the production system. A Snapshot Standby continues to receive redo from the primary database where it is archived for later use, which provides data protection at all times. However, Recovery time (RTO) will be extended by the amount of time required to convert the Snapshot Standby back to the standby database if a failover is required while testing is in progress. Additional storage is required for the fast recovery area when a standby is in snapshot mode (to hold archived redo received from the primary production database for later use and current redo and flashback logs generated by the snapshot standby).

The following are some of the benefits of using a snapshot standby database:

It provides an exact replica of a production database for development and testing while maintaining data protection at all times. You can use the Oracle Real Application Testing option to capture the primary database workload and then replay it for test purposes on the snapshot standby.
It is easily refreshed to contain current production data by converting to a physical standby and resynchronizing.

Convert the Standby Database to a Snapshot Standby

When you want an exact replica of a production database, you can use Oracle Data Guard Broker to convert the physical standby database to a snapshot standby database and validate the failover.

A snapshot standby is a fully updatable standby database that is created from a physical standby database. On snapshot standby databases, the redo data is received, but not applied until the snapshot standby database is converted back to a physical standby database.

The following are a couple of benefits to using a snapshot standby database:

The snapshot standby provides an exact replica of a production database for development and testing purposes while maintaining data protection at all times. You can use the Oracle Real Application Testing option to capture the primary database workload and then replay it for test purposes on the snapshot standby.
You can easily refresh the snapshot standby to contain current production data by converting to a physical standby and resynchronizing.

The Oracle Data Guard command-line interface (DGMGRL) enables you to manage a Oracle Data Guard broker configuration and its various members directly from the command-line interface.

Log into a DGMGRL session on the standby database instance with the sys user name and password.
```
[oracle@exa11db01 ~]$ dgmgrl
DGMRGL> connect
Username: sys
Password:
```

View the configuration to confirm the primary and standby databases.

DGMGRL> show configuration;

The output will look similar to the following:

Configuration - onpremexadr
  Protection Mode: MaxPerformance
  Members:
  db1_phx3g7 - Primary database
    db1        - Physical standby database 
      Error: ORA-16664: unable to receive the result from a member
Fast-Start Failover:  Disabled
Configuration Status:
ERROR   (status updated 108 seconds ago)

Convert the physical standby database to a snapshot standby database.
In this example, the standby_database_unique_name is db1.
```
DGMGRL> convert database standby_database_unique_name to snapshot standby;
```
When the conversion is complete, the output will have a line similar to the following:
```
Converting database "db1" to a Snapshot Standby database, please wait...
Database "db1" converted successfully
```

View the configuration to verify the conversion.

DGMGRL> show configuration;

The output will look similar to the following:

Configuration - onpremexadr
  Protection Mode: MaxPerformance
  Members:
  db1_phx3g7 - Primary database
    db1        - Snapshot standby database 
      Error: ORA-16664: unable to receive the result from a member
Fast-Start Failover:  Disabled
Configuration Status:
ERROR   (status updated 59 seconds ago)

Convert the snapshot standby back into a physical standby database.

DGMGRL> convert database standby_database_unique_name to physical standby;

The output will look similar to the following:

Converting database "db1" to a Physical Standby database, please wait...
Operation requires a connection to database "db1_phx3g7"
Connecting ...
Connected to "DB1_phx3g7"
Connected as SYSDBA.
Oracle Clusterware is restarting database "db1" ...
Connected to "db1"
Connected to "db1"
Continuing to convert database "db1" ...
Database "db1" converted successfully

View the configuration to verify the conversion.

DGMGRL> show configuration;

The output will look similar to the following:

Configuration - onpremexadr
  Protection Mode: MaxPerformance
  Members:
  db1_phx3g7 - Primary database
    db1        - Physical standby database 
      Error: ORA-16664: unable to receive the result from a member

Fast-Start Failover:  Disabled

Configuration Status:
ERROR   (status updated 20 seconds ago)
DGMGRL>

Set the Oracle Data Guard Parameters

Before executing a switchover, set the Oracle Data Guard parameters on the primary and standby database instances.

On the on-premises primary database, check the system change number (SCN).
```
select standby_became_primary_scn from v$database;
```
The output will look similar to the following:
```
STANDBY_BECAME_PRIMARY_SCN
--------------------------
0
```
Verify that the flashback is not enabled on the primary database.
```
select flashback_on from v$database;
```
The output will look similar to the following:
```
FLASHBACK_ON
------------------
NO
```

Display the parameter recovery.

SQL> show parameter recovery;

The output will look similar to the following:

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest	     string	      +RECOC1
db_recovery_file_dest_size	big integer	  8256M
recovery_parallelism             integer             0
remote_recovery_file_dest        string

Set the size of the DB_RECOVERY_FILE_DEST_SIZE parameter to meet your database size.
The following example uses 20G as the sample data size. Set the data size based on your database.
```
SQL> alter system set DB_RECOVERY_FILE_DEST_SIZE=20G;
```
Enable flashback on the primary database.
```
SQL> alter database flashback on;
```
Confirm that database flashback is enabled (on).
```
SQL> select flashback_on from v$database;
```
The output will look similar to the following:
```
FLASHBACK_ON
------------------
YES
```
On the standby Oracle Database Exadata Cloud Service, determine if flashback is enabled.
```
SQL> select flashback_on from v$database;
```
The output will look similar to the following:
```
FLASHBACK_ON
------------------
NO
```
Query the open mode status for the standby database in the cloud.
```
SQL> select open_mode from v$database;
```
The output will look similar to the following:
```
OPEN_MODE
-------------------- 
MOUNTED
```

Cancel database recovery for the standby database.

SQL> alter database recover managed standby database cancel;

Set the flashback on the database instance in the cloud.
```
SQL> alter database flashback on;
```

Disconnect the standby from the session.

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

Database altered

Confirm that database flashback is enabled (on).

SQL> select flashback_on from v$database;

FLASHBACK_ON
------------------
YES

Display the retention parameters.

SQL> show parameter_retention;

The output will look similar to the following:

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
db_flashback_retention_target	     integer	 1440
undo_retention			      integer	 900