Migration Considerations for Protected Database Administrators

Planning to Migrate Protected Databases to Recovery Appliance

A basic backup strategy involving Recovery Manager (RMAN) consists of a set of backup scripts that are scheduled to run at specified intervals. When you decide to use Recovery Appliance for data protection, you need to develop a plan to migrate your existing backup strategy to one that uses Recovery Appliance.

This section provides a high-level overview of the tasks involved in migrating your existing protected database backup strategy to Recovery Appliance. Details about how to perform each task are provided in the following sections.

If you are starting with Recovery Appliance for your protected database's data protection, then skip to Configuring Protected Databases.

Steps: Planning to Migrate Protected Databases to Recovery Appliance

Adapt the existing backup strategy for Recovery Appliance

All RMAN commands, with the exception of those listed in Differences in RMAN Commands will work with Recovery Appliance. You must make some changes to your existing RMAN backup strategy to adapt it for Recovery Appliance.

See Also:

"Adapting an Existing Backup Strategy for Recovery Appliance"
Migrate backup metadata to the Recovery Appliance catalog

Your existing backup strategy may be using an RMAN recovery catalog to store backup metadata for the protected database. You can migrate existing backup metadata for your protected database to the Recovery Appliance catalog.

See Also:

"Migrating Backup Metadata to the Recovery Appliance Catalog"
Migrate existing protected database backups to the Recovery Appliance

You can migrate valid database backups that are within the configured recovery window goals to the Recovery Appliance. Alternately, you can start backing up to the Recovery Appliance without migrating existing protected database backups.

See Also:

"Migrating Existing Backups to Recovery Appliance"

Adapting an Existing Backup Strategy for Recovery Appliance

When you decide to move from an existing backup strategy to one that uses Recovery Appliance for data protection, you need to make some modifications to your existing strategy. All RMAN backup and recovery scripts that you currently use will work in a Recovery Appliance environment with minor modifications.

The following modifications are required to adapt your existing RMAN backup and recovery scripts to work with Recovery Appliance:

Modify RMAN channel configuration or channel allocations so that they use SBT channels corresponding to the Zero Data Loss Recovery Appliance backup module (Recovery Appliance backup module) instead of disk or tape channels.
Modify RMAN backup scripts and remove commands whose behavior is modified in Recovery Appliance.
Simplify existing RMAN scripts by removing commands that are not required in a Recovery Appliance environment.

See Also:

Modifying RMAN Channel Configurations

An RMAN channel represents one stream of data to or from a backup device. The channel reads data from the input device, processes it, and then writes it to the output device. RMAN supports the following types of channel configurations:

DISK (backups are stored on disk)
SBT

Backups are stored on one of the following: tape using media management software such as Oracle Secure Backup, Recovery Appliance using the Recovery Appliance backup module, or on the Oracle Cloud.

Existing RMAN scripts will use either a DISK channel to backup to disk or an SBT channel to backup to tape. To back up to or restore from Recovery Appliance, you must configure use an SBT channel that corresponds to the Recovery Appliance backup module installed on the protected database host. In a Recovery Appliance environment, your backup and recovery scripts must allocate an SBT channel with the SBT_LIBRARY parameter pointing to the Recovery Appliance backup module.

See Also:

"Using RMAN Channels for Recovery Appliance Backup and Recovery Operations" for examples of allocating or configuring RMAN channels for use with Recovery Appliance

Modifying RMAN Backup and Recovery Scripts

If your backup scripts use any RMAN commands whose functionality is slightly modified in Recovery Appliance (listed in Differences in RMAN Commands), then you must modify the scripts to replace these commands with the appropriate new commands. For example, the RMAN UNREGISTER DATABASE command functionality works differently with Recovery Appliance. Therefore, you must modify your existing RMAN scripts to replace the UNREGISTER DATABASE command. Note that the DBMS_RA.DELETE_DB procedure that must be used instead of UNREGISTER DATABASE can be used only from SQL*Plus, not RMAN.

If your existing backup strategy uses the RMAN incrementally updated backup strategy that merges successive level 1 incremental backups with the initial image copy backup, then modify the RMAN commands to use the Recovery Appliance incremental-forever backup strategy.

See Also:

