Configuring Backup and Recovery Settings for Protected Databases (Command Line)

You can use the regular RMAN commands to configure backup and recovery settings for protected databases. These configured settings are used in subsequent backup and recovery operations.

This section contains the following topics:

Configuring Backup Settings for Protected Databases Using the Command Line

RMAN assigns default values for protected database backup settings. You can use the CONFIGURE command to modify these settings according to the backup requirements of your protected database.

To configure backup settings for a protected database using the command line:

Use RMAN to connect to the protected database as TARGET as described in “Connecting to the Protected Database and Recovery Appliance Using CLI”.

The following command starts RMAN and connects to the protected database as target using operating system authentication:
```
% rman target /
```
Use the CONFIGURE command to configure the required backup settings.

The backup settings that you can configure are:
- Fast recovery area
- Media manager for the Recovery Appliance
  
  Configure an RMAN SBT channel that points to the Recovery Appliance backup module.
- Backup optimization
(Optional) To set up redo transport services for the protected database, configure real-time redo transport as described in “Configuring Real-Time Redo Transport”.
See Also:
- “Overview of Protected Database Backup Settings”
- “Configuring RMAN SBT Channels for Recovery Appliance”
- Oracle Database Backup and Recovery User’s Guide for information about configuring backup optimization

Configuring Real-Time Redo Transport

When you configure real-time redo transport, redo data from the protected database is directly transported and stored on the Recovery Appliance. This reduces the window of potential data loss that exists between successive archived log backups.

Configuring real-time redo transport for a protected database is a one-time step. After you set it up, the protected database asynchronously transports redo data to the Recovery Appliance.

Note:

The user you use for redo transport must be the same user you configured to send backups to the Recovery Appliance.
When you clear the real-time redo transport configuration for a protected database, you must manually force a redo log switch to maintain an accurate state for the protected database. The log switch forces the remote file server process (RFS) to stop sending redo data to Recovery Appliance.

For real-time redo transport to work, the receiving database needs a physical user created. On the sending instance, set the redo_transport_user to the user receiving the redo.

In a non-DataGuard environment or a case where there is just a source database sending redo to the Recovery Appliance, just set the redo_transport_user parameter on the Recovery Appliance side to the VPC User defined that has permissions to receive backups and redo and that is a physical user on the Recovery Appliance database.

In a DataGuard environment, because the primary database is sending redo to a standby database, the standby database must have a physical user by the same name as that specified in the redo_transport_user parameter ofinit.ora.

Note: The redo_transport_user parameter defaults to the SYS account and is present in EVERY database. Therefore if all you have is a Primary Database and a Standby Database, then you do NOT need to set the redo_transport_user on the Primary Database - and we use the SYS account.

In a Data Guard environment that also has one or more Recovery Appliance environments, the VPC User must not be SYS (or any super user privilege), and the redo_transport_user must be set to the VPC user that has been created and defined on the Recovery Appliance side. (This is similar in concept to dbms_ra.grant_db_access.) Because the primary database is using the VPC User to login to the Recovery Appliance, it is also using the VPC User to login to the physical standby database. However, by default the VPC User is not present on the physical standby database and by implication is not present on the primary database. Therefore, before the real-time redo is configured to a Recovery Appliance, you must first create and configure the VPC User on the primary database, and ensure the information is applied to the physical standby database. You must also copy the ORAPWD file (different to the wallet used by Recovery Appliance) from the primary to the physical standby. Once these planning steps are complete, then you can continue to setup redo transport to the Recovery Appliance. One of these steps is to set the redo_transport_user parameter to VPC User. Now redo transport from primary to standby and from primary to Recovery Appliance are both using the VPC User to login to the target environment (standby & Recovery Appliance).

To enable real-time redo transport for a protected database:

Ensure that the Recovery Appliance user that the protected database uses to send backups to the Recovery Appliance is configured. This same user will be used for redo transport.

Also ensure that an Oracle wallet is created on the protected database that contains credentials for the Recovery Appliance (and redo transport) user. This process is described in “Creating an Oracle Wallet on the Protected Database”.

See Also: Zero Data Loss Recovery Appliance Administrator’s Guide for information about creating the virtual private catalog account that is used by the Recovery Appliance user
Ensure that the following conditions are met for the protected database:
- ARCHIVELOG mode is enabled
- DB_UNIQUE_NAME parameter is set
Ensure that the REMOTE_LOGIN_PASSWORDFILE and LOG_ARCHIVE_FORMAT initialization parameters are set for the protected database:
```
REMOTE_LOGIN_PASSWORDFILE=exclusive
LOG_ARCHIVE_FORMAT='log_%d_%t_%s_%r.arc'
```
REMOTE_LOGIN_PASSWORDFILE can be set to exclusive or shared.

