Recovery Appliance Architecture

The Recovery Appliance Environment

At minimum, the Recovery Appliance environment consists of one Recovery Appliance and one protected database. More typical is the sample environment shown in Figure 2-1.

Figure 2-1 Sample Recovery Appliance Environment

Description of "Figure 2-1 Sample Recovery Appliance Environment"

This section contains the following topics:

Main Components of the Recovery Appliance Environment

Figure 2-1 shows an example of a typical Recovery Appliance environment, which contains the following components:

Multiple protected databases

Each protected database sends backups and real-time redo to the Recovery Appliance. Protected databases can run on different releases of Oracle Database. For example, a mixed environment might include protected databases from Oracle Database 10g, Oracle Database 11g, and Oracle Database 12c.
Recovery Appliance

Figure 2-1 shows a central Recovery Appliance, which receives incremental backups and real-time redo from the protected databases. The Recovery Appliance contains the Recovery Appliance metadata database. This database includes the following components:
- The RMAN recovery catalog, which is subdivided into multiple virtual recovery catalogs.
- One or more storage locations. Recovery Appliance storage contains the delta store, which includes multiple delta pools.
Figure 2-1 also shows the central Recovery Appliance replicating backups to a second Recovery Appliance, which in turn forwards these backups to a third Recovery Appliance.
Oracle Enterprise Manager Cloud Control (Cloud Control)

Figure 2-1 shows Cloud Control running on a separate server in the environment. Administrators can use Cloud Control to manage all Recovery Appliances, protected databases, and tape devices in the Recovery Appliance environment.
DBMS_RA PL/SQL package

This is the command-line interface to Recovery Appliance. This package, which is stored in the Recovery Appliance metadata database, provides the underlying functionality for Cloud Control.
Oracle Secure Backup

Figure 2-1 shows the Recovery Appliance using Oracle Secure Backup to archive backups to a tape library. The diagram also shows a downstream Recovery Appliance archiving backups to a separate tape library.

See Also:

User Accounts in the Recovery Appliance Environment

The central components of a Recovery Appliance environment are the protected databases, Recovery Appliance, and Cloud Control. Table 2-1 summarizes the most important user accounts in the environment.

Table 2-1 User Accounts in the Recovery Appliance Environment

Component	Account Type	User Name	Description
Cloud Control	Cloud Control super-user	`SYSMAN`	This application account exists by default. Its purpose is to administer Cloud Control itself, and is not directly related to managing a Recovery Appliance or protected databases.
Cloud Control	Cloud Control administrator	User-Specified	A Cloud Control user account that has been granted the roles and privileges needed to manage a specific protected database or a specific Recovery Appliance. Multiple Cloud Control administrative accounts may exist, depending on your business requirements.
Recovery Appliance	Recovery Appliance metadata database super-user	`SYS`	`SYS` can create Recovery Appliance user accounts, but typically is not otherwise used for managing Recovery Appliance.
Recovery Appliance	Recovery Appliance administrator	`RASYS`	This database account owns the Recovery Appliance schema, which includes the RMAN recovery catalog and the `DBMS_RA` PL/SQL package (see DBMS_RA Package Reference). The `RASYS` user name is fixed and cannot be changed. `RASYS` does not have the privileges required to create database user accounts.
Recovery Appliance	Recovery Appliance user account	User-Specified	This account has authority to send and receive backups for databases registered with the Recovery Appliance, and to manipulate recovery catalog metadata for these databases. This is also the account to use to send redo data from a protected database to the Recovery Appliance. Unlike `RASYS`, a Recovery Appliance user account has no administrative capabilities in the Recovery Appliance. Typically, a Recovery Appliance metadata database contains multiple Recovery Appliance user accounts. These accounts are created when configuring access for protected databases (see Configuring Recovery Appliance for Protected Database Access). Every Recovery Appliance user account owns a virtual private catalog. The catalog owner can access and modify only those rows in the recovery catalog that pertain to the databases to which it has been granted access. The catalog user name for this is referenced in an RMAN `CONNECT CATALOG` command.
Protected Database	Protected database backup administrator	User account with `SYSBACKUP` privileges (or `SYSDBA` for releases in which `SYSBACKUP` is not supported)	This account has the privileges to back up, restore, and recover a protected database. This is the database user name that is referenced in an RMAN `CONNECT TARGET` command.

Figure 2-2 depicts the relationship between RASYS and two Recovery Appliance user accounts. In this example, each Recovery Appliance user account owns a separate virtual private catalog. Note that RASYS, as owner of the Recovery Appliance schema, is also the owner of the RMAN recovery catalog.

Figure 2-2 RASYS and Recovery Appliance User Accounts

Description of "Figure 2-2 RASYS and Recovery Appliance User Accounts"

See Also:

Oracle Database Security Guide to learn how to create database user accounts

Lifecycle of a Backup: Scenario

This section describes the lifecycle of a backup as it flows through the Recovery Appliance environment depicted in Figure 2-1. In this sample scenario, each protected database has already seeded Recovery Appliance with the required initial level 0 incremental backup. The basic data flow is as follows:

A protected database, or a standby database protecting this database, sends a level 1 incremental backup to the Recovery Appliance.

Recovery Appliance distinguishes itself from other backup solutions because only one level 0 backup is ever required for each data file. Level 1 incremental backups are most efficient because data blocks are only backed up when they change.

Oracle recommends making cumulative level 1 incremental backups (see Oracle Database Backup and Recovery Reference). Each cumulative level 1 backup uses the most recent virtual level 0 backup as its baseline. Typically, this virtual level 0 backup corresponds to the most recent level 1 backup.

