3 Configuring Protected Databases

This chapter describes how to configure protected databases for backup and recovery operations with Recovery Appliance.

Overview of Configuring Protected Databases for Recovery Appliance

To use Recovery Appliance as a centralized repository for your protected database backups, configuration is required both on the Recovery Appliance and on the protected database. You can use Enterprise Manager Cloud Control (Cloud Control) or RMAN to configure protected databases.

On the Recovery Appliance, the configuration steps include creating a protection policy that is assigned to the protected database, creating a Recovery Appliance user who owns the virtual private catalog, and granting access for the protected databases to a Recovery Appliance user. These steps are described in Zero Data Loss Recovery Appliance Administrator's Guide.

On the protected database, the configuration includes enabling the protected database to access the Recovery Appliance, adding protected database metadata to the Recovery Appliance, and specifying settings that will be used during backup and recovery operations.

Note:

Oracle recommends that you use a server parameter file for your protected database.

Steps to Configure Protected Databases for Recovery Appliance

Configuring protected databases performs the set up tasks required to back up and recover protected databases using Recovery Appliance.

To configure a protected database for Recovery Appliance:

1. Enroll the protected database with a Recovery Appliance.

   Enrolling is a one-time task that must be performed the first time you set up a protected database to use the Recovery Appliance.

   See Also:

   "Enrolling the Protected Database with Recovery Appliance"

2. Configure backup and recovery settings for the protected database.

   These settings are used during backup and recovery operations for the protected database. The settings can be modified according to the backup or recovery task that is being performed.

   See Also:

   • "Configuring Backup and Recovery Settings for Protected Databases (Cloud Control)"

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

3. Perform a test backup to verify that your protected database configuration is successful as described in "Performing a Test Backup Using Cloud Control".

See Also:

• "Overview of Enrolling Protected Databases"

• "Overview of Protected Database Backup Settings"

• "Overview of Protected Database Recovery Settings"

Overview of Recovery Appliance Backup Module

The Recovery Appliance backup module is an Oracle-supplied SBT library that functions as a media management library. RMAN uses the Recovery Appliance backup module to transfer backup data over the network to the Recovery Appliance. The backup module is referenced when allocating or configuring an RMAN SBT channel for backup or recovery operations to the Recovery Appliance. All backups to the Recovery Appliance, and all restores of complete backup sets, are performed by means of this backup module.

Install Location for the Recovery Appliance Backup Module

The Recovery Appliance backup module must be installed in the following locations:

• In the Oracle home of every protected database that uses RMAN to backup protected databases to Recovery Appliance

  If a particular Oracle home is used by more than one protected database, then the backup module must be installed only once in this Oracle home.

• On every upstream Recovery Appliance that sends backups to downstream Recovery Appliances in replication environments

  The library for the Recovery Appliance backup module, libra.so, is preinstalled on Recovery Appliance. However, the Oracle wallet containing the replication user credentials must be created on the upstream Recovery Appliance.

See Also:

• "Installing the Recovery Appliance Backup Module"

• ZDLRA Administrator's Guide

Recovery Appliance Backup Module Configuration File

The Recovery Appliance backup module configuration file contains the configuration settings that are used when protected databases communicate with the Recovery Appliance. The configuration file is created automatically when the Recovery Appliance backup module is installed on the protected database host.

You can also set some Recovery Appliance backup module configuration parameters inline, while configuring or allocating RMAN SBT channels for the Recovery Appliance, as shown in Example 3-3 and Example 3-4.

See Also:

"Configuration Parameters for the Recovery Appliance Backup Module" for the configuration parameters that can be specified while installing the Recovery Appliance backup module

Configuration Parameters for the Recovery Appliance Backup Module

Table 4-1 describes the configuration parameters that are used when installing the Recovery Appliance backup module. These parameters are used by protected databases while backing up to and restoring from Recovery Appliance.

Table 3-1 Recovery Appliance Backup Module Installer Parameters

Parameter Name	Mandatory/Optional	Description
dbUser	Mandatory	User name of the Recovery Appliance user who has the privileges required to connect to, send, and receive backups for the protected database
dbPass	Mandatory	Password for the dbUser user
host	Mandatory	SCAN host name of the Recovery Appliance
port	Mandatory	Listener port number of the Recovery Appliance metadata database
serviceName	Mandatory	Service name of the Recovery Appliance metadata database
walletDir	Mandatory	Location of the Oracle wallet that stores the Recovery Appliance user credentials and the proxy information used to connect to the Recovery Appliance. Note: If an Oracle wallet already exists in this directory, then the Recovery Appliance backup module installer overwrites the existing wallet.
proxyHost	Optional	Host name or IP address and TCP port of a proxy server through which to make an HTTP connection to the Recovery Appliance, in the form host:port.
configFile	Optional	Location of the configuration file that stores the configuration parameters for the Recovery Appliance backup module. The default location on Linux/UNIX is $ORACLE_HOME/dbs/raORACLE_SID.ora. On Windows, the default location is $ORACLE_HOME\database\raORACLE_SID.ora.
libDir	Optional	Location where the shared library for the Recovery Appliance backup module is stored. This library is used to transfer backup data over the network to the Recovery Appliance. It is recommended that you store the shared library in $ORACLE_HOME/lib on Linux/UNIX and in $ORACLE_HOME\database\lib on Windows. When you omit this parameter, the installer does not download the shared library. Downloading the library is not required only when you regenerate the Oracle wallet and configuration file in an Oracle home where the backup module was previously installed.
libPlatform	Optional	Platform name of the protected database host on which the Recovery Appliance backup module needs to be installed. Typically, the Recovery Appliance backup module installer automatically determines the platform on which it is run. You need to set this parameter only if the installer displays an error indicating the platform cannot be determined. Valid values for platform name are: linux64, windows64, solaris_sparc64, solaris_sparcx64, zlinux64, aix_ppc64, and hpux_ia64.
argFile	Optional	File from which the remaining command-line parameters must be read during the Recovery Appliance backup module installation.

