1. Administrator's Guide
  2. Managing Recovery Appliance
  3. Managing Protection Policies with Recovery Appliance
  4. About Protection Policies
  5. Guidelines for Protection Policies

Guidelines for Protection Policies

Here are several considerations to create effective protection policies.

  • All databases in a protection policy must share the following:

    • Recovery Window Compliance (14 days / 30 days / etc.). This should be smaller than Recovery Window Goal. The Recovery Window Compliance may be null. If too large, this can result in the Recovery Appliance rejecting new backups, because old backups for compliance purposes have not "expired" yet and made their storage space available for re-use with incoming backups.

    • Recovery Window Goal (14 days / 30 days / etc.). This is a goal to strive for and helps determine amount of storage required. However, if the amount of free storage becomes too small, the oldest backups might have their storage space reclaimed for new backups. In such a case, the goal isn't met but continued operation and the receiving of incoming backups is not prevented. This is the difference from the recovery window compliance.

    • Max Disk Retention (default / 21 days / 35 days / etc.)

    • Tape Retention Policy (90 Days / 365 Days / 7 years)

    • Tape Operation Schedule (Sunday Full / Daily Incremental / Daily ARCH)

    • Replication Configuration (Replicate or No-Replicate, and which Recovery Appliances to replicate to)

  • If a production database needs to be replicated but a development database does not, this case requires two (2) protection policies.

    Similarly, if a production database needs to be replicated but another production database does not, this case also requires two (2) protection policies.

  • Geographical regions or different lines of business can mean additional protection policies. For example, the regions of North America and Europe might require two (2) protection policies.

  • Tape operations that occur on different days requires a protection policy for each day.

    For example, if due to volume, certain databases perform their weekly full backup on Sunday and others on Monday, this requires two (2) protection policies. If all databases perform their weekly full backup on Sunday, then only one (1) protection policy is needed.

  • If the number of days for tape retention is different between two databases, this requires two (2) protection policies.

A protection policy is a named, logical object recorded in the Recovery Appliance metadata database. To be added to a Recovery Appliance, a protected database must be associated with a specific protection policy. The default protection polices are Platinum, Gold, Silver, and Bronze.

Each protection policy specifies different values for the disk and tape recovery windows. These values apply to every database protected by the policy. For example, Figure 7-1 shows three of the default protection policies, with different protected databases assigned to each policy. In the example, databases prod3 and prod11 are in the same policy, and so both have the same disk recovery window goal of 3 days.

As an example of an update to a protection policy, the customer may choose to change the LOG_COMPRESSION_ALGORITHM setting in a protection policy for generally one or both of the below reasons:

  • Reduction of CPU utilization on the appliance attributed to creation and compression of archived log backups.

  • Reduction of CPU utilization on the protected database during recovery operations, attributed to decompression of archived log backups before the logs can be applied on the restored data files.

Although Oracle cannot provide detailed CPU utilization and compression ratio differences between the different algorithms, as they are highly data type dependent, generally:

  • LOW and MEDIUM settings utilize less CPU than BASIC and HIGH for performing compression/decompression, with trade-off of lower compression ratio (i.e. higher space usage on appliance).

  • MEDIUM offers the optimal balance of CPU consumption and compression ratio in most cases.

  • LOW offers the least CPU consumption, at the expense of a modest reduction in compression (higher space usage on appliance) ratio compared to MEDIUM and BASIC.

  • OFF disables the compression.

If a significant increase of space is noticed then the LOG_COMPRESSION_ALGORITHM can be changed back to BASIC.

The HIGH setting is not recommended due to significant CPU consumption.

Note:

For more details on log compression usage, see ZDLRA: Changes in the Protection Policy Compression Algorithms (Doc ID 2654539.1)

When a protection policy has SECURE_MODE set to YES, then backups that are not encrypted are rejected before they can be uploaded to the Recovery Appliance, by design. When redo logs are being shipped directly to the Recovery Appliance, they also must be encrypted. However, the check for redo encryption happens after the redo log completes, so future attempts to open a new log on the Recovery Appliance are rejected. A few logs might get started before the archived log destination status shows redo being rejected. This condition clears when an encrypted redo log backup is sent to the Recovery Appliance. After which, future redo log switch are accepted on the Recovery Appliance.