Note:

If a level 1 cumulative backup cannot be incorporated into the Recovery Appliance (for example, because of a storage corruption), then the next level 1 backup has the same virtual level 0 backup baseline, enabling the Recovery Appliance to seamlessly incorporate the new level 1 incremental backup. Thus, cumulative backups almost never have greater overhead than differential backups.
The Recovery Appliance receives the incremental backup.

The received backup is available for immediate retrieval, but the Recovery Appliance has not yet indexed it, so the corresponding virtual full backups are not available. If a protected database requires this backup for recovery before the Recovery Appliance can index it, then RMAN automatically restores the previous virtual full backup and applies this incremental backup to it.
The Recovery Appliance processes the incremental backup.

The following operations occur asynchronously:
- The Recovery Appliance performs backup ingest. The Recovery Appliance processes the backup as follows:
  - Scans the backup that was sent by a protected database
  - Breaks it into smaller groups of blocks, assigning the blocks from each data file to a separate delta pool
  - Writes the groups into the appropriate storage location according to the protection policy for the database
  - Deletes the original backup set after the virtual backup set has been created
    
    Note:
    
    The Recovery Appliance may not delete the original backup at precisely the same time that the virtual backup is created. Thus, it is possible for both the original and virtual backups to coexist briefly in the recovery catalog as two separate copies.
  During backup ingest, the Recovery Appliance also indexes the backup, which involves storing information about the contents and physical location of each data block in the metadata database. Because the Recovery Appliance contains the recovery catalog for the protected database, the newly indexed virtual full backups are now available for use by RMAN, if needed for recovery.
- If Recovery Appliance replication is configured, then the Recovery Appliance forwards the backup to a downstream Recovery Appliance.
  
  Many different replication configurations are possible. Figure 2-1 shows a one-to-one configuration in which the central Recovery Appliance, acting as the upstream Recovery Appliance (backup sender), forwards its backups to a separate Recovery Appliance, acting as the downstream Recovery Appliance (backup receiver). Figure 2-1 shows cascaded replication, in which the downstream Recovery Appliance forwards its backups to a third Recovery Appliance.
- If automated copy-to-tape policies are enabled, then the Recovery Appliance archives the backup to tape.
  
  In Figure 2-1, the central Recovery Appliance uses Oracle Secure Backup software to communicate with a tape device. Also, the Recovery Appliance furthest downstream in the replication scheme archives its backups to tape. This technique has the following benefits:
  - To create redundancy, identical backups reside on two separate tape devices. In Figure 2-1, the primary Recovery Appliance archives to tape, as does the Recovery Appliance that is furthest downstream.
  - A downstream Recovery Appliance can back up to tape, thus offloading tape archival processing from the upstream Recovery Appliance.
- The Recovery Appliance periodically verifies that backups and redo are valid.
  
  The Recovery Appliance automatically validates backups on disk, and during inbound and outbound replication. The Recovery Appliance automatically performs crosschecks of tape backups. Just as with data file backups, the Recovery Appliance validates the integrity of redo log blocks during every operation, including receiving redo from protected databases and storing it in compressed archived log backup sets. No manually run RMAN VALIDATE commands are required.
- The Recovery Appliance performs automated delta pool space management.
  
  This phase involves deleting obsolete and expired backups, both on disk and tape, and optimizing the delta pools.

See Also:

"Recovery Appliance Storage Locations"
"Replicating Backups with Recovery Appliance"
"Automated Delta Pool Space Management"
Oracle Database Backup and Recovery User's Guide to learn how to make incremental backups

Protected Databases

A protected database uses a specific Recovery Appliance as a destination for centralized RMAN backup and recovery. In Figure 2-1, multiple protected databases send backups to a single centralized Recovery Appliance. Each database protected by a Recovery Appliance must use the recovery catalog in the Recovery Appliance metadata database.

To send backups to a Recovery Appliance, a protected database must be configured to allow access to the Recovery Appliance. The configuration involves creating the appropriate Recovery Appliance users and permissions, associating each protected database with a protection policy, and distributing Recovery Appliance connection credentials to each database.

This section contains the following topics:

Recovery Appliance Backup Modules

The Zero Data Loss Recovery Appliance Backup Module (Recovery Appliance Backup Module) is an Oracle-supplied SBT library that RMAN uses to transfer backup data over the network to the Recovery Appliance. An SBT library transfers data to and from a backup device type, either a tape device or Recovery Appliance. RMAN performs all backups to the Recovery Appliance, and all restores of complete backup sets, by means of this module.

The Recovery Appliance Backup Module must be installed in the following locations:

In the Oracle home of every protected database that sends backups to a Recovery Appliance

For example, a single host might have an Oracle Database 11g Oracle home, and an Oracle Database 12c Oracle home. Each Oracle home might support five protected databases, for a total of ten databases running on the host. In this case, only two Recovery Appliance Backup Modules must be installed: one in each Oracle home.
For Recovery Appliance replication environments, on every upstream Recovery Appliance that sends backups to downstream Recovery Appliances (see Replicating Backups with Recovery Appliance)

Figure 2-3 depicts an Oracle Database 11g and Oracle Database 12c protected database running on the same host. The Recovery Appliance Backup Module installed in each Oracle home communicates with the Recovery Appliance, replicates backups to a downstream Recovery Appliance.

Figure 2-3 Recovery Appliance Backup Modules

Description of "Figure 2-3 Recovery Appliance Backup Modules"

See Also:

Zero Data Loss Recovery Appliance Protected Database Configuration Guide to learn how to install the Recovery Appliance Backup Module
Oracle Database Backup and Recovery User's Guide to learn more about SBT channels and devices

Protection Policies

A protection policy is a named collection of properties that you can assign to multiple protected databases. Using a single policy for multiple databases reduces Recovery Appliance administration time, and enables you to change the properties of multiple protected databases with one operation. To accommodate databases with differing backup and recovery requirements, create as many protection policies as required.

A default installation of Recovery Appliance has the protection policies shown in Table 2-2.

Table 2-2 Default Protection Policies

Service Tier	Recovery Window	Additional Settings
Platinum	45 days on disk, 90 days on tape^Foot 1	Database backups, real-time redo transport, replication, and tape backups. All settings are mandatory.
Gold	35 days on disk, 90 days on tape	Database backups, real-time redo transport, replication, and tape backups (if tape is available).
Silver	10 days on disk, 45 days on tape	Database backups, real-time redo transport, and tape backups (if tape is available).
Bronze	3 days on disk, 30 days on tape	Database backups, and tape backups (if tape is available). There is no real-time redo transport.

^Footnote 1

Backups aged 45 days or less exist on both disk and tape, but backups aged more than 45 days exist only on tape. The Recovery Appliance creates tape backups immediately after disk backups, so the 90 day tape retention period begins at the same time as the 45 day disk retention period.

See Also:

Zero Data Loss Recovery Appliance Protected Database Configuration Guide to learn how to configure real-time redo transport
http://www.oracle.com/technetwork/database/availability/maa-reference-architectures-2244929.pdf to learn more about Oracle Maximum Availability Architecture (MAA) service tiers

Protection Policy Attributes

A protection policy, which you create with the DBMS_RA.CREATE_PROTECTION_POLICY procedure or with Cloud Control, sets the following attributes for all protected databases assigned to it:

Table 2-3 Protection Policy Attributes

Attribute	Description
`storage_location_name`	A Recovery Appliance storage location for storing backups
`polling_policy_name`	An optional backup polling policy that determines whether Recovery Appliance polls a storage location for backups
`recovery_window_goal`	The disk recovery window goal for the protected database.
`recovery_window_sbt`	The SBT retention period for the protected database
`guaranteed_copy`	The guaranteed copy setting, which determines whether backups protected by this policy must be copied to tape or replicated before being considered for deletion
`max_retention_policy`	The maximum length of time that the Recovery Appliance retains backups for databases that use this retention policy
`unprotected_window`	The maximum acceptable difference between the current time and the latest time that the database can be restored

You can associate an optional replication server configuration with a protection policy. The replication configuration applies to all protected databases associated with the protection policy.

See Also:

Recovery Windows

When creating a protection policy, you can define the following two recovery window attributes, expressed as intervals (typically days):

Disk recovery window goal

For each database assigned to the policy, Recovery Appliance attempts to support a point-in-time recovery to any time within this interval, counting backward from the current time. For example, if the recovery window goal is 15 days, and if it is noon on April 25, then the goal is the ability to perform point-in-time recovery to any time on or after noon on April 10. At noon on April 26, the goal is the ability to perform point-in-time recovery to any time on or after noon on April 11, and so on.

For disk, this interval is a goal, and not a guarantee. The Recovery Appliance might purge backups when disk space is low, in which case the goal is not always met. You can ensure that a minimum number of backups are guaranteed to be available by adjusting the reserved disk space property of each protected database.
SBT retention period

For each assigned database, backups are retained long enough on tape to support a point-in-time recovery to any time within this interval, counting backward from the current time. For SBT, this interval is a guarantee.

See Also:

"Recovery Window Goal"
""Backup Retention on Tape""
Zero Data Loss Recovery Appliance Protected Database Configuration Guide
Oracle Database Backup and Recovery User's Guide for a thorough discussion of recovery windows

Backup Polling Policies

A backup polling policy specifies:

A file system directory on shared storage where Recovery Appliance polls for backups to process (see "Backup Polling Locations")
The frequency with which Recovery Appliance polls
Whether backup data is to be deleted after being successfully processed

Assign backup polling policies to protected databases through protection policies. Each protection policy can optionally reference a polling policy.

Supported Oracle Database Releases