See Also:

"Installing the Recovery Appliance Backup Module"

Overview of Enrolling Protected Databases

Enrolling a protected database enables a specific Recovery Appliance to receive backups from the protected database. This is a one-time task that must be performed the first time you set up a protected database to use Recovery Appliance. Enrolling requires steps to be performed on both the Recovery Appliance and the protected database.

Enrolling a protected database performs the following tasks:

• Configures credentials required for the protected database to access the Recovery Appliance

  The protected database administrator requires credentials to authenticate with the Recovery Appliance and perform backup and recovery operations. This is done by associating a protected database administrator user with a Recovery Appliance user (in the Recovery Appliance metadata database). These credentials are stored in an Oracle wallet that is created on the protected database.

• Defines recovery window goals and allocates reserved space on the Recovery Appliance by associating the protected database with an appropriate protection policy

• Grants access to the protected database to the Recovery Appliance user

• Registers the protected database with the Recovery Appliance catalog

  Metadata for protected database backups must be stored in the Recovery Appliance catalog. There are multiple virtual private catalogs within the Recovery Appliance catalog. You must specify the virtual private catalog owner that will manipulate metadata for this protected database.

• When you use Cloud Control, an Enterprise Manager administrator must be provided access to the named credentials that are used to connect to a Recovery Appliance from Cloud Control. Enterprise Manager administrators that administer backup and restore operations for the protected database need access to these credentials in order to connect to the Recovery Appliance when configuring protected databases to backup to and restore from the Recovery Appliance.

See Also:

"Enrolling the Protected Database with Recovery Appliance"

Overview of Protected Database Backup Settings

Before you back up a protected database to Recovery Appliance, you must configure the protected database backup settings. These settings, described in Table 3-2, define the default behavior for your protected database backup environment. RMAN assigns default values for each backup setting. However, it is recommended that you configure settings according to the backup requirements of the protected database.

Table 3-2 Protected Database Backup Settings

Backup Setting	Description
Control file autobackup	Specifies that the control file and server parameter file must be automatically backed up whenever a backup record is added or database structure metadata in the control file changes.
Disk backup location	When configuring backups for the Recovery Appliance, if backup polling is required, then specify the backup polling location.
Backup optimization	Skips the backup of files when an identical file has already been backed up to the Recovery Appliance.
Retention policy	Specifies which backups must be retained to meet your recovery goals. You can either specify a recovery window or a redundancy value. This setting needs to be specified when you use a parallel backup strategy and need to delete obsolete backups created by your existing (not Recovery Appliance) backup strategy.
Archived redo log deletion policy	Specifies when archived redo logs are eligible for deletion. This policy applies to all archiving destinations including the fast recovery area.

See Also:

• Oracle Database Backup and Recovery User's Guide

• "Configuring Backup Settings for Protected Databases Using Cloud Control"

• "Configuring Backup Settings for Protected Databases Using the Command Line"

Overview of Protected Database Recovery Settings

Table 3-3 describes the recovery settings for protected databases. The values of some settings (for example, fast recovery area), are assigned based on how the protected database is configured for the Recovery Appliance.

Table 3-3 Protected Database Recovery Settings

Recovery Setting	Description
Desired mean time to recover	The Mean Time to Recover (MTTR) is the time required to recover the protected database. Plan your backup strategy based on an MTTR that is acceptable for your protected database.
ARCHIVELOG mode	The ARCHIVELOG mode enables archiving of filled groups of online redo log files immediately after a redo log switch occurs. Optionally, configure the following additional properties for the protected database: Log Archive File Name Format Specifies the default file name format for archived redo log files. Use a text string and variables to specify this value. Valid variables are described in Oracle Database Reference. Archived Redo Log Destination To use the fast recovery area as the redo log destination, set the Archived Redo Log Destination to USE_DB_RECOVERY_FILE_DEST. Note: Running the protected database in ARCHIVELOG mode is mandatory if you want to send redo data to the Recovery Appliance. See Also: Oracle Database Administrator's Guide for information about configuring your database to run in ARCHIVELOG mode.
Fast recovery area	A fast recovery area is a disk location that stores backup-related files such as RMAN backups, archived redo log files, control file and online redo log file copies. The fast recovery area automates management of backup-related files and minimizes the need to manually manage disk space for backup-related files. See Also: Oracle Database Backup and Recovery User's Guide for more information about configuring a fast recovery area.

See Also:

• Oracle Database Backup and Recovery User's Guide

• "Configuring Recovery Settings for Protected Databases Using Cloud Control"

• "Configuring Recovery Settings for Protected Databases Using the Command Line"

Enrolling the Protected Database with Recovery Appliance

Enrolling protected databases with a Recovery Appliance includes the following high-level steps:

• Cloud_Control
• Command_Line

To enroll a protected database on the a Recovery Appliance with Cloud Control:

1. Add the protected database to the Recovery Appliance.

   This step must be performed by the Recovery Appliance administrator and is described in Zero Data Loss Recovery Appliance Administrator's Guide.

   When adding a protected database, the Recovery Appliance administrator defines the following: protection policy associated with the protected database, minimum amount of disk space reserved for the protected database on the Recovery Appliance, and the Recovery Appliance user who has the privileges required to back up the protected database.

2. Access the home page of the protected database as described in "Accessing the Protected Database Home Page Using Cloud Control".

3. From the Availability menu, select Backup & Recovery, and then Backup Settings.

   The Backup Settings page is displayed.

