Implementing Additional High Availability Strategies

10 Implementing Additional High Availability Strategies

Besides replication, other high availability strategies can be used with Recovery Appliance to increase protection against data loss in certain scenarios.

The Oracle Maximum Availability Architecture (MAA) best practice to protect the appliance against site disasters and system outages is to implement a disaster recovery strategy using Recovery Appliance replication. With a replica appliance, protected database backup, redo, and restore operations continue uninterrupted, preserving complete data protection.

If your organization does not have a disaster recovery strategy or if you would like to add local system high availability to your existing disaster recovery strategy, you can use the Backup and Redo Failover feature of Recovery Appliance. This feature is available starting with Recovery Appliance software update 12.1.1.1.8.

Another component of a high availability (HA) and disaster recovery solution is Oracle Data Guard. Oracle Data Guard minimizes service interruption and resulting data loss by maintaining a synchronized standby database for the protected database.

Managing Temporary Outages with a Backup and Redo Failover Strategy

Backup and Redo Failover is a high availability feature that allows protected databases to temporarily direct backups and redo to an alternate Recovery Appliance when the primary Recovery Appliance experiences an outage or requires planned maintenance. This allows protected database backups and redo to continue uninterrupted and preserves complete data protection. It also prevents the local archived log destinations of the database from filling up and impacting the database, which can occur with no alternate backup destination.

Overview of the Backup and Redo Failover Feature

In an environment where Backup and Redo Failover is configured, a protected database sends backups and redo to a primary Recovery Appliance under normal circumstances. When that appliance is unavailable, the protected database sends backups and redo to an alternate Recovery Appliance until service on the primary is restored.

The alternate appliance does not create virtual full backups from the temporary backups it receives; it only stores the backup pieces (incremental and archived log backups). When the primary appliance is back online and operational, the alternate appliance forwards all temporary backups to the primary appliance, which uses them to create the corresponding virtual full backups. After all virtual full backups are created, the protected database resumes sending backups and redo to the primary appliance. The alternate appliance deletes the temporary backup pieces from local storage only after they are successfully forwarded to the primary appliance.

Configuring Backup and Redo Failover

This section explains how to configure Backup and Redo Failover. The basic work flow is as follows:

Configure the primary Recovery Appliance, as described in "Configuring the Primary Recovery Appliance for Backup and Redo Failover".
Configure the alternate Recovery Appliance, as described in "Configuring the Alternate Recovery Appliance for Backup and Redo Failover".
Configure replication from the alternate Recovery Appliance to the primary Recovery Appliance, as described in "Configuring Replication for Backup and Redo Failover".
Configure the protected database to send backups, as described in "Configuring the Protected Database for Backup and Redo Failover".

Configuring the Primary Recovery Appliance for Backup and Redo Failover

To configure the primary Recovery Appliance for Backup and Redo Failover, you perform many of the tasks for setting up a downstream Recovery Appliance in a replication scenario.

Task 1: Create a VPC user account and a replication user account on the primary Recovery Appliance

Follow the instructions in "Creating Virtual Private Catalog Accounts".

For example, log in to the Recovery appliance as root, change to the bin directory, and use the following command to create the VPC user:

# ./racli add vpc_user --user_name=vpcuser

Enter the password for vpcuser user when prompted.

To create the replication user repuser_from_alternate with the CREATE SESSION privilege:

CREATE USER repuser_from_alternate IDENTIFIED BY password;
GRANT CREATE SESSION TO repuser_from_alternate;

The user_name created on the alternate must be the same as the VPC user created on the primary. However, the passwords do not need to be the same.

Task 2 Create a protection policy on the primary Recovery Appliance

Follow the instructions in "Creating a Protection Policy Using DBMS_RA". Ensure that the store_and_forward field is set to NO.

For example, execute the following PL/SQL program to create a primary_brf policy:

BEGIN
  DBMS_RA.CREATE_PROTECTION_POLICY (
    protection_policy_name => 'primary_brf',
    description            => 'For protected dbs on primary',
    storage_location_name  => 'delta',
    recovery_window_goal   => INTERVAL '28' DAY,
    guaranteed_copy        => 'NO',
    store_and_forward      => 'NO');
END;

Task 3: Add a database to the protection policy on the primary Recovery Appliance

Follow the instructions in "Adding Protected Database Metadata Using DBMS_RA".

For example, execute the following PL/SQL program to add orcl12 to the primary_brf policy that you created in the previous task:

BEGIN
  DBMS_RA.ADD_DB (
    db_unique_name         => 'orcl12',
    protection_policy_name => 'primary_brf',
    reserved_space         => '128G');
END;

Task 4: Grant database access to the VPC user and the replication user on the primary Recovery Appliance

Follow the instructions in "Granting Database Access to a Recovery Appliance Account Using DBMS_RA".

For example, execute the following PL/SQL programs to grant the VPC user vpcuser and the replication user repuser_from_alternate the required privileges on protected database orcl12:

BEGIN
  DBMS_RA.GRANT_DB_ACCESS (
    username       => 'vpcuser',
    db_unique_name => 'orcl12');
END;
BEGIN
  DBMS_RA.GRANT_DB_ACCESS (
    username       => 'repuser_from_alternate',
    db_unique_name => 'orcl12');
END;

Configuring the Alternate Recovery Appliance for Backup and Redo Failover

To configure the alternate Recovery Appliance, you perform tasks similar to setting up an upstream Recovery Appliance in a replication scenario.

Task 1 Create a protection policy for Backup and Redo Failover on the alternate Recovery Appliance

Follow the instructions in "Creating a Protection Policy Using DBMS_RA". Ensure that you set the store_and_forward field to YES.

For example, execute the following PL/SQL program to create an alt_brf policy:

BEGIN
  DBMS_RA.CREATE_PROTECTION_POLICY (
    protection_policy_name => 'alt_brf',
    description            => 'For protected dbs on alternate',
    storage_location_name  => 'delta',
    recovery_window_goal   => INTERVAL '28' DAY,
    guaranteed_copy        => 'NO',
    store_and_forward      => 'YES');
END;

Task 2: Add the database to the protection policy on the alternate Recovery Appliance

Follow the instructions in "Adding Protected Database Metadata Using DBMS_RA".

For example, execute the following PL/SQL program to add orcl12 to the alt_brf policy that you created in the previous task:

BEGIN
  DBMS_RA.ADD_DB (
    db_unique_name         => 'orcl12',
    protection_policy_name => 'alt_brf',
    reserved_space         => '128G');
END;

Task 3: Grant database access to the VPC user on the alternate Recovery Appliance