The LOG_ARCHIVE_FORMAT is not required for real-time redo. The format given is just an example. For redo shipping, the name comes from the container file system. The handle name is internally generated to specify the incarnation, thread, sequence, and ct_key for the file.
Start SQL*Plus and connect to the protected database as a user with the SYSDBA or SYSBACKUP privilege.

The following command uses operating system authentication to connect to the protected database using SYSDBA privileges:
```
% sqlplus / as sysdba
```
Set the LOG_ARCHIVE_CONFIG initialization parameter to include a DG_CONFIG list. Also set the DB_UNIQUE_NAME for the protected database.

The following SQL commands, when connected to the protected database as a user with SYSDBA privilege, set the DB_UNIQUE_NAME and LOG_ARCHIVE_CONFIG parameters for a protected database whose db_unique_name is hr_ptdb and db_name is hr_ptdb:
```
ALTER SYSTEM SET DB_UNIQUE_NAME=hr_ptdb SCOPE=BOTH;
ALTER SYSTEM SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(zdlra2,hr_ptdb)' SCOPE=BOTH;
```
The DB_NAME and the DB_UNIQUE_NAME of the Recovery Appliance database is zdlra2.

See Also:

Oracle Data Guard Concepts and Administration for information about setting a DG_CONFIG list.
Configure an archived log destination that points to the redo staging area on the Recovery Appliance.

You configure an archived log destination by setting one of the LOG_ARCHIVE_DEST_n parameters, where n is any number between 1 and 31. You must include the SERVICE attribute to specify where to store the redo data. Set this attribute to the net service name of the Recovery Appliance database that stores the redo stream from the protected database.

The following example configures the protected database to transport redo data asynchronously to a Recovery Appliance whose net service name is boston.
```
ALTER SYSTEM SET LOG_ARCHIVE_DEST_3='SERVICE=boston
VALID_FOR=(ALL_LOGFILES, ALL_ROLES) ASYNC DB_UNIQUE_NAME=zdlra2' SCOPE=BOTH;
```
See Also:

Oracle Database Reference for information about setting the LOG_ARCHIVE_DEST_n parameter.
Enable logging for the archived redo log destination configured in Step 6 by setting the LOG_ARCHIVE_DEST_STATE_n parameter, where n matches the value used for the LOG_ARCHIVE_DEST_n parameter specified in Step 6.

The following command enables archived redo logging for the destination set using the LOG_ARCHIVE_DEST_3 parameter:
```
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_3='ENABLE' SCOPE=BOTH;
```
See Also: Oracle Database Reference for information about setting the LOG_ARCHIVE_DEST_STATE_n parameter
Set the redo transport user to the Recovery Appliance user that was created for this protected database (see Step 1).

The following example sets the redo transport user to ravpc1:
```
ALTER SYSTEM SET REDO_TRANSPORT_USER=ravpc1 SCOPE=BOTH;
```
Shut down the protected database and restart it.
```
SHUTDOWN IMMEDIATE;
STARTUP;
```
If the protected database uses a parameter file instead of a server parameter file, then add the parameters that were set in Steps 5 to 8 to the parameter file before you start up the protected database.

See Also:

“About Configuring Real-Time Redo Transport for Protected Databases”.
Zero Data Loss Recovery Appliance Administrator’s Guide for information about Oracle Database releases for which redo transport is supported.
Deploying Zero Data Loss Recovery Appliance in a Data Guard Configuration for instructions on how to configure redo transport for Recovery Appliance with Oracle Data Guard

Creating an Oracle Wallet on the Protected Database

An Oracle wallet stores the credentials of the Recovery Appliance user that will be used by the protected database to authenticate with the Recovery Appliance. These same credentials are used for sending backups and redo, if configured. When you install the Recovery Appliance backup module, an Oracle wallet is automatically created. You can also create the wallet and add required entries manually.

Note:

WALLET_ROOT is a required setting for Oracle AI Database 26ai, and is recommended as a best practice for Oracle AI Database 19c to avoid conflicts with other wallets.