4. In the Recovery Appliance Settings section, specify the following settings:

   • Recovery Appliance: Select the name of the Recovery Appliance with which the protected database is being enrolled. Protected database backups will be stored on this Recovery Appliance.

   • Virtual Private Catalog User: Select the virtual private catalog user (Recovery Appliance user) on the Recovery Appliance that has the privileges required to send backups for this protected database. This user must have already been created by the Recovery Appliance administrator as described in Zero Data Loss Recovery Appliance Administrator's Guide.

     Note:

     You can asynchronously transport the protected database redo data directly to the Recovery Appliance by selecting Enable Real-Time Redo Transport. However, you can also enable real-time redo transport while configuring recovery settings for protected databases as described in "Configuring Recovery Settings for Protected Databases Using Cloud Control".

5. Click Apply to save the settings.

After the protected database is enrolled with a Recovery Appliance, you can use the home page for the protected database (shown in Figure 3-1) to perform configuration, backup, and recovery operations for the protected database.

To enroll a protected database on a Recovery Appliance with RMAN:

The enrollment steps on the Recovery Appliance are performed using procedures in the DBMS_RA package. The steps performed on the protected databases use RMAN or operating system commands.

1. Add the protected database to the Recovery Appliance.

   The Recovery Appliance administrator, who has SYS privileges on the Recovery Appliance metadata database, is responsible for adding protected databases. You must provide the following information to enable the Recovery Appliance administrator to decide which protection policy must be assigned to the protected database:

   • recovery window goal for the protected database

   • estimated space required to store backups for this protected database

   See Also:

   Zero Data Loss Recovery Appliance Administrator's Guide

2. Grant the privileges required for performing backup and recovery operations to the Recovery Appliance user that the protected database will use for authentication. This Recovery Appliance user owns the virtual private catalog that stores metadata for the protected database.

   See Also:

   Zero Data Loss Recovery Appliance Administrator's Guide

3. Install the Recovery Appliance backup module.

   This creates the Oracle wallet that stores the credentials required to access the Recovery Appliance and installs the shared library that transfers backup data to the Recovery Appliance.

   See Also:

   " Installing the Recovery Appliance Backup Module "

4. Register the protected database with the Recovery Appliance catalog.

   1. Obtain the name and password of the Recovery Appliance catalog owner that will store backup metadata for this protected database. Contact the Recovery Appliance administrator for these credentials.
   2. Connect to the protected database as TARGET and to the Recovery Appliance catalog as CATALOG as described in "Connecting to the Protected Database and Recovery Appliance Using CLI".
   3. Register the protected database using the REGISTER DATABASE command.

      REGISTER DATABASE;
      
      database registered in recovery catalog
      starting full resync of recover catalog
      full resync complete
      

5. After the registration process is complete, execute a test backup to ensure that the configuration is correct.

   " Running a Test Backup Using the Command Line " describes this task.

Making Cloud Control Aware of externally Configured Databases

This section is an exception case when Enterprise Manager Cloud Control did not perform the initial configuration of the protected database, but you want Cloud Control to manage it going forward. If you attempt to use Cloud Control's Backup Settings page to finish the configuration for these particular databases to send backups to the Recovery Appliance, you may run into a common error. The error is of the nature "this database has been figured outside of Backup Settings" or "virtual private catalog user settings cannot be determined".

The reasons for the error are:

• Cloud Control is not aware of configurations performed outside of Cloud Control, such as on the command line.
• Cloud Control is not aware of configurations performed inside of Cloud Control but by different Cloud Control users. Cloud Control maintains separate backup settings for each individual Cloud Control user. A configuration performed by one user cannot be accessed by another user.

To Make Cloud Control aware of database configurations made outside of Cloud Control:

1. In Cloud Control, go to the protected database Home page.
2. Select the menu item Availability > Backup & Recovery > Recovery Catalog Settings.
3. Select Use Recovery Catalog.
4. Select from the drop-down list the particular Recovery Appliance virtual private catalog (VPC) with which the protected database was registered during the already-performed configuration process.

   If the required VPC is in the list, this should complete the task. Stop here.

   If the required VPC is not in the list, continue with the following steps.

   Make Cloud Control aware of databsase configurations made with Recovery Appliance VPC.

5. In the Cloud Control Targets menu, select Databases.
6. On the Databases page, select the menu item Availability > Recovery Catalogs.
7. Select the base Recovery Appliance catalog.
8. Select Manage Virtual Private Catalogs.
9. Select the radio button for Manage an existing virtual private catalog with Enterprise Manager.
10. Continue through the process.
11. Refresh the Recovery Catalog Settings page.
12. Select from the drop-down list the particular Recovery Appliance virtual private catalog (VPC) with which the protected database was registered during the already-performed configuration process.
    The required VPC should be in the list, and this should complete the task.

Cloud Control becomes aware of Recovery Appliance VPCs when the Recovery Appliance administrator runs the Cloud Control Add Protected Database workflow. If that operation is performed outside of Cloud Control, Cloud Control is not be aware of the VPC and cannot perform the database-side configuration to send backups to the Recovery Appliance or schedule backups to the Recovery Appliance.

The problem will be apparent in the database Backup Settings page, if after selecting a Recovery Appliance, the desired VPC is not listed in the Virtual Private Catalog User choice list.

Accessing the Protected Database Home Page Using Cloud Control

The home page of a protected database in Cloud Control provides a centralized interface to manage configuration, backup, and recovery tasks for the protected database.

To access the protected database home page:

1. Open the Cloud Control interface for Recovery Appliance and log in as the Enterprise Manager administrator of your protected database.

   See "Creating the Enterprise Manager Administrator to Manage Protected Database Operations".

2. From the Targets menu, select Databases.

   The Databases page is displayed. All the protected databases for which you have privileges are listed.

3. In the Name column, click the name of the protected database for which you want to perform backup and recovery operations.

   The home page for the selected protected database is displayed as shown in Figure 3-1. Use the menu options on this page to perform configuration, backup, and recovery tasks for the protected database.

   Figure 3-1 Protected Database Home Page

   
   Description of "Figure 3-1 Protected Database Home Page"