You created this user in "Task 1: Create a VPC user account and a replication user account on the primary Recovery Appliance".

Follow the instructions in "Granting Database Access to a Recovery Appliance Account Using DBMS_RA".

For example, execute the following PL/SQL program to grant the VPC user vpcuser the required privileges on protected database orcl12 :

BEGIN
  DBMS_RA.GRANT_DB_ACCESS (
    username       => 'vpcuser',
    db_unique_name => 'orcl12');
END;

Configuring Replication for Backup and Redo Failover

After you configure the primary and the alternate Recovery Appliances, you perform tasks similar to setting up replication from the alternate to the primary appliance. In this scenario, the alternate appliance has the upstream role and the primary appliance has the downstream role.

Task 1: Configure an Oracle wallet on the alternate Recovery Appliance

On the alternate Recovery Appliance, use the mkstore utility to create an Oracle auto-login wallet and add the credentials for the replication user you created in "Task 1: Create a VPC user account and a replication user account on the primary Recovery Appliance". The alternate Recovery Appliance requires these credentials when it logs in to the primary Recovery Appliance.

To configure an auto-login wallet on the alternate Recovery Appliance:

Run the following command to create an Oracle wallet in the /dbfs_repdbfs/REPLICATION directory:
```
mkstore -wrl /dbfs_repdbfs/REPLICATION -createALO
```
The mkstore utility creates a file named cwallet.sso in the designated location.
Run the following command to add the replication user credentials:
```
mkstore -wrl wallet_location -createCredential serv_name rep_user pwd
```
The placeholders are defined as follows:
- wallet_location is the directory in which you created the wallet in the previous step.
- serv_name is the Oracle network service name that you use in an EZ Connect descriptor to identify the primary Recovery Appliance on the Oracle network.
- rep_user is the user name of the replication user account. This user was created in Task 1: Create a VPC user account and a replication user account on the primary Recovery Appliance . The replication user is not created on the alternate.
- pwd is the secure password of the replication user rep_user.
For example, the following command adds credentials for the net service name rapribrf-scan.acme.com using port 1522 and a database name of rapri, and the replication user name repuser_from_alternate:
```
mkstore -wrl /dbfs_repdbfs/REPLICATION -createCredential \
"rapribrf-scan.acme.com:1522/rapri" "repuser_from_alternate" "pwd"
```

Verify that the credentials were properly added for this user by running the following command:

mkstore -wrl /dbfs_repdbfs/REPLICATION -listCredential

Oracle Secret Store Tool : Version 12.1.0.1 Copyright (c) 2004, 2012, Oracle and/or its affiliates. All rights reserved.
List credential (index: connect_string username)
1: rapribrf-scan.acme.com:1522/rapri repuser_from_alternate

The results do not display the password.

Task 2: Create the replication server configuration on the alternate Recovery Appliance

For the primary Recovery Appliance to which this alternate Recovery Appliance will forward backups after an outage, create a replication server configuration by executing DBMS_RA.CREATE_REPLICATION_SERVER.

This task assumes the following:

You want to create a replication server configuration named raprimary_rep.
You want the alternate Recovery Appliance to log in to the primary Recovery Appliance using the replication account repuser_from_alternate. You created this account in "Task 1: Create a VPC user account and a replication user account on the primary Recovery Appliance".
The configuration uses the net service name rapribrf-scan.acme.com:1522/rapri that you stored in the Oracle wallet you created in "Task 1: Configure an Oracle wallet on the alternate Recovery Appliance".
The Oracle wallet is stored in /dbfs_repdbfs/REPLICATION.
The file name of the Recovery Appliance Backup Module, which is preinstalled on every Recovery Appliance, is /u01/app/oracle/product/12.1.0.2/dbh1/lib/libra.so. The module functions as an SBT media management library. RMAN references this module when allocating or configuring a channel for backup to the Recovery Appliance (see "Configuring a Protected Database for Recovery Appliance Replication").

To create the replication server configuration:

With SQL*Plus or SQL Developer, connect to the alternate Recovery Appliance metadata database as RASYS.

Run the DBMS_RA.CREATE_REPLICATION_SERVER procedure for the primary Recovery Appliance.

The following example creates the replication server configuration named raprimary_rep for the primary Recovery Appliance:

BEGIN
  DBMS_RA.CREATE_REPLICATION_SERVER (
    replication_server_name => 'raprimary_rep',
    sbt_so_name      => '/u01/app/oracle/product/12.1.0.2/dbh1/lib/libra.so',
    catalog_user_name       => 'RASYS',
    wallet_alias            => 'rapribrf-scan.acme.com:1522/rapri',
    wallet_path             => 'file:/dbfs_repdbfs/REPLICATION');
END;

Confirm the creation of the replication server configuration. The replication_server_name is converted to upper-case and stored as such. Therefore queries with the name should also be upper-case.

For example, run the following query:
```
SELECT COUNT(*) should_be_one 
FROM   RA_REPLICATION_SERVER
WHERE  REPLICATION_SERVER_NAME = 'RAPRIMARY_REP';

SHOULD_BE_ONE
-------------
1
```
If the configuration was created correctly, then the return value is 1.

Task 3: Associate the alternate Recovery Appliance with the protection policy for Backup and Redo Failover

Specify the primary Recovery Appliance to which the alternate Recovery Appliance forwards backups after an outage by assigning the replication server configuration to a protection policy.

This task assumes the following:

You want to use the replication server configuration named raprimary_rep, which you created in "Task 2: Create the replication server configuration on the alternate Recovery Appliance".
You want to add the replication server configuration to protection policy alt_brf, which you created in "Task 1 Create a protection policy for Backup and Redo Failover on the alternate Recovery Appliance".

To associate the replication server configuration with the Backup and Redo Failover protection policy:

Ensure you are connected to the metadata database on the alternate Recovery Appliance as the Recovery Appliance administrator.
Run the DBMS_RA.ADD_REPLICATION_SERVER procedure for the Backup and Redo Failover protection policy and replication server configuration.

For example, execute the following PL/SQL program:
```
BEGIN
  DBMS_RA.ADD_REPLICATION_SERVER (
   replication_server_name => 'raprimary_rep',
   protection_policy_name  => 'alt_brf');
END;
```

Configuring the Protected Database for Backup and Redo Failover

After you configure replication for Backup and Redo Failover, the protected database administrator should perform the tasks in this section so that the protected database can send backups to the primary Recovery Appliance under normal conditions, and to the alternate Recovery Appliance during a planned or unplanned outage.

Task 1: Configure sqlnet.ora to point to the wallet location

Ensure that the sqlnet.ora file contains the location of the Oracle wallet.