Backing Up Protected Databases
Zero Data Loss Recovery Appliance Administrator's Guide for information about using the DBMS_RA.DELETE_DB procedure

Removing Unnecessary RMAN Commands

Typically RMAN backup and recovery scripts contain commands to validate backups. This includes commands such as VALIDATE and CROSSCHECK. Because Recovery Appliance automatically validates all backups from protected databases before writing them to the storage, these commands are no longer required after migrating your existing data protection strategy to use Recovery Appliance. While adapting your existing strategy to use Recovery Appliance, remove the VALIDATE and CROSSCHECK commands from your scripts.

From your existing backup strategy, you also need to remove those operations that will now be performed by Recovery Appliance, such as backing up to tape and deleting obsolete backups.

Migrating Backup Metadata to the Recovery Appliance Catalog

Your existing RMAN backup strategy typically involves storing backup metadata in an RMAN recovery catalog. When migrating to a data protection strategy that uses Recovery Appliance, you need a strategy to manage existing backup metadata that is stored in an RMAN recovery catalog.

See Also:

Zero Data Loss Recovery Appliance Administrator's Guide for information about the Recovery Appliance catalog
Oracle Database Backup and Recovery User's Guide for more information about the RMAN recovery catalog

To manage existing backup metadata while moving to Recovery Appliance, use one of the following strategies:

Import existing backup metadata for your protected database into the Recovery Appliance catalog

Importing backup metadata stored in an RMAN recovery catalog ensures that existing backup metadata for your protected databases is now contained in the Recovery Appliance catalog.

See Also:

"Importing Protected Database Metadata into the Recovery Appliance Catalog"
Retain existing backup metadata in the RMAN recovery catalog and store metadata for backups created to Recovery Appliance in the Recovery Appliance catalog

You must manage the RMAN recovery catalog in conjunction with the Recovery Appliance catalog. To create local backups and store the backup metadata in the RMAN recovery catalog, use the steps described in "Creating Local Backups". To create backups to a Recovery Appliance, configure the protected database and then back up to the Recovery Appliance.
See Also:
- "Configuring Protected Databases"
- "Backing Up Protected Databases"

Connecting to the Protected Database and Recovery Appliance Using CLI

To perform protected database backup or recovery operations using a Recovery Appliance, you must connect to the protected database and to the Recovery Appliance catalog. The connection to the protected database is established as target using operating system authentication or password file authentication. The connection to the Recovery Appliance catalog must be established as catalog. If the protected database is a pluggable database (PDB), then you must connect to the root of the multitenant container database (CDB) as TARGET.

To connect to a protected database (non-CDB) and Recovery Appliance:

Start RMAN.
```
% rman
```
Use the CONNECT command to connect to the protected database as TARGET and to the Recovery Appliance catalog as CATALOG.

The following command connects to the protected database as the SYS user. ra_rman_user is the Recovery Appliance user that the protected database uses to authenticate with the Recovery Appliance. ra1 is the net service name of the target Recovery Appliance that is configured in the Oracle wallet. Enter the passwords for both users when prompted.
```
RMAN> CONNECT TARGET sys as sysdba;
RMAN> CONNECT CATALOG ra_rman_user@ra1;
```

To connect to a protected database (CDB) and Recovery Appliance:

Start RMAN.
```
% rman
```
Use the CONNECT command to connect as TARGET to the root of the CDB and to the Recovery Appliance catalog as CATALOG.
Note:

Connecting to the Recovery Appliance as CATALOG when connected to a PDB as TARGET is not supported. When using the Recovery Appliance catalog, RMAN must connect as TARGET to the root of the CDB for backup and recovery operations.

The following command, run from the CDB, connects to the root as the common user c##bkuser user. my_cdb is the net service name of the CDB. ra_rman_user is the Recovery Appliance user that the protected database uses to authenticate with the Recovery Appliance. ra1 is the net service name of the target Recovery Appliance. Enter the passwords for both users when prompted.
```
RMAN> CONNECT TARGET c##bkuser@my_cdb;
RMAN> CONNECT CATALOG ra_rman_user@ra1;
```
See Also:

Oracle Database Backup and Recovery User's Guide for additional examples on connecting as TARGET to the root of a CDB