Configuring Backup and Recovery Settings for Protected Databases (Cloud Control)

Before you back up a protected database to the Recovery Appliance, you must configure backup and recovery settings for the protected database. These configured settings are used in subsequent backup and recovery operations.

Note:

You can use Cloud Control to enroll protected databases with Oracle Database 11g Release 2 (11.2) or later. For Oracle Database releases earlier than 11.2, use the command line to configure backup and recovery settings.

Configuring Backup Settings for Protected Databases Using Cloud Control

Backup settings define the default backup environment for the protected database. The settings that configure real-time redo transport and polling locations define how backups are created to the Recovery Appliance. Other settings, such as control file autobackups or backup optimization, define best practices and performance improvements for protected database backups. These settings may be configured based on your requirements.

To configure backup settings for a protected database using Cloud Control:

1. Access the home page for the protected database as described in "Accessing the Protected Database Home Page Using Cloud Control".
2. From the Availability menu, select Backup & Recovery, and then select Backup Settings.

   The Backup Settings page for the protected database is displayed. Figure 3-2 displays the Device tab of the Backup Settings page. The Recovery Appliance Settings section displays the Recovery Appliance and the Recovery Appliance user that you configured in "Enrolling the Protected Database with Recovery Appliance".

   Figure 3-2 Backup Settings Page for Protected Databases

   
   Description of "Figure 3-2 Backup Settings Page for Protected Databases"
3. In the Device tab, configure the following optional settings:

   • To write redo data asynchronously from the protected database to the Recovery Appliance, in the Recovery Appliance Settings section, select Enable Real-Time Redo Transport.

     See Also:

     "About Real-Time Redo Transport"

   • If you want to configure backup polling for the protected database, then specify the polling location in the Disk Backup Location setting of the Disk Settings section.

     Disk backups created to this location will then be automatically picked up by the Recovery Appliance if the protected database is assigned to a protection policy that specifies this location as a polling location. Polling policies are created by the Recovery Appliance administrator.

     See Also:

     • Zero Data Loss Recovery Appliance Administrator's Guide for information about backup polling policies

     • "Mounting the NFS Storage for Backup Polling"

   • If the protected database is on RAC, the operating system login credentials must be the same on all nodes.
4. In the Policy tab, configure settings that define the objects that must be backed up.

   Although it is not mandatory to configure the settings in this section, it is strongly recommended that you configure automatic backups for the control file and server parameter file. Table 3-2 describes these configuration settings.

   • To configure control file and server parameter file autobackups:

     • Select Automatically backup the control file and server parameter file (SPFILE) with every backup and database structural change.

     • In the Autobackup Disk Location field, specify an existing directory or Automatic Storage Management (ASM) disk group name to which the control file and server parameter file autobackups must be stored. If no location is specified, then the autobackups are stored in the local fast recovery area.

   • To enable backup optimization, select Optimize the whole database backup by skipping unchanged files such as read-only and offline datafiles that have been backed up.

   • To enable block change tracking, select Enable block change tracking for faster incremental backups and specify the name of the block change tracking file in the Block Change Tracking File field.

   • In the Tablespaces Excluded from Whole Database Backup section, ensure that you do not add any tablespaces.

     Note:

     When backing up to Recovery Appliance, the initial full backup of the protected database must contain all the tablespaces.

   • In the Archived Redo Log Deletion Policy section, select one of the following options to specify how RMAN must handle redo log file deletion for the local backups stored on the protected database host:

     • None

       Archived redo logs in the fast recovery area are eligible for deletion if they have been backed up at least once or if they are obsolete according to the backup retention policy.

     • Delete archived redo log files after they have been backed up the specified number of times

       Deletes archived redo log files that have been backed up the number of times specified in the Backups field.

   Note:

   In the Retention Policy section, you need not specify any values. The settings in the Retention Policy section are not used for backups to Recovery Appliance, as the retention policy is inherited from the protection policy that is associated with the protected database when it is enrolled with the Recovery Appliance.

5. Click Apply to save the backup settings.

See Also:

"Overview of Protected Database Backup Settings"

Configuring Recovery Settings for Protected Databases Using Cloud Control

Recovery settings define the default recovery environment for the protected database. The only mandatory setting for Recovery Appliance is the Log Archive Filename Format. Configuring the remaining recovery settings is optional.

To configure recovery settings for a protected database using Cloud Control:

1. Access the home page for the protected database as described in "Accessing the Protected Database Home Page Using Cloud Control".
2. From the Availability menu, select Backup & Recovery, then select Recovery Settings.

   The Recovery Settings page for the protected database is displayed as shown in Figure 3-3.

   Figure 3-3 Protected Database Recovery Settings

   
   Description of "Figure 3-3 Protected Database Recovery Settings"
3. In the Instance Recovery section, specify the Desired Mean Time To Recover.
4. In the Media Recovery section, perform the following steps:

   • (Optional) Select ARCHIVELOG Mode.

   • (Optional) In the Log Archive Filename Format field, specify the format used for archived redo log file names.

   • In the Archived Redo Log Destination field, provide a destination to store archived redo log files or specify USE_DB_RECOVERY_FILE_DEST to indicate that the redo log files must be stored in the local fast recovery area.

     If you selected Enable Real-Time Redo Transport in the Backup settings for this protected database, then the archived redo log destination is automatically set.

5. Configure a local fast recovery area for the protected database by specifying the following in the Fast Recovery section:

   • In the Fast Recovery Area Location field, specify the file-system or ASM location where backup-related files are stored. Oracle recommends that you configure a fast recovery area for the protected database. Local backups of the protected database are stored in the fast recovery area.

   • In the Fast Recovery Area Size field, specify the disk space quota allocated to the fast recovery area. This is the maximum storage that can be used by the recovery area for this protected database. Specifying a size is mandatory when you configure a fast recovery area.