The following example shows how the wallet location entry should appear:

SQLNET.WALLET_OVERRIDE = true
WALLET_LOCATION = 
(SOURCE = 
    (METHOD = FILE)
    (METHOD_DATA =
      (DIRECTORY = /u01/app/oracle/product/12.1.0/dbhome_1/dbs/zdlra)
   )
  )

Task 2: Create an auto-login wallet in the location specified in sqlnet.ora

The following example creates an auto-login wallet in the directory specified in "Task 1: Configure sqlnet.ora to point to the wallet location":

$ mkstore -wrl /u01/app/oracle/product/12.1.0/dbhome_1/dbs/zdlra/ -createALO

Task 3: Add the credentials for the primary and alternate Recovery Appliances to the wallet

In this task the protected database administrator adds credentials for the primary and alternate appliances using the VPC user you created in "Task 1: Create a VPC user account and a replication user account on the primary Recovery Appliance" to the wallet.

The following examples add the vpcuser credentials for the primary appliance rapribrf-scan.acme.com:1521/rapri:dedicated and the alternate appliance raaltbrf-scan.acme.com:1521/raalt:dedicated to the wallet on the protected database:

$ mkstore -wrl /u01/app/oracle/product/12.1.0/dbhome_1/dbs/zdlra/ -createCredential "rapribrf-scan.acme.com:1521/rapri:dedicated" "vpcuser" "pwd"
$ mkstore -wrl /u01/app/oracle/product/12.1.0/dbhome_1/dbs/zdlra/ -createCredential "raaltbrf-scan.acme.com:1521/raalt:dedicated" "vpcuser" "pwd"

Task 4: Register the database with the alternate Recovery Appliance and back up the control file

For this task, the protected database administrator performs steps 1 and 2, and the Recovery Appliance administrator performs step 3.

To register the database and back up the control file:

Using RMAN, connect to the protected database as TARGET and to the alternate Recovery Appliance catalog as CATALOG, and then run the REGISTER DATABASE command.
After the REGISTER DATABASE command is completed, back up the current control file to the alternate appliance:
```
BACKUP DEVICE TYPE SBT CURRENT CONTROLFILE;
```
Verify that the control file backup was replicated from the alternate appliance to the primary appliance.

Task 5: Ensure that the database is registered with the primary Recovery Appliance

This step is to confirm that the protected database is registered with the primary appliance. Because replication is configured when the database is registered with the alternate appliance in the previous task, the database should automatically be registered with the primary appliance.

To confirm registration with the primary appliance:

In RMAN, connect to the database using the primary appliance credentials in the CATALOG connect string.

rman TARGET / CATALOG /@rapribrf-scan.acme.com:1521/rapri:dedicated
Run the REGISTER DATABASE command.

The following error should display:
```
RMAN-20002: target database already registered in recovery catalog
```

Note:

The protected database administrator must also create a separate RMAN backup script that directs backups to the alternate Recovery Appliance when the primary appliance is not available, and redirects backups to the primary appliance when it is back in service. This script must connect to the alternate Recovery Appliance catalog and have the CONFIGURE CHANNEL or ALLOCATE CHANNEL command with credential_alias set to the alternate appliance. See Zero Data Loss Recovery Appliance Protected Database Configuration Guide for an example of how to create an RMAN backup script for the Recovery Appliance.
To send real time redo to the alternate Recovery Appliance during the outage of the primary appliance, an additional log archive destination must be defined as an ALTERNATE for the log archive destination used to connect to the primary appliance. The connect string must be defined in the Oracle auto-login wallet, similar to the connect string required for the primary appliance, and using the same VPC user (although the password may be different). See Data Guard Concepts and Administration for an example of how to use the ALTERNATE attribute to automatically fail over to a alternate remote destination.

Implementing DR Failover to Downstream Recovery Appliance

As part of disaster recovery, protected databases should failover to a downstream Recovery Appliance as the target for sending backup files and redo transport if the upstream Recovery Appliance is unavailable. This section provides steps on how to configure a protected database for transparent failover of backup operations and redo transport to a downstream Recovery Appliance.

For sake of clarity, this examples makes the following assumptions:

If you have real time redo transport enabled, it receives an error and stops sending redo to the upstream Recovery Appliance. Within a minute, real time redo transport connects to the downstream Recovery Appliance and resumes sending redo there.
The name of the example protected database is CDB122DR. It is a Container Databases with One Pluggable Database.
The name of the example upstream Recovery Appliance is RAHADR1.
The name of the example downstream Recovery Appliance is RAHADR2.
A common VPC user called HADR_COMMON_VPCUSER was created on both Recovery Appliances and must use the same password on both.
A local VPC user called HADR_LOCAL_VPCUSER has been created on both Recovery Appliances but the password can be different between the two.
The replication server between RAHADR1 and RAHADR2 is using the VPC user REPUSER_FROM_HADR1.

Setup and Configuration for Failover

This section establishes VPC users for the Recovery Appliances to use later for failover.It modifies the network configuration files needed, configures the replication server, creates protection policies, registers the protected database, and adds several grants to the upstream and downstream Recovery Appliances.

Creating VPC Users

This task creates database VPC user accounts in the upstream and downstream Recovery Appliances.

When creating the accounts, keep in mind these password requirements.

The first VPC user (HADR_LOCAL_VPCUSER) account may be used by other protected databases and can have different passwords between the RAHADR1 and RAHADR2 Recovery Appliances.
The second VPC user (HADR_COMMON_VPCUSER) account must use the same password on both the RAHADR1 and RAHADR2 Recovery Appliances and can be used by other protected databases

The following conditions are applicable to this specific example.

Recovery Appliance RAHADR1 has previously been installed with a DB_UNIQUE_NAME of rahadr1.
Recovery Appliance RAHADR2 has previously been installed with a DB_UNIQUE_NAME of rahadr2.

Create two VPC users for the protected database on the upstream Recovery Appliance RAHADR1.

# racli add vpc_user --user_name HADR_LOCAL_VPCUSER
[HADR_LOCAL_VPCUSER] New Password: ***********
Sun Mar 25 08:27:53 2018: Start: Add vpc user HADR_LOCAL_VPCUSER.
Sun Mar 25 08:27:53 2018: Add vpc user HADR_LOCAL_VPCUSER successfully.
Sun Mar 25 08:27:53 2018: End: Add vpc user HADR_LOCAL_VPCUSER.