Importing Protected Database Metadata into the Recovery Appliance Catalog

To use Recovery Appliance for data protection of your protected databases, metadata for these protected databases must be stored in the Recovery Appliance catalog and not in an RMAN recovery catalog. Existing backup metadata that is currently stored in an RMAN recovery catalog can be imported into the Recovery Appliance catalog. It is recommended that you import your existing recovery catalogs into the Recovery Appliance catalog.

An RMAN recovery catalog can store metadata for one or more protected databases. While importing an RMAN recovery catalog into the Recovery Appliance catalog, you can import metadata related to only some databases or import all the metadata in the RMAN recovery catalog.

Note that importing your existing catalog to the Recovery Appliance catalog copies the backup metadata only. The existing backups themselves are not copied to the Recovery Appliance during catalog import. If required, you must separately copy existing backups as described in "Migrating Existing Backups to Recovery Appliance".

Steps to Import Protected Database Metadata Into Recovery Appliance

Complete the preparation steps described in "Preparing to Import an RMAN Recovery Catalog into Recovery Appliance".
Import the RMAN recovery catalog that stores metadata for the protected database that is being migrated to the Recovery Appliance as described in "Importing Protected Database Metadata Using the IMPORT CATALOG Command".

Preparing to Import an RMAN Recovery Catalog into Recovery Appliance

Before importing a protected database's metadata from an RMAN recovery catalog into the Recovery Appliance catalog, some actions must be performed both on the protected database and on the Recovery Appliance.

Perform the following steps on the Recovery Appliance:
1. Create a Recovery Appliance user that will be used by the protected database whose metadata is being migrated. The protected database authenticates with the Recovery Appliance using this Recovery Appliance user.
2. Create a protection policy that will be used by the protected database whose metadata is being migrated.
  
  You can also use an existing protection policy, if it meets the requirements for the protected database being migrated.
3. Enroll the protected database whose metadata is being migrated with the Recovery Appliance.
See Also:

Zero Data Loss Recovery Appliance Administrator's Guide for more information about performing these steps
Perform the following steps on the protected database:
1. If the source RMAN recovery catalog is not an contained in an Oracle 12c Release 1 database, then upgrade the recovery catalog database to Oracle 12c Release 1.
  
  See Also:
  
  Oracle Database Upgrade Guide for information about upgrading a database to Oracle Database 12c Release 1 (12.1).
2. Install the Recovery Appliance backup module that creates the shared library required to transfer backup data to the Recovery Appliance.
  
  Installing the backup module will create the Oracle wallet that contains credentials used to authenticate the protected database with the Recovery Appliance.
  
  See Also:
  
  "Installing the Recovery Appliance Backup Module"
3. Connect as TARGET to the protected database and as CATALOG to the RMAN recovery catalog that stores metadata for the protected database.
  
  The following example connects as TARGET to the protected database and as CATALOG to the source RMAN recovery catalog. The owner of the RMAN recovery catalog is rman_cat11 and dbrcat11 is the net service name of the RMAN recovery catalog database. Replace rmancat11_pswd with the password of the rman_cat11 user.
```
$ rman target / catalog rman_cat11/rmancat11_pswd@dbrcat11
```
4. Ensure that no backups from the protected database are being created to the RMAN recovery catalog.
  
  The following commands connect to SQL*Plus as the owner of the source RMAN recovery catalog and query for backups that are being created to the RMAN recovery catalog rman_cat11.
```
$ sqlplus rman_cat11/rmancat11_pswd@dbrcat11
SQL> SELECT username, module 
          FROM v$session
          WHERE username = 'RMAN_CAT11';
```
  This query should not return any results. Rows returned indicate a connection for what could be an ongoing backup or restore operation. If rows are returned, verify that there are no connections, then retry the query.
5. Determine the number of backup pieces contained in the catalog for the protected database.
  
  The following example lists the number of backup pieces for the protected database MY_PTDB:
```
SQL> SELECT db_name, COUNT(*)
          FROM rc_backup_piece_details
          WHERE db_name='MY_PTDB';
```
6. Exit SQL*Plus, and reconnect as TARGET to the protected database and as CATALOG to the source RMAN recovery catalog to verify that the backups in the recovery catalog are valid and can be used for a successful recovery operation.
```
$ rman target / catalog rman_cat11/rmancat11_pswd@dbrcat11
```
  You can either verify the backups by restoring them or by using the RESTORE ... VALIDATE command.
  
  See Also:
  
  Oracle Database Backup and Recovery Reference for details about using the RESTORE ... VALIDATE command
7. Connect to SQL*Plus as the owner of the source RMAN recovery catalog and run the dbmsrmansys.sql script. This script grants additional privileges that are required for the RECOVERY_CATALOG_OWNER role.
```
$ sqlplus rman_cat11/rmancat11_pswd@dbrcat11 
SQL> $ORACLE_HOME/rdbms/admin/dbmsrmansys.sql
SQL> exit
```
  The rman_cat11 user owns the RMAN recovery catalog and the net service name of the recovery catalog database is dbrcat11. Replace rmancat11_pswd with the password of the rman_cat11 user.
8. On the Recovery Appliance, start an RMAN session and connect to the Recovery Appliance as TARGET using the RASYS user and to the source RMAN recovery catalog as CATALOG.
  
  The following command connects as TARGET to the Recovery Appliance and as CATALOG to the source RMAN recovery catalog.
```
$ 	rman target rasys/rasys_pswd
RMAN> CONNECT CATALOG rman_cat11/rmancat11_pswd@dbrcat11
```
  RASYS is the owner of the Recovery Appliance catalog. Replace rasys_pswd with the password of the rasys user. The owner of the source RMAN recovery catalog is rman_cat11 and the service name of the recovery catalog database is dbrcat11. Replace rmancat11_pswd with the password of the rman_cat11 user.
9. Upgrade the source RMAN recovery catalog to Oracle Database 12c Release 1 (12.1.0.2). The UPGRADE CATALOG command needs to be entered twice for confirmation.
  - ```
  UPGRADE CATALOG;
  UPGRADE CATALOG;
```
10. Repeat Steps 2.d through 2.f on the upgraded source RMAN recovery catalog to verify that the upgraded catalog is fine and can be used to recover the protected database.

Importing Protected Database Metadata Using the IMPORT CATALOG Command

Use the RMAN IMPORT CATALOG command to import metadata from an RMAN recovery catalog into the Recovery Appliance catalog.

The version of the source RMAN recovery catalog schema must be equal to the current version of the Recovery Appliance recovery catalog schema (12.1.0.2). Upgrade the source recovery catalog schema to 12.1.0.2 if needed.

To import protected database metadata into the Recovery Appliance catalog:

Start RMAN and connect as CATALOG using the rasys user. Note that rasys is the owner of the Recovery Appliance catalog.
The following command (replace ra_pswd with the password of the rasys user) connects as CATALOG to the Recovery Appliance catalog. The Single Client Access Name (SCAN) of the Recovery Appliance is ra-scan and the service name of the Recovery Appliance metadata database is zdlra5. rasys is the Recovery Appliance catalog owner.
```
# 	rman CATALOG rasys/ra_pswd@ra-scan:1521/zdlra5
```
Import the source RMAN recovery catalog into the Recovery Appliance catalog. The credentials of the source RMAN recovery catalog are provided by the protected database administrator.
Use the NO UNREGISTER clause to specify that the protected database must not be unregistered from the source RMAN recovery catalog that it is currently using.

The following command imports all the metadata contained in the source RMAN recovery catalog that is owned by the user rman_cat11 (replace rmancat11_pswd with the password of the rman_cat11 user).
```
IMPORT CATALOG rman_cat11/rmancat11_pswd@dbrcat11 NO UNREGISTER;
```
The following command imports the metadata for the protected database with database name MY_PTDB contained in the source RMAN recovery catalog that is owned by the user rman_cat11 (replace rmancat11_pswd with the password of the rman_cat11 user).
```
IMPORT CATALOG rman_cat11/rmancat11_pswd@dbrcat11 
     DB_NAME 'MY_PTDB' NO UNREGISTER;
```
Verify that all the backup pieces are included in the Recovery Appliance catalog by querying the RC_BACKUP_PIECE_DETAILS view.