6. Click Apply to save the recovery settings.

See Also:

• Table 3-3 for a brief description of the recovery settings

• "Overview of Protected Database Recovery Settings"

Clearing the Backup Configuration of Protected Databases Using Cloud Control

You can clear the backup configuration of a protected database and remove its existing Recovery Appliance settings. Clearing the backup configuration removes the currently-configured Recovery Appliance and virtual private catalog user, any configured RMAN channels, and the real-time redo transport configuration.

To clear the backup configuration for a protected database using Cloud Control:

1. Access the home page for the protected database as described in "Accessing the Protected Database Home Page Using Cloud Control".
2. From the Availability menu, select Backup & Recovery, and then select Backup Settings.

   The Backup Settings page for the protected database is displayed as shown in Figure 3-2.

3. In the Recovery Appliance Settings section, click Clear Configuration.

   Note:

   If real-time redo transport was configured for the protected database, then you must manually force a redo log switch to maintain an accurate state for the Redo Shipping column of this protected database in Cloud Control.

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

• Configuring Recovery Settings for Protected Databases Using the Command Line

• Using RMAN Channels for Recovery Appliance Backup and Recovery Operations

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:

1. 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 /
   

2. 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

3. (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:

1. 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

2. Ensure that the following conditions are met for the protected database:

   • ARCHIVELOG mode is enabled

   • DB_UNIQUE_NAME parameter is set

3. 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.

4. 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
   

5. 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

6. 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

7. 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

8. 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;
   

9. 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:

The sqlnet.ora file in the protected database must contain the location of the Oracle wallet. Typically, the wallet location is automatically added to this file when you install the Recovery Appliance backup module.

Note:

Databases that use Enterprise User Security (EUS) WALLET_ROOT format are not supported for protected database configuration. Only WALLET_LOCATION is supported.

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

If the wallet cannot be stored in a centralized location for multiple ZDLRAs, 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 3-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 3-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 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:

1. 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 /
   

2. Use the CONFIGURE command to configure the required recovery settings described in "Overview of Protected Database Recovery Settings".

See Also:

Oracle Database Backup and Recovery User's Guide

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:

• Configuring RMAN SBT Channels for Recovery Appliance

• Allocating RMAN SBT Channels for Recovery Appliance

See Also:

• "About RMAN SBT Channels and Protected Databases"

• "Installing the Recovery Appliance Backup Module"

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-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-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 3-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 3-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;
}

Configuring Encrypted SBT

The LIBRA.SO module supports both the legacy mode (RA21.1) and the encrypting SBT option (RA23.1). In both modes, the external password store is created in the same way, but then the RMAN SBT channels is configured differently.

• RA23.1
• RA21.1

This information applies to RA 23.1 and later.

1. 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

2. 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/19.0.0.0/dbhome_1/lib/libra.so,
   ENV=(RA_FORMAT=true,
   RA_WALLET=location=file:/u01/app/oracle/product/19.0.0.0/dbhome_1/dbs/zdlracredential_alias=ra-scan:1521/zdlra5:dedicated)' 
   FORMAT '%U_%d';

3. In addition to this, RMAN compression and RMAN encryption needs to be configured. This can be done either one time or as part of each backup job.

   configure compression algorithm  'low';
   set encryption on;
   configure device type 'sbt_tape' backup type to compressed backupset;

4. An RMAN SBT channel is allocated 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.

   set echo on
   configure compression algorithm 'low';
   set encryption on;
   configure device type 'sbt_tape' backup type to compressed backupset;
   RUN{ALLOCATE CHANNEL c1 DEVICE TYPE sbt_tape 
   PARMS='SBT_LIBRARY=/u01/app/oracle/product/19.0.0.0/dbhome_1/lib/libra.so,
   ENV=(RA_FORMAT=true, 
   RA_WALLET=location=file:/u01/app/oracle/product/19.0.0.0/dbhome_1/dbs/zdlracredential_alias=ra-scan:1521/zdlra5:dedicated)' 
   FORMAT '%U_%d';
   BACKUP INCREMENTAL LEVEL 1 FILESPERSET 1 SECTION SIZE 64G DATABASE PLUS ARCHIVELOG NOT BACKED UP FILESPERSET 8;}

5. The above is performed by the protected database, and the Recovery Appliance administrator does not need to know this is happening. However, the Recovery Appliance administrator can prevent un-encrypted data from being sent to the appliance. This is achieved with the CREATE_PROTECTION_POLICY or UPDATE_PROTECTION_POLICY and specifying the parameter SECURE_MODE = YES.

   SQL> exec dbms_ra.update_protection_policy(
   protection_policy_name => ‘GOLD’, 
   secure_mode => ‘YES’);

6. After this configuration, if an attempt is made to run an unencrypted (legacy) backup, an error message occurs similar to:

   RMAN-00571:
   ===========================================================RMAN-00569: =============== ERROR
   MESSAGE STACK FOLLOWS ===============RMAN-00571:
   ===========================================================RMAN-03009: failure of backup
   command on channel_29 channel at 01/19/2023 10:27:06ORA-27192: skgfcls: sbtclose2
   returned error - failed to close fileORA-19511: non RMAN, but media
   manager or vendor specific failure, error text:KBHS-01404:  See trace file
   /u01/app/oracle/diag/rdbms/<dbuniquename>/<sid>/trace/sbtio_204486_140658931245376.log  for
   detailsKBHS-00719: Error 'recovery
   appliance Error'; ORA-64868: Only RMAN encrypted backups are supported on this Recovery
   Appliance.
   KBHS-00700: HTTP