# racli add vpc_user --user_name HADR_COMMON_VPCUSER
[HADR_COMMON_VPCUSER] New Password: ***********
Sun Mar 25 08:27:53 2018: Start: Add vpc user HADR_COMMON_VPCUSER.
Sun Mar 25 08:27:53 2018: Add vpc user HADR_COMMON_VPCUSER successfully.
Sun Mar 25 08:27:53 2018: End: Add vpc user HADR_COMMON_VPCUSER.

Create two VPC users for the protected database on the downstream Recovery Appliance RAHADR2.

# racli add vpc_user --user_name HADR_LOCAL_VPCUSER
[HADR_LOCAL_VPCUSER] New Password: ***********
Sun Mar 25 08:27:53 2018: Start: Add vpc user HADR_LOCAL_VPCUSER.
Sun Mar 25 08:27:53 2018: Add vpc user HADR_LOCAL_VPCUSER successfully.
Sun Mar 25 08:27:53 2018: End: Add vpc user HADR_LOCAL_VPCUSER.

# racli add vpc_user --user_name HADR_COMMON_VPCUSER
[HADR_COMMON_VPCUSER] New Password: ***********
Sun Mar 25 08:27:53 2018: Start: Add vpc user HADR_COMMON_VPCUSER.
Sun Mar 25 08:27:53 2018: Add vpc user HADR_COMMON_VPCUSER successfully.
Sun Mar 25 08:27:53 2018: End: Add vpc user HADR_COMMON_VPCUSER.

If the VPC user account used by the replication server for sending backups from the upstream (HARADR1) to the downstream (RAHADR2) Recovery Appliances hasn't been created, create the VPC user now.

# racli add vpc_user --user_name REPUSER_FROM_HADR1
[REPUSER_FROM_HADR1] New Password: ***********

Sun Mar 25 08:35:01 2018: Start: Add vpc user REPUSER_FROM_HADR1.
Sun Mar 25 08:35:01 2018: Add vpc user REPUSER_FROM_HADR1 successfully.
Sun Mar 25 08:35:01 2018: End: Add vpc user REPUSER_FROM_HADR1.

Modifying Configuration for Transport Failover

This task modifies the Oracle network configuration files that are used for transparent failover to the downstream Recovery Appliance.

If you have a RAC database, this should be performed on each host where the protected database runs.

Verify that there are no ${ORACLE_HOME}/dbs/ra${ORACLE_SID}.ora files on any of the hosts.
This file has the effect of overriding all the configuration parameters defined in this step and should be removed if present.
Configure a TNS alias in the tnsnames.ora file that will be used by RMAN to connect to the correct Recovery Appliance.
```
$ cd ${ORACLE_HOME}/network/admin
```

Edit tnsnames.ora and add the following entry:

DR_RAHADR =
(DESCRIPTION_LIST =
  (LOAD_BALANCE = off)
  (FAILOVER = on)
  (DESCRIPTION =
    (CONNECT_TIMEOUT = 5)
    (TRANSPORT_CONNECT_TIMEOUT = 3)
    (RETRY_COUNT = 3)
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = ra1ingest-scan)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = rahadr1)
    )
  )
  (DESCRIPTION =
    (CONNECT_TIMEOUT = 5)
    (TRANSPORT_CONNECT_TIMEOUT = 3)
    (RETRY_COUNT = 3)
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = ra2ingest-scan)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = rahadr2)
    )
  )
)
DR_RAHADR1 =
(DESCRIPTION_LIST =
  (DESCRIPTION =
    (CONNECT_TIMEOUT = 5)
    (TRANSPORT_CONNECT_TIMEOUT = 3)
    (RETRY_COUNT = 3)
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = ra1ingest-scan)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = rahadr1)
    )
  )
)
DR_RAHADR2 =
(DESCRIPTION_LIST =
  (DESCRIPTION =
    (CONNECT_TIMEOUT = 5)
    (TRANSPORT_CONNECT_TIMEOUT = 3)
    (RETRY_COUNT = 3)
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = ra2ingest-scan)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = rahadr2)
    )
  )
)

Configuring the Replication Server

This task configures the replication server that sends the database backups from RAHADR1 to the RAHADR2 Recovery Appliance.

The operations and naming conventions used here are equivalent to those in Enterprise Manager when there is no dedicated replication network. For more information, see Replicating Backups with Recovery Appliance.

The replication server between RAHADR1 and RAHADR2 has not already been created.

If a replication wallet does not exist on RAHADR1, create a replication wallet that points to RAHADR2.
```
$ mkstore -wrl file:/dbfs_repdbfs/REPLICATION -createALO
```

Add the credentials to the wallet. On RAHADR1, add the credentials for logging into RAHADR2.

$ mkstore -wrl file:/dbfs_repdbfs/REPLICATION 
-createCredential <rahadr2-scan>:1521/rahadr2 REPUSER_FROM_HADR1 my_v3ry_c0mplex_pa55w0rd

Create the Recovery Appliance replication server on RAHADR1.

$ sqlplus rasys/ra

SQL> exec dbms_ra.create_replication_server( 
replication_server_name =>'RAHADR2_REP', 
sbt_so_name => 'libra.so', max_streams => 8, 
catalog_user_name=> 'RASYS', 
wallet_alias => '<rahadr2-scan>:1521/rahadr2',
wallet_path => 'file:/dbfs_repdbfs/REPLICATION');

PL/SQL procedure successfully completed.

Configuring Upstream and Downstream Recovery Appliances

This task configures the protection policies for the protected database on the downstream and upstream Recovery Appliance, and then adds the protection policy to the replication server.

If a protection policy that is used, for example, by the CBR122DR database does not exist on the respective Recovery Appliances, these steps create them. The protection policy name does not have to be unique between the downstream and upstream Recovery Appliances.

To prevent a circular references between RAHADR1 and RAHADR2, the protection policy from RAHADR2 is not added to the replication server while the protection policy from RAHADR1 is added. All databases in the protection policy are replicated.

Note: Because RAHADR2 does not normally accept redo from the CDB122DR database, set the unprotected data window parameter is set to 1.25 days to avoid false alerts from occurring if the CDB122DR database is idle.

Log into SQLPLS as rasys/ra on RAHADR2, the downstream Recovery Appliance. This step and the next few are performed on RAHADR2, unless otherwise stated.
```
$ sqlplus rasys/ra
```

Create the protection policy.

SQL> exec dbms_ra.create_protection_policy( 
protection_policy_name => 'cdb122dr_PP', 
storage_location_name => 'DELTA', 
recovery_window_goal => numtodsinterval(3,'DAY'), 
unprotected_window => numtodsinterval(1.25,'DAY'), 
allow_backup_deletion => 'NO');

PL/SQL procedure successfully completed.