See My Oracle Support Note Doc ID 1995866.1 (http://support.oracle.com/epmos/faces/DocumentDisplay?id=1995866.1) for information about the Oracle database releases supported by Recovery Appliance, including the features available with each release.

Real-Time Redo Transport

Redo data contains records of all changes made to a database and is therefore critical to minimizing data loss if data failure occurs. By using the real-time redo transport feature of Recovery Appliance, you substantially reduce the window of potential data loss that exists between successive archived redo log backups. Typical RPO is zero to subsecond when you enable real-time redo transport.

Figure 2-4 shows a protected database sending incremental backups and redo logs to the Recovery Appliance.

Figure 2-4 Redo Log Transmission

Description of "Figure 2-4 Redo Log Transmission"

With real-time redo transport enabled, a protected database generates redo changes in memory, and then immediately transfers them to the Recovery Appliance, which validates them and writes them to a staging area.

When the protected database performs an online redo log switch, the Recovery Appliance converts and assembles the redo changes into compressed archived redo log file backups. The Recovery Appliance catalog automatically tracks these archived redo log backups in its recovery catalog. RMAN can restore and apply these archived redo log backups as usual. The advantages are:

If the redo stream terminates unexpectedly, then the Recovery Appliance can close the incoming redo stream and create a partial archived redo log file backup, thereby protecting transactions up to the last change that the appliance received. When the Recovery Appliance detects that the redo stream has restarted, it automatically retrieves all missing archived redo log files from the protected database. In this way, the Recovery Appliance can preserve the recovery window goal.
Because the Recovery Appliance automatically converts real-time redo into archived redo log files, it is not necessary to back up archived redo log files from the database host to the Recovery Appliance.

The Recovery Appliance does not apply the redo that it receives to the backups sent by the protected databases. Thus, to continue providing updated virtual level 0 backups, the Recovery Appliance must incorporate new incremental backups into the delta store. The appliance provides a virtual level 0 backup corresponding to each level 1 incremental backup sent by the protected database. In a recovery scenario, you restore the appropriate level 0 backup, and then use redo log files to roll it forward.

See Also:

Zero Data Loss Recovery Appliance Protected Database Configuration Guide to learn more about real-time redo transport and how to enable it

Recovery Appliance Metadata Database

The key component of the Recovery Appliance is the Recovery Appliance metadata database. This database manages metadata for all backups, and also contains the RMAN recovery catalog. The Recovery Appliance metadata database is preconfigured, pretuned, and managed by the Recovery Appliance. Figure 2-5 depicts a Recovery Appliance metadata database interacting with a protected database.

Figure 2-5 Recovery Appliance Metadata Database

Description of "Figure 2-5 Recovery Appliance Metadata Database"

This section contains the following topics:

Delta Store

The delta store is the totality of all protected database backup data in Recovery Appliance storage location. All data file and archived redo log backups reside in the delta store. The delta store contains delta pools for all data files in all protected databases.

Delta Pools

The delta store is the collection of delta pools. As the Recovery Appliance receives backups from protected databases, it indexes them and stores them in delta pools. A delta pool is the set of data file blocks from which Recovery Appliance constructs virtual full backups. Recovery Appliance automatically manages delta pools so that it can create a virtual full backup that corresponds to any incremental backup ever received.

Each separate data file whose backups are sent to Recovery Appliance has its own separate delta pool. For example, data file 10 from prod1 has its own delta pool, data file 1 from database prod2 has its own delta pool, and so on. As shown in Figure 2-6, the delta store contains all the delta pools for the databases protected by Recovery Appliance.

Figure 2-6 Delta Pools in Delta Store

Description of "Figure 2-6 Delta Pools in Delta Store"

Automated Delta Pool Space Management

The set of operations by which Recovery Appliance manages backups is called automated delta pool space management. Specifically, space management involves the following automated tasks:

Deleting backups (both in a Recovery Appliance storage location and on tape) that are obsolete or expired based on the disk recovery window goal and SBT retention policy

Recovery Appliance periodically determines that some backups no longer need to be stored on disk, so their disk space can be reclaimed. When the Recovery Appliance determines that some backups residing in the delta pools are obsolete, the individual blocks that compose those backups are typically located in physical files alongside non-obsolete blocks. Recovery Appliance rewrites these physical files so that the delta pools can reclaim the space occupied by the obsolete blocks.
Reorganizing the delta pools periodically to improve performance of restore operations

The automatic tracking and reorganizing of the delta pools is called delta pool optimization. As old blocks are deleted and new incremental backups arrive for updated data files, the blocks in a backup can become less contiguous. This state can degrade the performance of restore operations. Recovery Appliance runs a background task that automatically reorganizes virtual full backup blocks to maintain contiguity, thus optimizing read access for restore operations.

Recovery Appliance Schema

The Recovery Appliance schema contains metadata used internally by the Recovery Appliance to manage backups on behalf of its protected databases. RASYS is the Recovery Appliance administrative user who owns the Recovery Appliance schema. The Recovery Appliance schema contains the RMAN recovery catalog.

Recovery Appliance Catalog

Updates to the recovery catalog reflect the results of Recovery Appliance indexing and space management collection. These updates do not occur in the control files of the protected databases. For this reason, protected databases that store backups in the Recovery Appliance must use the Recovery Appliance catalog.

Note:

Protected databases may use the recovery catalog in the Recovery Appliance without also using the Recovery Appliance as their backup repository.

RMAN connects to the Recovery Appliance catalog using the same Recovery Appliance account employed for backup and recovery operations. Each Recovery Appliance user account is also a virtual private catalog account. The DBMS_RA.GRANT_DB_ACCESS procedure grants Recovery Appliance privileges to a database user account for a specified protected database.

See Also:

"Granting Database Access to a Recovery Appliance Account Using DBMS_RA"
"GRANT_DB_ACCESS"
Oracle Database Backup and Recovery User's Guide to learn how to manage a recovery catalog

Recovery Appliance Storage

Recovery Appliance uses the following types of storage:

Recovery Appliance storage location

This Oracle ASM location is the main storage for backups on Recovery Appliance disks, serving as the destination for protected database backups.
Backup polling location

An optional file system directory on shared storage, outside the Recovery Appliance, that is a destination for backup pieces and archived redo log files from a protected database. Recovery Appliance polls the directory at specified intervals, retrieves any found backups, and then processes and stores them.

See Also:

"Recovery Appliance Storage Locations"
"Backup Polling Locations"
Zero Data Loss Recovery Appliance Protected Database Configuration Guide to learn how to configure real-time redo transport

Recovery Appliance Storage Locations

A Recovery Appliance storage location can be shared among multiple protected databases. The Recovery Appliance administrator decides which clients will use each storage location.

Benefits of Recovery Appliance Storage

The benefits of Recovery Appliance storage locations are:

More efficient disk usage

Recovery Appliance uses common storage to absorb spikes from all protected databases, reducing the total amount of over-allocated storage. In traditional RMAN backup and recovery, a fast recovery area stores recovery-related files. Individual fast recovery areas require that each database maintain the amount of storage required to accommodate its largest expected activity spike, which often results in wasted storage.

Note:

The default storage location in the Recovery Appliance also contains a fast recovery area for catalog backups.

Oracle recommends that protected databases continue to maintain fast recovery areas for storage of local online and archived redo log files, control file autobackups, and flashback logs. In a Recovery Appliance environment, the fast recovery areas have smaller space requirements because RMAN backups are stored in the Recovery Appliance.
Database-optimized backup deduplication and compression
Shared disk backup pool distributed based on database protection policy, which defines the disk recovery window goal for each database protected by the policy

Oracle ASM and Recovery Appliance Storage

Recovery Appliance storage locations occupy space in Oracle ASM disk groups. By default, the delta pool is stored in normal redundancy Oracle ASM disk groups, which means that the Recovery Appliance maintains two copies of all on-disk backups. Database backups can survive the loss of any one disk or storage server. The Recovery Appliance metadata database, which tracks the files and blocks, is stored in a high redundancy Oracle ASM disk group.

See Also:

DELTA Storage Location

By default, Recovery Appliance is configured with all available disk storage assigned to a single storage location called DELTA. As shown in Figure 2-7, all protected databases share this storage location.

Figure 2-7 DELTA Storage Location

Description of "Figure 2-7 DELTA Storage Location"

Backup Polling Locations

A backup polling policy defines a file system directory where a protected database places backups without interacting directly with Recovery Appliance. The backup polling directory is an NFS mount point, and is not in a Recovery Appliance storage server.

The polling policy defines the file system path to the storage and how often it will be searched for new backups. Polling policies are optional and do not need to be created if backups are not sent to Recovery Appliance using the polling method.

See Also:

"Backup Polling Policies"

Stages of Backup Polling

Backup polling occurs in the following stages:

The protected database writes backups without the involvement of Recovery Appliance, which does not need to be running while backups are created.
Recovery Appliance polls for newly arrived backups.
When Recovery Appliance discovers a file through polling, the Recovery Appliance examines its contents and tries to associate it with a protected database, and then does either of the following:
- If the file is associated with a registered protected database, then Recovery Appliance processes the backup.
- If the file is not associated with any registered protected database, then Recovery Appliance logs a warning message and does not process the file.

How Recovery Appliance Processes Backups in Backup Polling Directories

To set up polling so that backups are copied to Recovery Appliance storage, you must configure a backup polling directory that exists outside Recovery Appliance storage locations, but which the Recovery Appliance can access. The protected database writes its backups to the polling directory, which you specify in the polling policy.

The Recovery Appliance checks the polling directory for newly created backups. When backups exist, the Recovery Appliance copies the backups from the polling directory to its internal Recovery Appliance storage location, and then processes them. After enough time has passed for Recovery Appliance to copy the backups, the protected database deletes the backups from the polling directory. Figure 2-8 depicts this configuration.

Figure 2-8 Backup Polling

Description of "Figure 2-8 Backup Polling"

How Recovery Appliance Manages Storage Space

An important duty of the Recovery Appliance administrator is planning for the proper amount of disk space for a specified retention window and database size. As conditions change, the Recovery Appliance provides space management monitoring and alerting at the storage location and database level. When estimated storage needs are approaching the amount of available storage, alerts and warnings give the administrator time to accommodate the storage demands.

The following attributes, whose settings are accessible through the RA_DATABASE view, determine how Recovery Appliance manages storage space and backup retention:

See Also:

"Archival and Encrypted Backups" for special algorithms that apply to RMAN backups that are not part of the incremental-forever strategy

Recovery Window Goal

The recovery_window_goal parameter of DBMS_RA.CREATE_PROTECTION_POLICY specifies the interval (typically in days) within which point-in-time recovery must be possible, counting backward from the current time. Consider a recovery_window_goal setting of 1 day. At midnight on August 7, the goal is recoverability to any time between the current time and midnight on August 6. At midnight on August 8, the goal is recoverability to any time between the current time and midnight on August 7, and so on.

Recovery Appliance attempts to retain sufficient backups to meet the recovery window goal defined for each database. For example, a Recovery Appliance protects databases STORE01, STORE02, and STORE03. The recovery window goal for STORE01 is 1 day. If at midnight on August 7, STORE01 needs 624.2 GB for backups to meet its recovery window goal, then the Recovery Appliance attempts to ensure that at least this much space is allocated for STORE01 backups.

If sufficient space exists in storage, then backups created before a recovery window goal may be available—although they are not guaranteed. If purging previous backups is not necessary, then the Recovery Appliance keeps them, effectively extending the time to which point-in-time recovery is available. For example, on August 7 the space available to STORE01 might be 700 GB or more, even though only 624.2 GB is required. A similar situation may exist for STORE02 and STORE03.

If sufficient space does not exist in storage, then by default (guaranteed_copy=NO) the Recovery Appliance may purge backups. When reclaiming space, the Recovery Appliance attempts to respect the recovery window requirement first.

See Also:

Reserved Space

Next in importance to the recovery window goal is the reserved_space parameter of DBMS_RA.ADD_DB and DBMS_RA.UPDATE_DB. The reserved space defines the amount of disk space guaranteed to each protected database to meet its recovery window goal.

Note:

This is the only storage parameter that is specified in ADD_DB rather than in the protection policy.

Because backups need space, you must estimate how much space you believe is needed to store backups. For example, you might allocate 1024 GB of reserved space to the DB1124 database, which means the Recovery Appliance guarantees 1024 GB to DB1124 if the database needs this amount to meet its recovery window goal. The following graphic shows a section of a Protected Database Details report:

Description of the illustration pdb_details.png

In the preceding example, the disk recovery window goal for DB1124 is 3 days, and the actual recovery window (the time to which the Recovery Appliance can currently recover) is 4.59 days. Meeting the recovery window goal requires 182.3 GB of backup data. This amount is less than 20% of the specified reserved space setting of 1024 GB. By default, at any given time, a database may actually have more or less than its specified reserved space available.

Note:

Reserved space is measured in space (GB), whereas the recovery window goal is measured in time.

The Recovery Appliance uses recovery window goals and reserved space settings to allocate storage dynamically to meet business requirements. If the Recovery Appliance has purged as much backup data as possible while still meeting the recovery window goal for each database, and if more space is needed, then the Recovery Appliance evaluates the reserved space setting of each database. Recovery Appliance purges backups for the database whose backups exceed the reserved space by the highest percentage, and logs a message in the RA_INCIDENT_LOG view. Query the RA_PURGING_QUEUE view to determine which database will next have a backup purged.

See Also:

Guaranteed Copy

A key question in storage management is whether it is more important to ensure that older backups are copied or replicated than it is to accept new backups or redo. The following settings are possible for the guaranteed_copy parameter of DBMS_RA.CREATE_PROTECTION_POLICY:

NO (default)

Recovery Appliance can purge backups before they have been copied to tape or replicated when it is necessary to make space for newer backups. In this case, the protected database may have more or less than the reserved space.
YES

When guaranteed copy is enabled, Recovery Appliance never purges a backup before it has been copied to tape or replicated. Also, the Recovery Appliance never permits the total size of backups that have not been copied or replicated to exceed the reserved_space setting for a database.

After the Recovery Appliance has consumed reserved space with backups that have not been copied to tape or replicated, the Recovery Appliance cannot accept new backups or redo. This setting only changes the behavior of storage management when the tape system or replicated Recovery Appliance is unavailable for an extended period.

The Recovery Appliance uses a different algorithm for virtual backups that are part of an incremental-forever backup strategy. Nonvirtual backups occupy a specific amount of space and either have or do not have a tape copy. For virtual backups, the tape schedule may write either a level 1 or level 0 version of any virtual backup in the Recovery Appliance. Additionally, space computations for virtual backups are complex because the space includes blocks needed to support the backup, which may differ from the space needed to write the backup to tape. For these reasons, after the Recovery Appliance writes a virtual data file backup to tape, the Recovery Appliance considers all versions of this backup and any older virtual backups of this data file as copied to tape (or replicated).

See Also:

Maximum Retention Window

The max_retention_window parameter of DBMS_RA.CREATE_PROTECTION_POLICY specifies the maximum time that the Recovery Appliance retains backups for databases using this policy. Specifying null means that no backup purging occurs unless caused by space pressures within a storage location, or user actions.

The Recovery Appliance only keeps backups longer than the retention window when necessary to preserve the recovery window goal for a database. The effect of this setting is that the Recovery Appliance deletes backups sooner than it might otherwise have chosen to delete them.

See Also:

Archival and Encrypted Backups

The following types of backups cannot be part of an incremental-forever strategy, or be used to construct virtual full backups:

RMAN archival backups created using the BACKUP ... KEEP command
RMAN encrypted backups created using CONFIGURE or SET ENCRYPTION

The Recovery Appliance manages the preceding backups differently from backups in an incremental-forever strategy. Recovery Appliance retains archival backups regardless of the specified recovery window goal. However, encrypted backups do adhere to recovery window settings.

Archival backups are eligible for deletion by the Recovery Appliance only after the KEEP time expires. If you intend to store archival backups for an extended time, then note the following guidelines:

Adjust the reserved space to account for them. Archival backups reduce the space available for achieving your recovery window goal and must be accounted for.
Because the Recovery Appliance does not automatically copy archival backups to tape, you must manually copy them using the COPY_BACKUP procedure. This procedure also enables you to copy archival backups to disk locations that are outside Recovery Appliance storage locations. The MOVE_BACKUP procedure copies an archival backup to disk or tape and then deletes it from the storage area.

See Also:

"Copying Backups to Tape with Recovery Appliance"
"Data Encryption Techniques"
Oracle Database Backup and Recovery User's Guide to learn more about archival backups
My Oracle Support Note Doc ID 2107079.1 (http://support.oracle.com/epmos/faces/DocumentDisplay?id=2107079.1) to learn how to create archival backups for long term retention on the Recovery Appliance

Oracle Secure Backup

Oracle Secure Backup is the tape management component of Recovery Appliance. The Recovery Appliance offloads tape backup operations from protected databases to the Recovery Appliance. Thus, protected database hosts do not need the RMAN-integrated media management software module. Instead, a single copy of the Oracle Secure Backup module is installed on Recovery Appliance. The Recovery Appliance automatically manages the copy of backups to tape for all protected databases.

See Also:

Oracle® Database Backup and Recovery Reference.

Tape Archival

Protected databases send backups to the Recovery Appliance, which stores them on disk in the specified storage locations. To reclaim disk space and to create transportable tape backups, business requirements may necessitate archival to tape.

Tape backups are a repetitive task that the Recovery Appliance automates and performs as a background task. The Recovery Appliance administrator configures rules that specify the frequency with which the Recovery Appliance creates tape backups. Because the protection policy is a natural grouping of databases, databases sharing the same protection policy can share the same tape archival requirements.

Recovery Appliance creates tape backups in the compatibility version that matches the greatest compatibility version of any full or incremental backup that contributes blocks to the backup. The database identity information that the Recovery Appliance sends to the media management layer is identical to the information that would be sent if the database were sending the backup. This consistency guarantees that the database for which the backups were created can use them.

Tape Retrieval

Backups are stored on tape as complete backup sets, not virtual backups, so tape backups are usable by RMAN without mediation by the Recovery Appliance. You can restore backups from tape in the following ways:

Retrieval by Recovery Appliance

This is the simplest way to restore an SBT backup created by Recovery Appliance. RMAN requests the restore from Recovery Appliance, without needing to be aware that this particular backup has been moved to tape. Recovery Appliance recognizes that the requested backup set is located on tape, open an SBT session to restore the backup from the media manager, and transfer the data over the network to the protected database host.
Retrieval by protected database

Because the SBT backups exist in a client-compatible format, RMAN can restore the backups from tape directly to any host, without involving Recovery Appliance. In this case, RMAN must first catalog the backup pieces before it can restore them from tape, and the Oracle Secure Backup library must be installed on the protected database host.

See Also:

Oracle Database Backup and Recovery User's Guide to learn how to restore backups from tape

Recovery Appliance Replication

In Recovery Appliance replication, one Recovery Appliance (the upstream Recovery Appliance) forwards backups to another Recovery Appliance (the downstream Recovery Appliance). After initial configuration, replication is fully automatic. Each Recovery Appliance in a replication topology manages its own protection and polling policies.

How a Downstream Recovery Appliance Processes Backups

To forward backups to a downstream Recovery Appliance, the upstream Recovery Appliance uses the same Recovery Appliance Backup Module that a protected database uses to send backups. The basic steps for processing backups are as follows:

A protected database uses its Recovery Appliance Backup Module to send backups to the Recovery Appliance.
The Recovery Appliance receives the backups and processes them as normal.
The upstream Recovery Appliance forwards the backups to the downstream Recovery Appliance.

Note:

The downstream Recovery Appliance does not know that it serves in the downstream role. The logic for receiving and processing backups on the downstream Recovery Appliance is independent of what occurs on the upstream Recovery Appliance.

Note:

When real-time redo transport is enabled, incoming redo changes are not replicated in real time by Recovery Appliance. When an archived redo log backup is created, the Recovery Appliance automatically replicates this backup along with the data file backups.
As it receives backups from the upstream Recovery Appliance, the downstream Recovery Appliance updates its own metadata database.
The upstream Recovery Appliance requests metadata updates from the downstream metadata.

Periodically, the upstream Recovery Appliance requests metadata updates from the Recovery Appliances directly downstream from it. On receiving a metadata request, the downstream Recovery Appliance sends metadata updates to the upstream Recovery Appliance, which updates its own recovery catalog. In Recovery Appliance replication, this process is known as reconciling.

See Also:

"Lifecycle of a Backup: Scenario"

Replication Use Cases

Because a downstream Recovery Appliance processes backups independently from the upstream Recovery Appliance, a downstream Recovery Appliance can have completely different policies for every database whose backups it is storing. This design allows for a wide variety of use cases to be configured. In general, the use case for replication is to preserve database backup and recovery operations in the event of an outage or loss of the local recovery appliance. The replication topologies described below illustrate how this can be achieved.

One-Way

Backup data from local protected database (DB-a) flows to an upstream Recovery Appliance (RA-x), which forwards it to a downstream Recovery Appliance (RA-y).

Description of the illustration rep_oneway.png
Bi-Directional

Backup data from local protected databases (DB-a) flow to a local Recovery Appliance (RA-x), which then forwards them to a remote Recovery Appliance (RA-y). Conversely, backup data from remote database (DB-d) flow to a RA-y, which then forwards them to RA-x.

Bi-directional replication is essentially one-way replication from RA-x to RA-y for a certain set of protected databases (DB-a,DB-b, DB-c), and also one-way replication the other direction from RA-y to RA-x for a different set of protected databases (DB-d, DB-e, DB-f).

Description of the illustration rep_bidirectional.png
In this case, each Recovery Appliance plays both the upstream and downstream roles in the replication topology. Every Recovery Appliance serves as the primary backup location for one set of protected databases, and the secondary backup location for the other set. In this way, every Recovery Appliance is actively utilized while also providing disaster recovery services for the other Recovery Appliance.
Hub-and-Spoke

Backups flow from one set of databases to a local Recovery Appliance, and from a different set of databases to a different local Recovery Appliances. The local Recovery Appliances then forward these backups to a single remote Recovery Appliance, which archives the backups to tape.

Description of the illustration rep_hubspoke.png
Backup Anywhere

Two Recovery Appliances RA-x and RA-y replicate between each other, and are the upstream and downstream of each other. Backups from databases DB-a and DB-b flow to their upstream Recovery Appliance, respectively RA-x and RA-y. Then RA-x and RA-y replicate these backups to their downstream Recovery Appliance, respectively RA-y and RA-x. Backups from databases DB-a and DB-b can be sent to either RA-x or RA-y with replication occurring to the Recovery Appliance which did not receive the backups directly from the DB.

Description of the illustration rep_backupanywhere.png
Read-Only Replication

The read_only replication mode is useful when changing the destination Recovery Appliance for database backups from the original RA-x to a different RA-y while RA-x remains available to RA-y. This eliminates the need to replicate the old backups from RA-x to RA-y, which is time consuming and network intensive. If the original RA-x is available to RA-y, a replication server configuration in read_only mode can be added to the protection policy on RA-y which designates RA-x as the downstream. All backups for the databases in the policy that exist on the downstream are retrievable when and if needed by the upstream. After the old backups on the original RA-x have expired according to the protection policy, RA-y no longer needs the backups on RA-x which allows RA-x to be removed from the replication topology.

Description of the illustration rep_readonly.png
A key use case for read_only replication is for introducing new Recovery Appliances into a replication configuration, so that the original Recovery Appliances can be decommissioned or so that protected database workload can be scaled out across additional Recovery Appliances. This allows for the graceful transfer of backup / restore between Recovery Appliances without unnecessary transmission and duplication of old backup files.
Request Mode Replication

In request_only mode replication, the upstream (RA-x) Recovery Appliance receives the primary database backups while the downstream (RA-y) receives the standby database backups, redo logs, and archive logs. When the upstream RA-x is offline for planned maintenance as one example, the primary database redo and archive logs are redirected to the downstream RA-y, where new virtual full and archived log backups are created in order to preserve database recoverability. Redo and archived logs are the more critical data to retrieve from the upstream databases, because the database can hang if the local archived log director fills up. Therefore, they are transmitted to RA-y so that they can be safely deleted by RMAN on DB-a.

RA-y is not affected by RA-x outage and still receives level 1 backups from standby database as normal. Standby backups on RA-y can be used for primary database restores. When RA-x comes back online, all previously redirected backups are replicated from the downstream RA-y to the upstream RA-x to re-establish its full recoverability of its databases.

Description of the illustration rep_request.png
Cascade Mode Replication

Any of the preceding use cases could be adapted for cascaded replication, in which an upstream Recovery Appliance replicates to a downstream Recovery Appliance, which in turn replicates to another Recovery Appliance, creating a one-way chain of Recovery Appliances.

Description of the illustration rep_cascade.png

Data Encryption Techniques

Various encryption options are available for backups and redo sent to the Recovery Appliance, as shown in Figure 2-9. The Recovery Appliance does not provide server-side encryption, which means that the appliance does not itself encrypt and decrypt data.

Figure 2-9 Data Encryption Techniques

Description of "Figure 2-9 Data Encryption Techniques"

The following types of encryption are supported:

Transparent Data Encryption (TDE) on Production Database Tablespaces

Oracle recommends that you enable TDE on tablespaces in the database, and then take incremental backups as usual. TDE requires the Advanced Security Option. The benefits of TDE are as follows:

TDE is transparent to applications.
Backups of encrypted tablespaces, and redo describing changes to these tablespaces, are encrypted. The TDE-encrypted data blocks are secured on the protected database, Recovery Appliance storage, tape devices, and replicated appliances, and also when transferred through any network connections.
TDE on the source database reduces overhead on downstream servers.
This technique supports an incremental-forever strategy and virtual full backups.

Note:

Oracle does not recommend encrypting backups using the RMAN SET or CONFIGURE ENCRYPTION command. See "Archival and Encrypted Backups" for more information

The following table shows the support for incremental forever when RMAN encryption and/or RMAN compression are used for the protected database backups:

Table 2-4 Support for Incremental Forever with RMAN Encryption and RMAN Compression

Data in the Database	No RMAN Encryption and No RMAN Compression	RMAN Encryption	RMAN Compression	RMAN Encryption and RMAN Compression
Not Encrypted	Yes	No	Yes	No
TDE Tablespace Encryption	Yes	Yes	No	No

See Also:

Oracle Database Advanced Security Guide to learn about TDE
Oracle Database Backup and Recovery User’s Guide to learn about configuring backup encryption
Oracle Database Backup and Recovery User’s Guide to learn about making compressed backups

Redo Encryption Using LOG_ARCHIVE_DEST_n

When enabled, the ENCRYPTION attribute of LOG_ARCHIVE_DEST_n encrypts redo both at rest on the Recovery Appliance and during the network transfer to the appliance. The basic process is as follows:

The protected database encrypts the redo in memory, using the private key contained in the Oracle Wallet on the protected database.
The protected database transfers the redo to the Recovery Appliance over the network.

Note:

If Oracle Net security is also enabled, then the redo is double encrypted during network transfer.
The Recovery Appliance writes the encrypted redo to archived redo log files, which exist in encrypted form only on the Recovery Appliance.

In a recovery scenario, RMAN restores and decrypts the encrypted redo log files on the protected database, using the encryption key stored in the Oracle wallet on the protected database host (not on the Recovery Appliance). RMAN never applies encrypted redo log files during media recovery.

See Also:

My Oracle Support Note Doc ID 1995866.1 (http://support.oracle.com/epmos/faces/DocumentDisplay?id=1995866.1) for versions of Oracle Database that support encrypted redo
Oracle Data Guard Concepts and Administration to learn about redo encryption using LOG_ARCHIVE_DEST_n

Tape Drive-Based Hardware Encryption

The Recovery Appliance supports tape drive-based hardware encryption. In this case, the tape drive encrypts the data, not the software.

Note:

Oracle Secure Backup can encrypt backup pieces before Recovery Appliance copies them to tape. However, Oracle does not recommend software-based encryption because of its possible negative effect on performance.

For key management, Oracle recommends Oracle Key Manager, which centrally authorizes, secures, and manages all encryption keys. Oracle Key Manager does not consume CPU on the Recovery Appliance when encrypting and decrypting data.

See Also:

Oracle Secure Backup Administrator's Guide to learn about hardware encryption