7. Additionally, if real-time redo is enabled, then the LAD parameter needs to be set ENCRYPTION=enable.

   ALTER SYSTEM SET LOG_ARCHIVE_DEST_3='SERVICE=boston 
   VALID_FOR=(ALL_LOGFILES, ALL_ROLES) 
   ASYNC DB_UNIQUE_NAME=zdlra2 encryption=enable' SCOPE=BOTH;

   Without this, Recovery Appliance administrator sees the message.

   2023-01-19T18:25:41.933868+00:00
   Recovery Appliance failure on ospid: 221805; 
   Errors: ORA-64869: Unencrypted redo is not allowed for database <dbname>.

This information applies to RA 21.1 and earlier.

1. 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

2. 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

TLS for Protected Databases

Transport Layer Security (TLS) between a Recovery Appliance and client databases involves the use of certificates that authenticate and encrypt communication.

• Trusted Certificates are generally obtained from a trusted Certified Authority (CA) through an application process (at the corporate level). These certificates are generally used between external systems. Because they were created by the CA, these certificates do not contain any local host names. The file type is *.pem.

• Signed Certificates are created as needed and contain the local host name as well as location and organization information as part of what authenticates it. These certificates are often used between local or internal systems. Signed certificates are specific to each Recovery Appliance. The file type is *.p12.

Both types of certificates are required.

The details for obtaining or creating certifications are provided in the Zero Data Loss Recovery Appliance Administrator's Guide in TLS Overview.

Performing Test Backup and Recovery Operations

After you enroll the protected database with a Recovery Appliance, it is recommended that you perform a test backup and recovery operation. This testing helps confirm that your configuration settings are accurate and that the backup to and recovery from the Recovery Appliance are performed successfully. If you encounter any problem with the test backup or recovery, you may correct your settings and reconfigure your protected database.

Running a Test Backup Using the Command Line

After configuring a protected database for Recovery Appliance, you can test the connection to the Recovery Appliance by attempting a test backup.

To create a test backup of the protected database:

1. Connect to the protected database as TARGET and to the Recovery Appliance catalog as CATALOG as described in "Connecting to the Protected Database and Recovery Appliance Using CLI".
2. Configure an RMAN SBT channel for the Recovery Appliance as described in "Configuring RMAN SBT Channels for Recovery Appliance".

   A good guideline for choosing the number of channels is to start with the number of channels that are currently used for incremental backups or a default of 2 or 4 channels per node depending on the number of cores or CPUs.

3. Use the following RMAN command to perform a full backup:

   BACKUP DEVICE TYPE SBT CUMULATIVE INCREMENTAL LEVEL 1 DATABASE
       PLUS ARCHIVELOG FORMAT %d_%U;
   

   This BACKUP command creates a new level 0 backup, if one does not already exist, when it is run for the first time.

   Note:

   Archive redo logs can be included with regular backups because the Recovery Appliance keeps track of which logs may need to be backed up and avoids backing up the same archived redo logs twice. The benefit of including archived redo logs is in the case where there is a gap. Without archived redo logs, gap detection may be delayed.

Running a Test Recovery Using the Command Line

After creating a test backup of the protected database to Recovery Appliance, you can test this backup by performing a test recovery.

To perform a test recovery of the protected database:

1. Shutdown and restart the protected database in NOMOUNT mode.
2. Connect to the protected database as TARGET and to the Recovery Appliance catalog as CATALOG.

   See "Connecting to the Protected Database and Recovery Appliance Using CLI".

3. Configure an RMAN SBT channel for the Recovery Appliance as described in "Configuring RMAN SBT Channels for Recovery Appliance".
4. Use the following RMAN command to restore the previously created test backup from the Recovery Appliance. Because the VALIDATE option is used, this can be done without interfering with the production database.

   RESTORE VALIDATE DATABASE;
   

If these backup and recovery procedures succeed, then the client database is ready to perform regular backups to the Recovery Appliance.

Performing a Test Backup Using Cloud Control

After configuring the protected database, verify that the configuration is accurate by performing a test backup.

To perform a test backup using Cloud Control:

1. Access the home page for the protected database as described in "Accessing the Protected Database Home Page Using Cloud Control".
2. From the Availability menu, select Backup & Recovery, then Backup Settings.

   The Device tab of the Backup Settings page is displayed. Figure 3-4 displays the Recovery Appliance Settings section of this page.

   Figure 3-4 Recovery Appliance Settings Section of Backup Settings Page

   
   Description of "Figure 3-4 Recovery Appliance Settings Section of Backup Settings Page"
3. In the Recovery Appliance Settings section, click Test Backup.

   A test backup is initiated by Cloud Control and the Processing: Test Recovery Appliance Backup page is displayed.

   If the backup is successful, the following message is displayed: Recovery Appliance backup test successful.

   If there is an error when performing the backup, then an error message stating "Recovery Appliance backup test failed" is displayed. Click View Error Details to display the View Error Details page containing detailed information about the cause of the error. Rectify the problem and then perform a test backup.

Configuring Multiple Protected Databases to Send Backups to Recovery Appliance

Databases become "protected by a Recovery Appliance" when they are configured to send backups to the Recovery Appliance.

You can perform this procedure on individual databases using the Enterprise Manager (EM) Backup Settings page. However, the Enterprise Manager Command Line Interface (EMCLI) configure_db_ha command greatly facilitates configuring multiple databases concurrently.

Because protected databases can be hosted on a variety of hardware platforms, a corresponding RMAN backup module is required for each platform. When a new version of this module becomes available and it needs to be installed on many systems, the same emcli configure_db_ha command greatly simplifies this complex maintenance task.

• Update EM Software Library with Latest Version of RMAN Recovery Appliance Backup Module. This task is required for Scenario #2, and for some variants in Scenario #1.
• Scenario #1: Configure Multiple Protected Databases to Send Backups to Recovery Appliance.
• Scenario #2: Update the RMAN Recovery Appliance Backup Module for Multiple Protected Databases