Compare the number of rows returned by the query in Step 2.e of "Preparing to Import an RMAN Recovery Catalog into Recovery Appliance" with the output of this step. The number of backup pieces returned by both queries must be the same.

See Also:

Oracle Database Backup and Recovery Reference for information about the IMPORT CATALOG command

Migrating Existing Backups to Recovery Appliance

Your existing backup strategy may store protected database backups in a local disk location or on a shared disk. After you import the metadata for the protected database backups into the Recovery Appliance catalog, you must migrate existing backups that are within the recovery window goals to the Recovery Appliance storage. You can migrate backups for only a subset of the protected databases contained in the imported RMAN recovery catalog. However, for all the databases represented in the imported catalog, you can begin using the Recovery Appliance catalog as your recovery catalog.

Note:

To begin using an incremental-forever backup strategy with Recovery Appliance, you must first submit a level 0 incremental backup. If a recent level 0 incremental backup already exists for a particular protected database, it might be more convenient to migrate that backup into the Recovery Appliance, rather than take another level 0 backup from the database. After migrating the level 0 backup and any required existing level 1 backups and archived log files, you can then begin the incremental-forever strategy by sending level 1 incremental backups and archived log files.

The recommended strategy is to migrate all existing backups and switch immediately to Recovery Appliance. Any backups created after you migrate existing backups must be stored on the Recovery Appliance.

Use one of the following techniques to migrate existing protected database backups that are stored on disk to the Recovery Appliance:

Configure a backup polling location where all the existing protected database backups can be placed. Next, set up the Recovery Appliance to poll this location and pick up the protected database backups.

See "Setting Up Backup Polling to Migrate Existing Backups to the Recovery Appliance".

If you have existing backups that are stored on tape, then use the steps described in "Making Tape Backups Available to Recovery Appliance".
Back up image copies that are stored on local disk storage as backup sets to the Recovery Appliance using the RMAN BACKUP AS BACKUPSET COPY OF DATABASE command. You must configure an SBT channel that corresponds to the Recovery Appliance backup module, as described in "Configuring RMAN SBT Channels for Recovery Appliance", before you run this command.

See Also:

"Importing Protected Database Metadata into the Recovery Appliance Catalog"
Oracle Database Backup and Recovery Reference for details about the syntax of the BACKUP AS BACKUPSET command

Setting Up Backup Polling to Migrate Existing Backups to the Recovery Appliance

This section describes how to migrate protected database backups that are currently stored in a polling location to the Recovery Appliance storage. A polling location is a file system directory on shared storage, outside the Recovery Appliance, that stores backup pieces and archived redo log files for a protected database. The Recovery Appliance polls this location at specified intervals, retrieves any new backups, and stores them on the Recovery Appliance.

To import existing backup sets by configuring a polling location:

On the Recovery Appliance, create a polling policy corresponding to the polling location that contains the protected database backups to be migrated.
The following example, when connected as the RASYS user to SQL*Plus, creates a polling policy called MIGRATION_LINUX that polls the location /polling/shared_backup_location for backups.
```
BEGIN
		    DBMS_RA.CREATE_POLLING_POLICY (
       polling_policy_name => 'MIGRATION_LINUX',
       polling_location => '/polling/shared_backup_location',
       polling_frequency => INTERVAL '1' MINUTE,
       delete_input => FALSE);
END;
```
On the Recovery Appliance, use the DBMS_RA.UPDATE_PROTECTION_POLICY procedure to assign the polling policy created in Step 1 to the protection policy that is associated with the protected database.

Set the delete_input parameter to False to indicate that the backups must not be deleted from the source location.

See Also:

Zero Data Loss Recovery Appliance Administrator's Guide
Mount the polling location directory on the Recovery Appliance database nodes as described in "Mounting the NFS Storage for Backup Polling".
Verify that the backup sets have been imported by querying the ra_task view.

You can also query the rc_backup_piece_details view to display the backup pieces for protected databases that are being polled.

Mounting the NFS Storage for Backup Polling

When you use backup polling, you must mount the Network File System (NFS) directory that stores backups for this protected database. Ensure that the path is accessible

Use the following steps to mount the polling location directory on the Recovery Appliance database nodes:

As the root, create the directory that will be used as the polling location.
```
# mkdir /polling_import
```
As root, mount the polling location using the following command:
```
# mount -o options nfs_server_name:nfs_directory_name directory
```
where options represent the NFS mount options, nfs_server_name is the host name of the NFS server, directory_name is the directory on the NFS server, and directory is the mount point directory.

The following example attaches the /backup/bkp_db_imp directory on the NFS server myNFShost at the directory polling_import:
```
# mount -o rw,hard,rsize=32768,wsize=32768,tcp,vers=3,timeo=600,actimeo=0 
     myNFShost:/backup/bkp_db_imp/source_bkp_dir /polling_import
```
Ensure that the oracle user has read permission for the mounted directory.

Making Tape Backups Available to Recovery Appliance

If your current tape backup strategy uses third-party media management software, you can make these tape backups available to the Recovery Appliance. Note that you need to import the metadata for these tape backups into the Recovery Appliance catalog.

To make tape backups available to Recovery Appliance:

Allocate an SBT channel that corresponds to the Recovery Appliance backup module.
Allocate an SBT channel that corresponds to the media management library that manages the existing tape backups.
Maintain both these SBT channels until the retention period or recycling period of the tapes is reached.

During this period, if required, the protected database can be recovered using the backups stored on tape.
After the retention period or recycling period of the tapes is reached, release the channel configured in Step 2.

Creating Local Backups

When you create protected database backups to local disk storage, metadata about these backups is stored in an RMAN recovery catalog. If an RMAN recovery catalog is not configured, or if you do not connect to the catalog, then the metadata is stored in the protected database control file.

To create local backups of the protected database:

Connect RMAN to the protected database as TARGET and connect to an RMAN recovery catalog as CATALOG.
The following command connects as TARGET to the protected database with service name hr_ptdb and as CATALOG to an RMAN recovery catalog database with net service name catdb. rco is the RMAN recovery catalog owner and hradm is a user with SYSBACKUP privileges on the protected database. Enter the password for the hradm and rco users when prompted.
```
% rman TARGET hradm@hr_ptdb CATALOG rco@catdb
```
Create local backups of the protected database.
Depending on your backup strategy, you can create full or incremental backups. Include archived redo log files in all backups to minimize the time required to recover from a failure. Allocate an RMAN channel of device type DISK to store backups to the local disk.

The following example allocates a disk channel and creates a level 1 incremental backup of the entire database including the archived redo log files:
```
RUN
{
   ALLOCATE CHANNEL d1 DEVICE TYPE DISK;
   BACKUP INCREMENTAL LEVEL 1
      DATABASE
      PLUS ARCHIVELOG;
}
```
Because no location is specified in the command, the backups are stored in the local fast recovery area that is configured for the protected database. To store backups on locally configured tape devices, allocate an SBT channel that corresponds to the legacy media management software.

Recovering Protected Databases Using Local Backups

When you create protected database backups to a local disk location, you can use regular RMAN commands to perform recovery. You need to configure one of the following before you restore and recover the protected database:

disk channels that corresponds to the disk location where the backups are stored
SBT channels that correspond to backups on legacy media management environments where the backups are stored

To perform complete recovery of a protected database using local disk backups:

Connect RMAN to the protected database as TARGET and connect to the RMAN recovery catalog as CATALOG.
The following command connects as TARGET to the protected database with net service name hr_ptdb and as CATALOG to an RMAN recovery catalog database with net service name rco. hradm is a user with SYSBACKUP privileges on the protected database and rco is the RMAN recovery catalog owner. Enter the passwords for the hradm and rco users when prompted.
```
% rman TARGET hradm@hr_ptdb CATALOG rco@catdb
```
Allocate an RMAN channel of device type DISK to use backups stored on local disk storage.
The following command allocates a disk channel that creates backups to the local disk storage.
```
RMAN> ALLOCATE CHANNEL d1 DEVICE TYPE DISK;
```
Restore and recover the protected database using the RESTORE and RECOVER commands respectively.
The following example performs complete recovery of the protected database:
```
RUN
{
   STARTUP MOUNT;
   ALLOCATE CHANNEL c1 DEVICE TYPE DISK;
   RESTORE DATABASE;
   RECOVER DATABASE;
   ALTER DATABASE OPEN;
}
```