A server_seps subdirectory can be used and is recommended as best practice with 26ai, such as ${DB_UNIQUE_NAME} in the WALLET_ROOT parameter set to /u01/app/oracle/admin/${DB_UNIQUE_NAME}/wallet

In the environment section, you specify the SEPS wallet location. Because there could be conflicts with other oracle products that use a wallet (like OUD), the default location for the SEPS wallet should be set to the WALLET_ROOT location, rather than within the $ORACLE_HOME location.

In the past, the channel setting for Recovery Appliance was:

RA_WALLET=location=file:${ORACLE_HOME}/dbs/ra_wallet credential_alias={SEPS entry in wallet}

The recommendation is to set the WALLET_ROOT in the spfile, and store the SEPS wallet within the server_seps directory under this location.

If WALLET_ROOT is set to $ORACLE_BASE/admin/{$DB_NAME}/wallet, the setting would be:

RA_WALLET=location=file:${ORACLE_BASE}/admin/${DB_NAME}/wallet/server_seps/ credential_alias={SEPS entry in wallet}

In the case of multiple Recovery Appliances, store a single wallet in a centralized location and have the sqlnet.ora file on each Recovery Appliance reference that centralized wallet location.

If the wallet cannot be stored in a centralized location for multiple Recovery Appliances, then it needs to be copied to all instances. Create the wallet and master key on the first instance, and then copy the wallet to the other instances. Further, set up the environment variable ORACLE_UNQNAME to separate your database wallets. Then you can refer to them dynamically from the sqlnet.ora as follows for Unix / Linux:

WALLET_LOCATION =
  (SOURCE=(METHOD=FILE)
    (METHOD_DATA =
       (DIRECTORY=/etc/oracle/wallets/$ORACLE_UNQNAME/)))

On Windows-based systems, you can refer to a database dynamically with:

WALLET_LOCATION =
    (SOURCE =
      (METHOD = FILE)
      (METHOD_DATA =
        (DIRECTORY = E:\oracle\%ORACLE_UNQNAME%)))

In addition on Windows, establish a Windows registry key for the database ORACLE_UNQNAME=<dbname> . However, this registry key can only be set for one database on Windows, so this approach is currently restricted to environments where there is only one database running on the Windows server.

Example 1 Creating an Oracle Wallet on the Protected Database

The following command creates an Oracle wallet that stores the credentials of the Recovery Appliance user named ravpc1:

$ mkstore                         \
  -wrl $ORACLE_HOME/oracle/wallet \
  -createALO                      \
  -createCredential zdlra01ingest-scan.acme.com:1521/zdlra01:dedicated ravpc1

Enter the password for the ravpc1 user when prompted. Here, zdlra01 is the net service name of the Recovery Appliance database. The directory $ORACLE_HOME/oracle/wallet must be created before the mkstore command is run.

Example 2 Creating an Oracle Wallet with Multiple User Credentials

The following command creates two sets of credentials in the Oracle wallet of a protected database. In this scenario, ra_user is used both by the Recovery Appliance for normal backup and recovery operations (and real-time redo transport, if enabled) and by the Data Guard standby database for data synchronization. The service name of the Recovery Appliance is zdlra2 and that of the primary database in the Data Guard set up is chicago.

$ mkstore                                             \
  -wrl $ORACLE_HOME/oracle/wallet                     \
  -createALO                                          \
  -createCredential chicagoingest-scan.acme.com:1521/chicago:dedicated ra_user            \
  -createCredential zdlra02ingest-scan.acme.com:1521/zdlra02:dedicated ra_user

Enter the password for ra_user when prompted. The directory $ORACLE_HOME/oracle/wallet must be created before the mkstore command is run.

Configuring an Oracle Wallet for VPC User Credentials

An Oracle wallet can be configured for VPC user credentials for SBT operations among other tasks. You create the external password store and the configure the RMAN SBT channels.

This information applies to RA 21.1 and earlier.