These scenarios are independent. If EM handles the protected database management, scenario #1 is performed one time for each protected database, followed by periodic maintenance using variations of these scenarios.

Scenario #2 requires that the latest version of RMAN Recovery Appliance Backup module be uploaded to the EM software library. This can be accomplished manually as needed, or in a scheduled job.

Update EM Software Library with Latest Version of RMAN Recovery Appliance Backup Module

This section is required when Enterprise Manager (EM) maintains the RMAN Recovery Appliance backup module used by protected databases, because it supplies EM's software library with the latest RMAN module.

The RMAN Recovery Appliance Backup Module is different for each supported operating system where protected databases are hosted.

The steps in this section update the software library with the latest version of the RMAN Recovery Appliance Backup Module. Later EM installs from the software library the RMAN module appropriate for each protected database.

• Option 1: Configuring EM for Automatic Upload of RMAN Module to Software Library. Use this option to automatically maintain the software library with the latest RMAN backup module.
• Option 2: Using EMCLI to Manually Upload RMAN Backup Module to Software Library. Use this option if EM does not have direct access to Oracle Cloud (offline mode).

Option 1: Configuring EM for Automatic Upload of RMAN Module to Software Library

This option creates a re-occurring job in EM that locates and downloads new versions of the RMAN Recovery Appliance backup modules on Oracle Cloud to EM.

This option assumes that EM has direct access to Oracle Cloud in order to locate and download the RMAN Recovery Appliance backup modules. You schedule a job in EM for Update High Availability Software in Software Library

1. In EM, navigate to Job Library.
2. In the pull-down for Create Library Job, select Update High Availability Software in Software Library and then Go.

   Figure 3-5 Create Library Job

   
   Description of "Figure 3-5 Create Library Job"
3. Specify a name for the library job. In this example, the name is "updateRA3".

   Figure 3-6 Create Library Job, General Tab

   
   Description of "Figure 3-6 Create Library Job, General Tab"
4. On the Parameters tab and the pull-down for Backup Module Type, select Recovery Appliance.

   Figure 3-7 Create Library Job, Parameter Tab

   
   Description of "Figure 3-7 Create Library Job, Parameter Tab"
5. On the Schedule tab, enter appropriate details for this job's schedule. The job is intended to run on a repeating schedule (e.g., once a week) so that it can periodically check Oracle Cloud for new backup module versions.

   Figure 3-8 Create Library Job, Schedule Tab

   
   Description of "Figure 3-8 Create Library Job, Schedule Tab"

Later when this job is run at its scheduled time, it scans a designated location in the Oracle Cloud that contains the latest version of the RMAN Recovery Appliance backup module for all supported protected database platforms. It compares that version to the latest version maintained in the EM software library. If the version found in Oracle Cloud is newer, that version for all supported platforms is down-loaded into the software library. Older version of RMAN backup are archived in the software library.

Protected databases that are managed by EM have their RMAN backup modules updated to this new version with the emcli config_db_ha command.

Here is an example of the job output when a new backup module version is found and downloaded to the Software Library.

Figure 3-9 Job Output when new software module found

Description of "Figure 3-9 Job Output when new software module found"

Option 2: Using EMCLI to Manually Upload RMAN Backup Module to Software Library

This option is a manual step that is repeated whenever a new version of the RMAN Recovery Appliance backup module is needed for the EM software library to distribute.

This option is intended for "offline" mode when EM does not have direct access to Oracle Cloud.

1. Manually download the new version of RMAN Recovery Appliance backup module (for all supported platforms) from Oracle Cloud to a location accessible to the system where EMCLI commands are invoked.

   For this example, the latest backup module versions for the Linux and AIX platforms were downloaded from Oracle Cloud to the /home directory.

2. Use EMCLI to get the new version into the software library.

   emcli configure_db_ha –uploadBackupModule –module_type="ra" –module_location="/home/ra_linux64.zip,/home/ra_aix.zip"

   New module versions for multiple platforms can be uploaded to the software library concurrently.

   In the above example, the latest versions for the Linux and AIX platforms, which were previously downloaded from Oracle Cloud to the /home directory, are made available in the software library.

Complete usage of this command and all other forms of the configure_db_ha verb discussed below can be found in Cloud Control Command Line Interface Guide.

Scenario #1: Configure Multiple Protected Databases to Send Backups to Recovery Appliance

Uses Enterprise Manager to manage the configuration of multiple protected databases.

After the Recovery Appliance administrator has enrolled a protected database, the database must be configured locally to send backups and redo to the Recovery Appliance. This configuration procedure can be performed for an individual database from the Enterprise Manage (EM) Backup Settings page. However, performing this procedure on multiple databases might not be practical through the EM user interface.

Enrolling multiple databases is more easily achieved through the EM command line interface (EMCLI) and the configure_db_ha -configureRABackup command. It performs the configuration procedure for multiple databases concurrently.

The following examples illustrate different usages of this command to perform the initial configuration for individual and multiple databases.

Single-instance Database

The following example of emcli configure_db_ha –configureRABackup configures one single-instance database to send backups to and ship redo to a Recovery Appliance.

If the RMAN backup module is already installed in the database Oracle home, it does not install the latest RMAN backup module from the software library. The command uses the EM named database and host credentials.

emcli configure_db_ha –configureRABackup –ra_target_name="Chicago ZDLRA" –ra_user="rauser1" –target_name="Finance" –target_type="oracle_database" –db_cred="DB_USER" –db_host_cred="DB_HOST_USER" –enable_redo_ship

One Cluster Database

The following example of emcli configure_db_ha –configureRABackup configures one cluster database to send backups to a Recovery Appliance.

The command does not use the –enable_redo_ship option, so redo logs are not shipped. The –force_backup_module_install option specifies that the latest RMAN backup module from the software library should be installed in the Oracle home of each cluster database instance. The command uses the EM named database and host credentials.

