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

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.

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 occurs in the following stages:

1. The protected database writes backups without the involvement of Recovery Appliance, which does not need to be running while backups are created.

2. Recovery Appliance polls for newly arrived backups.

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

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"

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.

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.

Because backups need space, you must estimate how much reserve 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.

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.

The ESTIMATE_SPACE procedure can assist with determining reserved space. When calculating reserved space for a compliance protection policy, the target_window should be the RECOVERY_WINDOW_COMPLIANCE plus an extra day for edge conditions.

A key question in storage management is whether it is more important to ensure that older backups are copied to tape or cloud 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 cloud 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 cloud. The Recovery Appliance can only hold up to disk_reserve_space bytes of backup data that is not yet copied to all libraries with the guaranteed_copy=YES.

  After the Recovery Appliance has consumed reserved space with backups that have not been copied to tape or cloud, 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. Non-virtual 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).

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.

The RECOVERY_WINDOW_COMPLIANCE parameter of DBMS_RA.CREATE_PROTECTION_POLICY specifies for each database using the policy a range of time that backups will not be deleted. These backups must not use more than disk_reserved_space bytes of storage, and if they do, new backups will be rejected until those backups age out of the range.

RECOVERY_WINDOW_COMPLIANCE is different and more restrictive than RECOVERY_WINDOW_GOAL, because the goal doesn't have to be met but the compliance does. The goal might be for the Recovery Appliance to recover a given database to any point in the last 30 days, if reserve storage is sufficient and not needed and overwritten by newer backups. Recovery window compliance might require the Recovery Appliance to recover a given database to any point in the past 7 days regardless of reserve storage constraints.

Because backups need space, you must estimate how much reserve space you believe is needed to store backups. The ESTIMATE_SPACE procedure can assist with determining reserved space. When calculating reserved space, the target_window should be the RECOVERY_WINDOW_COMPLIANCE plus an extra day for edge conditions.

Changes can be made to the protection policy to keep backups longer or shorter for new backups. However, once RECOVERY_WINDOW_COMPLIANCE is set for a given backup, it is strictly enforced and the backup is not deleted until the RECOVERY_WINDOW_COMPLIANCE period expires.

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. SET ENCRYPTION ON backups are supported for incremental forever when RMAN channels are allocated with PARMS=(RA_FORMAT=TRUE).

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.