Add the database (for this example) and its protection policy to the list of those protected by the Recovery Appliance.

SQL> exec dbms_ra.add_db(
db_unique_name => 'cdb122dr', 
protection_policy_name=> 'cdb122dr_PP', 
reserved_space => '1T');

PL/SQL procedure successfully completed.

Grant access to the replication user to the database (for this example).

SQL> exec dbms_ra.grant_db_access(
username => 'REPUSER_FROM_HADR1',
db_unique_name => 'cdb122dr');

PL/SQL procedure successfully completed.

Log into sqlplus as rasys/ra on RAHADR1, the upstream Recovery Appliance. This step and all that follow are performed on RAHADR1.
```
$ sqlplus rasys/ra
```

Create a protection policy. The protection policy name does not have to be unique.

SQL> exec dbms_ra.create_protection_policy( 
protection_policy_name =>'cdb122dr_PP', 
storage_location_name => 'DELTA', 
recovery_window_goal => numtodsinterval(3,'DAY'), 
unprotected_window => numtodsinterval(5,'MINUTE'), 
allow_backup_deletion => 'NO');

PL/SQL procedure successfully completed.

Add the database (for this example) and its protection policy to the list of those protected by the Recovery Appliance.

SQL> exec dbms_ra.add_db(
db_unique_name => 'cdb122dr', 
protection_policy_name=> 'cdb122dr_PP', 
reserved_space => '1T');

PL/SQL procedure successfully completed.

Grant access to the replication user to the database (for this example).

SQL> exec dbms_ra.grant_db_access(
username => 'HADR_LOCAL_VPCUSER',
db_unique_name => 'cdb122dr');

PL/SQL procedure successfully completed.

Add the protection policy to the replication server. This step is performed on the upstream Recovery Appliance (RAHADR1). This step was not performed on the downstream Recovery Appliance, in order to prevent a circular reference between the two Recovery Appliances.
```
SQL> exec dbms_ra.add_replication_server( 
replication_server_name =>'RAHADR2_REP', 
protection_policy_name => 'cdb122dr_PP');

PL/SQL procedure successfully completed.
```

Registering the Protected Database on the Upstream Recovery Appliance

This task configures the wallet, adds VPC user credentials, tests those credentials, and registers the protected database with the upstream Recovery Appliance. If it is a RAC database, the steps need to be performed on each host where the protected database runs.

The operations and naming conventions used here are equivalent to those in Enterprise Manager.

Configure the sqlnet.ora file that will be used by RMAN to connect to the correctRecovery Appliance. Go to the proper directory.
```
$ cd ${ORACLE_HOME}/network/admin
```

Edit the sqlnet.ora file and ensure the following parameters are set correctly:

SQLNET.WALLET_OVERRIDE = true

NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT)

WALLET_LOCATION =
  (SOURCE =
    (METHOD = FILE)
    (METHOD_DATA =
      (DIRECTORY = /u01/app/oracle/product/12.2.0.1/dbhome_1/dbs/zdlra)
    )
  )

SQLNET.EXPIRE_TIME = 10

Create a replication wallet that stores each of the VPC user credentials. Perform this step only if the replication wallet doesn't already exist. On each host:
```
$ mkstore -wrl file:/u01/app/oracle/product/12.2.0.1/dbhome_1/dbs/zdlra -
createALO
```

Create credential aliases for each of the three credentials that will be used by RMAN. On each host, run the mkstore command. Enter the appropriate password when prompted.

$ mkstore -wrl file:/u01/app/oracle/product/12.2.0.1/dbhome_1/dbs/zdlra -
createCredential dr_rahadr2 hadr_local_vpcuser hadr2_L0cal_Pa55w0rd

$ mkstore -wrl file:/u01/app/oracle/product/12.2.0.1/dbhome_1/dbs/zdlra -
createCredential dr_rahadr1 hadr_local_vpcuser hadr1_L0cal_Pa55w0rd

$ mkstore -wrl file:/u01/app/oracle/product/12.2.0.1/dbhome_1/dbs/zdlra -
createCredential dr_rahadr hadr_common_vpcuser c0mm0n_Pa55w0rd

Verify the credentials are working correctly by logging into each target using only the credential alias. On each host, run the following:
```
$ sqlplus /@dr_rahadr1
```
Register the protected database with the Recovery Appliance in RAHADR1. On one of the hosts, run:
```
$ rman target / catalog /@dr_rahadr1

RMAN> register database;
```

Perform a test backup of the current control file to Recovery Appliance hadr1 (RAHADR1). On one of the protected database hosts, perform a backup of the current control file.

$ rman target / catalog /@dr_rahadr1