emcli configure_db_ha –configureRABackup –ra_target_name="Chicago ZDLRA" –ra_user="rauser1" –target_name="Finance" –target_type="rac_database" –force_backup_module_install

Single-Instance and Cluster Databases

The following example of emcli configure_db_ha –configureRABackup uses an input file, –input_file="/tmp/dblist", to specify the single-instance and cluster databases to be configured..

The –enable_redo_ship option is specified so that backups and redo logs are shipped to the Recovery Appliance. The –force_backup_module_install option specifies that the latest RMAN backup module from the software library should be installed in the Oracle home of each database. The command uses the same EM named database and host credentials for all databases.

emcli configure_db_ha –configureRABackup –ra_target_name="Chicago ZDLRA" –ra_user="rauser1" –input_file="/tmp/dblist" –db_cred="DB_USER" –db_host_cred=" DB_HOST_USER" –enable_redo_ship –force_backup_module_install –staging_directory=”/tmp/stage"

The content of the input file, /tmp/dblist, used by in this example specifies a single-instance database and a cluster database

target.0.target_name=db1
target.0.target_type=oracle_database
target.1.target_name=rac1
target.1.target_type=rac_database

Multiple Databases from an Input File

The following example of emcli configure_db_ha –configureRABackup uses an input file, –input_file="/tmp/dblist", to specify the databases to be configured.

The –enable_redo_ship option is specified so that backups and redo logs are shipped to the Recovery Appliance. If the RMAN backup module is already installed in the database Oracle home, then it does not install the latest RMAN backup module from the software library. The -schedule option sets a future time for the operation. The command uses the same EM named database and host credentials for all databases.

emcli configure_db_ha –configureRABackup –ra_target_name="Chicago ZDLRA" –ra_user="rauser1" –input_file="/tmp/dblist" –db_cred="DB_USER" –db_host_cred="DB_HOST_USER" –enable_redo_ship -schedule="start_time:2016/06/28 18:31;tz:PST;"

Maintaining Protected Database Configurations

Variations of emcli configure_db_ha -configureRABackup command can be re-run as needed against the same databases to update the configuration.

All aspects of the local database configuration (such as the wallet, backup module, RMAN configuration) are automatically updated if needed by the EM deployment procedure invoked by the command. In this way, ongoing maintenance of the configuration for multiple database can be accomplished with one command.

Example maintenance scenarios include the following:

• Update the Virtual Private Catalog (VPC) credentials used by each protected database to send backups to Recovery Appliance after a VPC user password change: Assuming the EM named credentials corresponding to the VPC user have been updated (required for EM operations that use this VPC user), the EM deployment procedure automatically updates all the protected database wallets with the new credentials.

• Update the Recovery Appliance RMAN backup module in all Oracle homes of each protected database: This can be done as part of a complete protected database configuration, or separately as a stand-alone operation. If the -force_backup_module_install option was specified during the database configuration, the EM deployment procedure updates the backup module in each Oracle home with the latest version present in the EM Software Library.

• Enable redo shipping to Recovery Appliance for databases where it was not previously enabled: This can be done by re-running the command with the -enable_redo_ship option and an input file listing the databases that need redo shipping enabled.

The complete syntax and input file format can be found in EM Command Line Interface .

Scenario #2: Update the RMAN Recovery Appliance Backup Module for Multiple Protected Databases

This scenario uses the command emcli configure_db_ha -installSoftware to update the RMAN Recovery Appliance Backup module for multiple protected databases.

The following examples illustrate different usages of this command for individual and multiple databases:

• Installing RMAN Backup Module on a Single-Instance Database
• Installing RMAN Backup Module on a Cluster Database
• Installing RMAN Backup Module on Multiple Databases

Installing RMAN Backup Module on a Single-Instance Database

The following example of emcli configure_db_ha –installSoftware installs the latest RMAN backup module from the software library into the Oracle home of a single-instance database if no RMAN module is already present.

The command uses the EM named database and host credentials.

emcli configure_db_ha –installSoftware –install_backup_module –module_type=“ra" –target_name=“db1" –target_type="oracle_database" –db_host_cred="OMS_HOST_CRED"

Installing RMAN Backup Module on a Cluster Database

The following example of emcli configure_db_ha –installSoftware installs the latest RMAN backup module from the software library into the Oracle homes of each instance of one cluster database.

The –force_backup_module_install option specifies that the latest RMAN backup module from the software library should be installed in the Oracle home of each database regardless of whether the module is already installed. The command uses the same EM named database and host credentials for all databases.

emcli configure_db_ha –installSoftware –install_backup_module –module_type=”ra” –target_name="Finance" –target_type="rac_database" –force_backup_module_install –db_host_cred="DB_HOST_USER"

Installing RMAN Backup Module on Multiple Databases

The following example of emcli configure_db_ha –installSoftware uses an input file to specify which databases should receive the latest RMAN backup module.

The –force_backup_module_install option specifies that the latest RMAN backup module from the software library should be installed in the Oracle home of each database regardless of whether the module is already installed. The operation is scheduled start time in the future.

emcli configure_db_ha –installSoftware –install_backup_module –module_type=“ra“ –force_backup_module_install –input_file=“/tmp/dblist“ -schedule="start_time:2016/06/28 18:31;tz:PST;

The content of –input_file="/tmp/dblist" specifies a single-instance and a cluster database that are used by this command.

target.0.target_name=db1
target.0.target_type=oracle_database
target.0.db_cred=DB_SYS_CRED
target.0.db_host_cred=HOST__CRED1
target.1.target_name=rac1
target.1.target_type=rac_database
target.1.db_cred=DB_SYS_CRED2
target.1.db_host_cred=HOST_CRED2

Note the input file specifies different database and host named credentials for each database, illustrating the flexibility offered by using an input file for multiple databases.