Create a secure external password store (mkstore). The following command creates an Oracle wallet that stores the credentials of the Recovery Appliance user named ravpc1:
```
$ mkstore                         \

  -wrl $ORACLE_HOME/oracle/wallet \

  -createALO                      \

  -createCredential zdlra01ingest-scan.acme.com:1521/zdlra01:dedicated ravpc1
```
Refer to: Creating an Oracle Wallet on the Protected Database
An RMAN SBT channel is configured with the SBT_LIBRARY parameter pointing to the Recovery Appliance backup module. The complete path of the shared library libra.so is specified. The RA_WALLET parameter represents the location of the Oracle wallet that stores the credentials used to authenticate this protected database with the Recovery Appliance. ra-scan is the SCAN of the Recovery Appliance and zdlra5 is the service name of the Recovery Appliance metadata database.
```
CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE'
PARMS 'SBT_LIBRARY=/u01/app/oracle/product/11.2.0.4.0/dbhome_1/lib/libra.so,
ENV=(RA_WALLET=location=file:/u01/app/oracle/product/11.2.0.4.0/dbhome_1/dbs/zdlra
credential_alias=ra-scan:1521/zdlra5:dedicated)' FORMAT '%U_%d';
```
Refer to: Configuring RMAN SBT Channels for Recovery Appliance

Configuring Recovery Settings for Protected Databases Using the Command Line

Use the CONFIGURE command to modify the default values assigned by RMAN for the protected database recovery settings.

To configure recovery settings for a protected database using the command line:

Use RMAN to connect to the protected database as TARGET.

The following command starts RMAN and connects to the protected database as target using operating system authentication:
```
% rman target /
```
Use the CONFIGURE command to configure the required recovery settings described in “Overview of Protected Database Recovery Settings”.

Using RMAN Channels for Recovery Appliance Backup and Recovery Operations

To transfer backups to and from the Recovery Appliance, you must use an RMAN SBT (System Backup to Tape) channel that corresponds to the Recovery Appliance backup module.

The following techniques are available to use RMAN channels for protected database operations:

See Also:

Configuring RMAN SBT Channels for Recovery Appliance

You configure RMAN SBT channels for Recovery Appliance using the RMAN CONFIGURE command. Configuring channels for a protected database creates persistent settings that are applicable to all backup, restore, and maintenance operations on that protected database. Configured settings remain in effect until they are explicitly cleared, changed, or overridden in a particular operation using an ALLOCATE command. Example 3 configures an RMAN SBT channel for a Recovery Appliance. After this configuration, you need not explicitly allocate SBT channels that correspond to the Recovery Appliance backup module for each backup or recovery operation.

Example 3 Configuring an RMAN Channel for Recovery Appliance

In this example, an RMAN SBT channel is configured with the SBT_LIBRARY parameter pointing to the Recovery Appliance backup module. The complete path of the shared library libra.so is specified. The RA_WALLET parameter represents the location of the Oracle wallet that stores the credentials used to authenticate this protected database with the Recovery Appliance. ra-scan is the SCAN of the Recovery Appliance and zdlra5 is the service name of the Recovery Appliance metadata database.

CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE'
PARMS 'SBT_LIBRARY=/u01/app/oracle/product/11.2.0.4.0/dbhome_1/lib/libra.so,
ENV=(RA_WALLET=location=file:/u01/app/oracle/product/11.2.0.4.0/dbhome_1/dbs/zdlra
credential_alias=ra-scan:1521/zdlra5:dedicated)' FORMAT '%U_%d';

Allocating RMAN SBT Channels for Recovery Appliance

Use the RMAN ALLOCATE command to allocate RMAN SBT channels that will be used to back up to or recover from the Recovery Appliance. For a particular operation, you can override the persistent configuration that was set using the CONFIGURE command by explicitly allocating an RMAN SBT channel before the operation. Enclose the ALLOCATE command and the other commands in a RUN block. Example 4 allocates an RMAN SBT channel for the Recovery Appliance and then creates a full backup of the protected database including archived redo logs.

Example 4 Allocating RMAN Channels for Recovery Appliance

This example allocates an RMAN SBT channel with the SBT_LIBRARY parameter specifying the complete path of the Recovery Appliance backup module. The ENV setting is used to specify the configuration parameters used by the Recovery Appliance backup module. ra-scan is the SCAN of the Recovery Appliance and zdlra5 is the service name of the Recovery Appliance metadata database.

RUN
{
ALLOCATE CHANNEL c1 DEVICE TYPE sbt_tape
PARMS='SBT_LIBRARY=/u01/app/oracle/product/12.1.0.2/dbhome_1/lib/libra.so,
ENV=(RA_WALLET=location=file:/u01/app/oracle/product/12.1.0.2/dbhome_1/dbs
credential_alias=ra-scan:1521/zdlra5:dedicated)' FORMAT '%U_%d';
BACKUP INCREMENTAL LEVEL 1 DATABASE PLUS ARCHIVELOG;
}