RMAN> CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' FORMAT '%d_%U' PARMS
"SBT_LIBRARY=/u01/app/oracle/product/12.2.0.1/dbhome_1/lib/libra.so,
ENV=(RA_WALLET='location=file:/u01/app/oracle/product/12.2.0.1/dbhome_1/dbs/z
dlra credential_alias=dr_rahadr1')";

RMAN> backup device type sbt current controlfile tag 'controltest';

Starting backup at 05-JUN-18
allocated channel: ORA_SBT_TAPE_1
channel ORA_SBT_TAPE_1: SID=2320 instance=cdb122dr1 device type=SBT_TAPE
channel ORA_SBT_TAPE_1: RA Library (RAHADR1)
SID=6DE9FE3D49ED4598E05311F3850AC59F
allocated channel: ORA_SBT_TAPE_2
channel ORA_SBT_TAPE_2: SID=2516 instance=cdb122dr1 device type=SBT_TAPE
channel ORA_SBT_TAPE_2: RA Library (RAHADR1)
SID=6DE9FE48D84C48C8E05311F3850A89BE
channel ORA_SBT_TAPE_1: starting full datafile backup set
channel ORA_SBT_TAPE_1: specifying datafile(s) in backup set
including current control file in backup set
channel ORA_SBT_TAPE_1: starting piece 1 at 05-JUN-18
channel ORA_SBT_TAPE_1: finished piece 1 at 05-JUN-18
piece handle=CDB122DR_2kt4m80u_1_1 tag=CONTROLTEST comment=API Version
2.0,MMS Version 3.17.1.26
channel ORA_SBT_TAPE_1: backup set complete, elapsed time: 00:00:15
Finished backup at 05-JUN-18
Starting Control File and SPFILE Autobackup at 05-JUN-18
piece handle=c-3244939197-20180605-00 comment=API Version 2.0,MMS Version
3.17.1.26
Finished Control File and SPFILE Autobackup at 05-JUN-18

List the backup set just created. Verify there are two copies of the control file, one on Recovery Appliance hadr1 (RAHADR1) and the other on Recovery Appliance hadr2 (RAHADR2).

RMAN> list backupset tag CONTROLTEST;

List of Backup Sets
===================
BS Key Type LV Size
------- ---- -- ----------
220 Full 138.75M
Control File Included: Ckp SCN: 9076177 Ckp time: 05-JUN-18
Backup Set Copy #1 of backup set 220
Device Type Elapsed Time Completion Time Compressed Tag
----------- ------------ --------------- ---------- ---
SBT_TAPE 07:00:21 05-JUN-18 NO CONTROLTEST
List of Backup Pieces for backup set 220 Copy #1
BP Key Pc# Status Media Piece Name
------- --- ----------- ----------------------- ----------
221 1 AVAILABLE Recovery Appliance (RAHADR1)
CDB122DR_2kt4m80u_1_1
Backup Set Copy #2 of backup set 220
Device Type Elapsed Time Completion Time Compressed Tag
----------- ------------ --------------- ---------- ---
SBT_TAPE 07:00:21 05-JUN-18 NO CONTROLTEST
List of Backup Pieces for backup set 220 Copy #2
BP Key Pc# Status Media Piece Name
------- --- ----------- ----------------------- ----------
246 1 AVAILABLE Recovery Appliance (RAHADR2)
RA_SBT_CDB122DR_3244939197_230_2kt4m80u_1_2_220

Adding Remaining Grants to the Upstream and Downstream Recovery Appliance

This task grants access to VPC users on both the upstream and downstream Recovery Appliances.

On RAHADR1, add the grant access to the one remaining VPC users.

SQL> exec dbms_ra.grant_db_access(
username => 'HADR_COMMON_VPCUSER',
db_unique_name => 'cdb122dr');

PL/SQL procedure successfully completed.

On RAHADR2, add the grant access to the two remaining VPC users. These users are pre-setup in the event that backups failover, due to RAHADR1 not being available.

SQL> exec dbms_ra.grant_db_access(
username => 'HADR_LOCAL_VPCUSER',
db_unique_name => 'cdb122dr');

PL/SQL procedure successfully completed.

SQL> exec dbms_ra.grant_db_access(
username => 'HADR_COMMON_VPCUSER',
db_unique_name => 'cdb122dr');

PL/SQL procedure successfully completed.

Verify the credentials are working correctly by logging into each target using only the credential alias. On each host run:
```
$ sqlplus /@dr_rahadr2

$ sqlplus /@dr_rahadr
```

Configuring Channel Device Parameters

This task configures the channel device parameters for use with the DR_RAHADR alias.

On one of the protected database hosts, run:

$ rman target / catalog /@dr_rahadr1

RMAN> CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' FORMAT '%d_%U' PARMS
"SBT_LIBRARY=/u01/app/oracle/product/12.2.0.1/dbhome_1/lib/libra.so,
ENV=(RA_WALLET='location=file:/u01/app/oracle/product/12.2.0.1/dbhome_1/dbs/z
dlra credential_alias=dr_rahadr')";

(Optional) configure the following parameters, which are best practice recommendations.

RMAN> CONFIGURE BACKUP OPTIMIZATION on;

RMAN> CONFIGURE CONTROLFILE AUTOBACKUP on;

RMAN> CONFIGURE DEFAULT DEVICE TYPE TO sbt;

RMAN> CONFIGURE DEVICE TYPE SBT_TAPE PARALLELISM 2 BACKUP TYPE TO BACKUPSET;

RMAN> CONFIGURE SNAPSHOT CONTROLFILE NAME TO '+RECOC1/cdb122dr/snapcf.f';

RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO backed up 1 times to device
type sbt;

Configuring Upstream and Downstream Recovery Appliance

This task creates host specific files for backups, loads the scripts on their respective hosts, and verifies the credentials.

On a host of the upstream Recovery Appliance, create the backup_database_rahadr1.rman text file with the following content.

{
allocate channel rahadr1_sbt_1 device type sbt
  format '%d_%U'
  PARMS="SBT_LIBRARY=/u01/app/oracle/product/12.2.0.1/dbhome_1/lib/libra.so,
  ENV=(RA_WALLET='location=file:/u01/app/oracle/product/12.2.0.1/dbhome_1/dbs/zdlra
  credential_alias=dr_rahadr1')";

allocate channel rahadr1_sbt_2 device type sbt
  format '%d_%U'
  PARMS="SBT_LIBRARY=/u01/app/oracle/product/12.2.0.1/dbhome_1/lib/libra.so,
  ENV=(RA_WALLET='location=file:/u01/app/oracle/product/12.2.0.1/dbhome_1/dbs/zdlra
  credential_alias=dr_rahadr1')";

backup
  tag '&1'
  cumulative incremental level 1
  filesperset 1
  section size 64g
  database
    plus archivelog
      not backed up
      filesperset 32
      delete input;
}

On a host of the downstream Recovery Appliance, create the backup_database_rahadr2.rman text file with the following content.

{
allocate channel rahadr2_sbt_1 device type sbt
  format '%d_%U'
  PARMS="SBT_LIBRARY=/u01/app/oracle/product/12.2.0.1/dbhome_1/lib/libra.so,
  ENV=(RA_WALLET='location=file:/u01/app/oracle/product/12.2.0.1/dbhome_1/dbs/zdlra
  credential_alias=dr_rahadr2')";

allocate channel rahadr1_sbt_2 device type sbt
  format '%d_%U'
  PARMS="SBT_LIBRARY=/u01/app/oracle/product/12.2.0.1/dbhome_1/lib/libra.so,
  ENV=(RA_WALLET='location=file:/u01/app/oracle/product/12.2.0.1/dbhome_1/dbs/zdlra
  credential_alias=dr_rahadr2')";

backup
  tag '&1'
  cumulative incremental level 1
  filesperset 1
  section size 64g
  database
    plus archivelog
      not backed up
      filesperset 32
      delete input;
}

Ensure the script on RAHADR1 does not exist by trying to delete it first. Then load the HADR1 script into the RAHADR1 Recovery Appliance.

$ rman target / catalog /@dr_rahadr1

RMAN> delete script backup_database;

RMAN> create script backup_database from file
'/home/oracle/backup_database_rahadr1.rman';

Ensure the script on RAHADR2 does not exist by trying to delete it first. Then load the HADR2 script into the RAHADR2 Recovery Appliance.

$ rman target / catalog /@dr_rahadr2

RMAN> delete script backup_database;

RMAN> create script backup_database from file
'/home/oracle/backup_database_rahadr2.rman';

Verify credentials have access to the database.

$ rman target / catalog /@dr_rahadr

RMAN> print script backup_database;

printing stored script: backup_database
{
allocate channel rahadr1_sbt_1 device type sbt
  format '%d_%U'
  PARMS="SBT_LIBRARY=/u01/app/oracle/product/12.2.0.1/dbhome_1/lib/libra.so,
  ENV=(RA_WALLET='location=file:/u01/app/oracle/product/12.2.0.1/dbhome_1/dbs/zdlra
  credential_alias=dr_rahadr1')";

allocate channel rahadr1_sbt_2 device type sbt
  format '%d_%U'
  PARMS="SBT_LIBRARY=/u01/app/oracle/product/12.2.0.1/dbhome_1/lib/libra.so,
  ENV=(RA_WALLET='location=file:/u01/app/oracle/product/12.2.0.1/dbhome_1/dbs/zdlra
  credential_alias=dr_rahadr1')";

backup
  tag '&1'
  cumulative incremental level 1
  filesperset 1
  section size 64g
  database
    plus archivelog
      not backed up
      filesperset 32
      delete input;
}

Backup Operation

This task starts the backup_database script.

The following RMAN command should be used for all RMAN backup operations.

Note:

When the script is run, the channel allocations indicate which Recovery Appliance is logged into and the Recovery Appliance database name.

Start RMAN
```
$ rman target / catalog /@dr_rahadr
```

Start the backup_database script. If RAHADR1 is running, the script logs into RAHADR1. Otherwise, the script logs into RAHADR2.

RMAN> run { execute script backup_database using 'Level1'; }

executing script: backup_database

allocated channel: rahadr1_sbt_1
channel rahadr1_sbt_1: SID=1936 instance=cdb122dr1 device type=SBT_TAPE
channel rahadr1_sbt_1: RA Library (RAHADR1)
SID=6DEA2A958DFBE0CFE05311F3850AB3AB

allocated channel: rahadr1_sbt_2
channel rahadr1_sbt_2: SID=394 instance=cdb122dr1 device type=SBT_TAPE
channel rahadr1_sbt_2: RA Library (RAHADR1)
SID=6DEA2A9CC2BBE0D0E05311F3850AC634

Backup Piece Gap Resolution

When the upstream Recovery Appliance (RAHADR1) becomes available again, the backups that had failed over to the downstream Recovery Appliance (RAHADR2) need to be transferred back to RAHADR1 to resolve the gap of virtual full backups.

The gap shows as INDEX_BACKUP tasks in ORDERING_WAIT state on RAHADR1, because the virtual full backup metadata is present through normal catalog reconcile with RAHADR2 configured as downstream, however the backups are not yet physically present on the upstream Recovery Appliance.

The PL/SQL script tkrmrshadr.sql performs this operation. It loads the RA_POPULATE_BACKUP_PIECE procedure into the database. Then the script creates a DBMS_SCHEDULER_JOB that runs every 15 minutes to look for INDEX_BACKUP tasks that are in an ORDERING_WAIT state. It determines which backup pieces need to be transferred to the upstream Recovery Appliance RAHADR1 from the downstream RAHADR2. The backup pieces are transferred in parallel if possible using the DBMS_RA.POPULATE_BACKUP_PIECE command.

The initial query is very quick. However, if pieces are found, then the job can run for an extended period of time due to the INDEX_BACKUP tasks that are created on RAHADR1 as a result of the DBMS_RA.POPULATE_BACKUP_PIECE calls.

The MD5SUM for the tkrmrshadr.sql is beb79a1bdd61c91b34e0d777f75c2227.

$ md5sum tkrmrshadr.sql beb79a1bdd61c91b34e0d777f75c2227 tkrmrshadr.sql

---------------**************** -------------------
Installing tkrmrshadr.sql
- Install the script into all RAs participating in HADR.
- The script only needs to be installed once:
- As rasys: sqlplus rasys/<rasyspwd> @<full_dir_location_of_script>/tkrmrshadr.sql
---------------**************** -------------------

Real-Time Redo Transport

Real-Time Redo Transport for protected databases can be configured to regularly use the upstream Recovery Appliance, but to failover to the downstream Recovery Appliance when the upstream one isn't available. When the upstream Recovery Appliance becomes available again, redo transport automatically changes from using the downstream back to using the upstream.

Configuring the VPC User for Real-Time Redo Transport

This task establishes the VPC user for redo transport and then you choose between (1) enabling parameters in Data Guard Broker and (2) enabling log archive parameters.

Configure the redo_transport_user to the local VPC user.

$ sqlplus / as sysdba

SQL> alter system set redo_transport_user=hadr_local_vpcuser;

System altered.

Choose one of the two options.
- Option 1: Use Data Guard Broker to Configure Real-Time Redo Transport
- Option 2: Use log_archive* Parameters to Configure Real-Time Redo Transport

Option 1: Use Data Guard Broker to Configure Real-Time Redo Transport

This task enables Data Guard Broker parameters that establish failover of real-time redo transport from the upstream to the downstream Recovery Appliance.

Enable the dg_broker* parameters from a SQLPLUS session as sysdba.

$ sqlplus / as sysdba

SQL> alter system set
dg_broker_config_file1='+DATAC1/cdb122dr/dr1cdb122dr.dat';
System altered.

SQL> alter system set
dg_broker_config_file2='+DATAC1/cdb122dr/dr2cdb122dr.dat';
System altered.

SQL> alter system set dg_broker_start=true;
System altered.

Configure Data Guard Broker with respect to the primary databases, connection identifiers for the Recovery Appliances, network timeouts, and maximum number of failures. In the end, enable the configuration changes.

$ dgmgrl sys/myPassword

DGMGRL for Linux: Release 12.2.0.1.0 - Production on Tue Jun 5 11:37:44 2018

Copyright (c) 1982, 2017, Oracle and/or its affiliates. All rights reserved.

Welcome to DGMGRL, type "help" for information.
Connected to "cdb122dr"
Connected as SYSDG.

DGMGRL> create configuration cdb122dr as primary database is cdb122dr connect
identifier is '//scam06-scan3/cdb122dr';
Configuration "cdb122dr" created with primary database "cdb122dr"

DGMGRL> add recovery_appliance rahadr1 as connect identifier is 'dr_rahadr1';
Recovery Appliance "rahadr1" added

DGMGRL> add recovery_appliance rahadr2 as connect identifier is 'dr_rahadr2';
Recovery Appliance "rahadr2" added

DGMGRL> edit recovery_appliance rahadr1 set property MaxFailure=1;
Property "maxfailure" updated

DGMGRL> edit recovery_appliance rahadr1 set property ReopenSecs=10;
Property "reopensecs" updated

DGMGRL> edit recovery_appliance rahadr1 set property NetTimeout=8;
Property "nettimeout" updated

DGMGRL> edit recovery_appliance rahadr2 set property MaxFailure=1;
Property "maxfailure" updated

DGMGRL> edit recovery_appliance rahadr2 set property NetTimeout=8;
Property "nettimeout" updated

DGMGRL> edit database cdb122dr set property RedoRoutes = '(LOCAL : (rahadr1
async priority=1, rahadr2 async priority=2))';
Warning: ORA-16677: Standby database has the same or higher priority than
other members specified in the RedoRoutes group.
Property "redoroutes" updated

DGMGRL> enable configuration;
Enabled.

Note:

If Redo Transport does not start, then you may need to bounce the protected database. For a RAC database, this can be done in a rolling fashion.

Option 2: Use log_archive* Parameters to Configure Real-Time Redo Transport

This task enables manually changes several log_archive* parameters that establish failover of real-time redo transport from the upstream to the downstream Recovery Appliance.

Log into sqlplus as rasys/ra and change several parameters with respect to the primary databases, connection identifiers for the Recovery Appliances, network timeouts, and maximum number of failures. In the end, enable the configuration changes.

$ sqlplus rasys/ra

SQL> alter system set log_archive_config =
'dg_config=(cdb122dr,rahadr1,rahadr2)';

SQL> alter system set log_archive_dest_2='service=dr_rahadr1 ASYNC NOAFFIRM
delay=0 optional compression=disable max_failure=1 max_connections=1
reopen=10 db_unique_name=rahadr1 net_timeout=8 group=1 priority=1
valid_for=(online_logfile,all_roles)';

SQL> alter system set log_archive_dest_3='service=dr_rahadr2 ASYNC NOAFFIRM
delay=0 optional compression=disable max_failure=1 max_connections=1
reopen=300 db_unique_name=rahadr2 net_timeout=8 group=1 priority=2
valid_for=(online_logfile,all_roles)';

SQL> alter system set log_archive_dest_state_2=enable;

SQL> alter system set log_archive_dest_state_3=enable;

Note:

If Redo Transport does not start, then you may need to bounce the protected database. For a RAC database, this can be done in a rolling fashion.

Replication Mode for HADR

Demonstrates a high availability disaster recover scenario involving replicated recovery appliances.

Figure 10-1 shows two data centers, one local and one remote, each with a recovery appliance RA-x and RA-y that are configured as a replication pair, or bi-directional replication.

The database in the local data center sends its backups and redo logs to RA-x, as usual. RA-x then replicates the backups and redo logs to RA-y in the remote local data center. If local RA-x goes offline, the backups and redo are redirected to remote RA-y, with full recoverability to both data centers. When RA-x comes back online, remote RA-y replicates backups to local RA-x to get it in sync with the current state.

In this example, backups from the remote data center's databases to RA-y are not replicated to RA-x in the local data center.

Figure 10-1 Backups Replicated to two Recovery Appliances

Description of "Figure 10-1 Backups Replicated to two Recovery Appliances"

Backup Anywhere Mode for Data Guard

Demonstrates a how Backup Anywhere supports Data Guard.

Figure 10-2 shows two data centers for local and remote, where the primary site (upstream) is local RA-x and the standby site (downstream) is remote RA-y. The database in the local data center sends its primary backups and logs to RA-x, as usual. In request_only mode, there is no active replication between the upstream and downstream. Replication only happens when backups are requested by the upstream RA-x to fill gaps after an outage. Data Guard and redo logs keeps the remote database in sync with the local database.

When a failover or switchover is carried out, the remote database becomes the new primary and will backup and send redo to RA-y. Meanwhile a reversal of the replication automatically occurs from RA-y to RA-x for the backups and logs. All backups needed to synchronize RA-y are replicated from RA-x, while new primary backups and redo to RA-y replicate as normal to RA-x. No initial full backup is replicated, which reduces WAN consumption.

Figure 10-2 Backup Anywhere Mode for Data Guard

Description of "Figure 10-2 Backup Anywhere Mode for Data Guard"

A common use case with Data Guard and taking backups only on one database, is when the primary database has production workloads running that backups might impact. Instead, backups are taken from the standby database to its recovery appliance (RA-y). Replication from RA-y to RA-x keeps it in synch.

Request_Only Mode for Data Guard

Demonstrates a how replication request_only mode supports Data Guard.

The purpose of the request_only mode is to allow a recovery appliance to request backups from the second Recovery Appliance of a pair, in order to fill gaps in its backups, such as after an offline period. Figure 10-3 shows two data centers for local and remote, where the primary site is local RA-x and the standby site is remote RA-y. Backups are taken at primary and standby databases, each to their respective local Recovery Appliances. In request_only mode, replication traffic does not occur from RA-x to RA-y. Dataguard and redo logs keeps the remote database in sync with the local database.

The replication servers are configured for bi-direction replication. When using add_replication_server, RA-y gets a protection policy as normal. However, add_replication_server for RA-x has the protection policy with REQUEST_ONLY=TRUE.

When a switchover from the primary (local) to the secondary (remote) has happened, replication traffic does not occur from RA-x to RA-y. However, the RA-x catalog is kept in sync with the RA-y backups. When RA-x is offline, standby backups continue to be sent to RA-y with full recoverability to both data centers. When RA-x comes back online, RA-x requests missing backups from RA-y in order to sync with the current state.

Figure 10-3 Replication Request Mode of Backup Anywhere

Description of "Figure 10-3 Replication Request Mode of Backup Anywhere"

Replication Read-Only Mode when Migrating to New Data Center

Demonstrates a how replication read-only mode supports migrating from one data center to another, and how existing backups on a downstream recovery appliance can be accessed read-only by an upstream recovery appliance.

Figure 10-4 shows the databases in local data center backing up to its RA-x. In the example, all of the local databases need to be moved to the remote data center, and RA-x is to be decommissioned.

The data bases in the remote data center are created by cloning them from RA-x. Then a replication server is created on RA-y as the upstream, and RA-x as the downstream. When using add_replication_server, RA-y gets a protection policy READ_ONLY=TRUE.

The databases in the remote data center start backing up to RA-y. Should a database need to be recovered, backups on local data center RA-x remain accessible through RA-y until RA-x's backup's are obsolete and RA-x is decommissioned.

Figure 10-4 Read-Only Mode of Backup Anywhere

Description of "Figure 10-4 Read-Only Mode of Backup Anywhere"