Managing Protection Policies with Recovery Appliance

8 Managing Protection Policies with Recovery Appliance

This chapter explains how to manage protection policies and polling policies, which are part of "Setup and Configuration for Recovery Appliance".

This chapter contains the following topics:

About Protection Policies

A protection policy is the central mechanism for controlling management of backup storage space, based on pre-defined recovery window goals. From the perspective of a DBA, the most important elements of a protection policy are the disk and tape recovery windows.

This section contains the following topics:

See Also:

"Protection Policies" for an architectural overview

Purpose of Protection Policies

For every database associated with it, a protection policy specifies:

The recovery window goal for disk backups
The recovery window for tape backups
Whether Recovery Appliance must replicate backups or copy them to tape before deleting them
Which Recovery Appliance storage location is used for backups
An optional backup polling policy

You can attach multiple protected databases to a single protection policy. A Recovery Appliance may have a variety of protection policies to support different data protection support levels. For example, protection policies can be generic service levels such as gold, silver, and bronze. Alternatively, policies can be specific to the requirements of protected databases and applications.

Overview of 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 8-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.

Figure 8-1 Protection Policies

Description of "Figure 8-1 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.

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.

User Interfaces for Protection Policies

This section contains the following topics:

Accessing the Create Protection Policy Page in Cloud Control

The Create Protection Policy page in Oracle Enterprise Manager Cloud Control (Cloud Control) is the recommended interface for creating protection policies.

To access the Create Protection Policy page:

Access the Recovery Appliance Home page, as described in "Accessing the Recovery Appliance Home Page".
From the Recovery Appliance menu, select Protection Policies.

The Recovery Appliance Login page appears.
Enter your login credentials, and then click Login.

The Protection Policies page appears, as shown in the example in Figure 8-2.

Figure 8-2 Protection Policies Page

Description of "Figure 8-2 Protection Policies Page"

DBMS_RA Procedures Relating to Protection Policies

You can use the DBMS_RA package to create and manage protection policies. Table 8-1 describes the principal program units relating to protection policies.

Table 8-1 DBMS_RA Protection Policy Procedures

Program Unit	Description
`CREATE_POLLING_POLICY`	Creates a backup polling policy.
`CREATE_PROTECTION_POLICY`	Creates a protection policy.
`DELETE_PROTECTION_POLICY`	Deletes a protection policy.
`UPDATE_PROTECTION_POLICY`	Updates a protection policy.

See Also:

DBMS_RA Package Reference

Recovery Catalog Views for Protection Policies

You can monitor protection policies using the Recovery Appliance catalog views. Table 8-2 summarizes the views that are most relevant for protection policies.

Table 8-2 Recovery Catalog Views for Protection Policies

View	Description
`RA_PROTECTION_POLICY`	This view describes the defined protection policies.
`RA_POLLING_POLICY`	This view describes the defined backup polling policies.
`RA_DATABASE`	The `POLICY_NAME` column of this view lists the protection policy used by this protected database.
`RA_REPLICATION_CONFIG`	The `PROTECTION_POLICY` column of this view lists the protection policy for a particular Recovery Appliance used for replication.
`RA_REPLICATION_DATABASE`	The `POLICY_NAME` column of this view lists the protection policy that is associated with this replication server and database.
`RA_REPLICATION_PAIR`	This view lists replication information for replicating protection policies.
`RA_REPLICATION_POLICY`	The `POLICY_NAME` column of this view lists the protection policy associated with this replication server configuration.

See Also:

Recovery Appliance View Reference

Basic Tasks for Managing Protection Policies

This section explains the basic tasks involved in managing protection policies. Figure 8-3 shows the overall workflow described in Recovery Appliance Workflow, with the protection policy tasks highlighted.

Figure 8-3 Protection Policy Tasks in Recovery Appliance Workflow

Description of "Figure 8-3 Protection Policy Tasks in Recovery Appliance Workflow"

Typically, you perform protection policy tasks in the following sequence:

During the planning phase, group the databases into tiers, and decide the recovery requirements for each tier.

"Planning for Recovery Appliance" describes these tasks.
During the configuration phase (see "Setup and Configuration for Recovery Appliance"), create one protection policy for each database tier.
1. Optionally, if your Recovery Appliance has access to a backup polling location, and if you are performing configuration using command-line tools, then create a backup polling policy.
  
  "Creating a Backup Polling Policy (Command-Line Only)" describes this task.
  
  Note:
  
  Cloud Control enables you to configure the polling policy and the protection policy in the same page.
2. Create a protection policy for a specific database tier.
  
  "Creating a Protection Policy" describes this task.
During the ongoing maintenance phase (see "Maintenance Tasks for Recovery Appliance"), modify protection policies as needed. Typical modification tasks include:
- Update the attributes of a protection policy.
  
  "Updating a Protection Policy" describes this task.
- Delete a protection policy.
  
  "Deleting a Protection Policy" describes this task.

Creating a Protection Policy

This section explains how to create a protection policy using either Cloud Control (recommended) or the DBMS_RA.CREATE_PROTECTION_POLICY procedure. The best practice is to create a separate protection policy for each tier of databases (see "Task 1: Group protected databases into tiers").

You must be logged in to the Recovery Appliance as RASYS or as a named db_user with user_type=admin.

Cloud_Control
Command_Line

To create a Protection Policy with Cloud Control:

Access the Protected Databases page, as described in "Accessing the Protected Databases Page in Cloud Control".
Click Add.

The Add Protected Databases page appears.

Figure 8-4 Add Protected Databases Page

Description of "Figure 8-4 Add Protected Databases Page"
Click Create.

The Create Protection Policy page appears.

Figure 8-5 Create Protection Policy Page

Description of "Figure 8-5 Create Protection Policy Page"

In this page, the default Recovery Appliance storage location DELTA is already selected.
Enter values as follows:
- In the Name field, enter the name of the new protection policy.
  
  For example, enter bronze_dev.
- In the Description field, enter a description for the new policy.
  
  For example enter, Policy with disk recovery window of 3 days and no tape backup.
- In the Recovery Window field of the Disk Recovery Window Goal section, specify a recovery window goal that the Recovery Appliance should attempt to meet for point-in-time recovery using disk backups, and then select the units.
  
  For example, enter 3 and then select days.
- If the protection policy is being configured for regulatory operation, specify the Recovery Window Compliance. This setting specifies a time range for each database backup in which backups will not be deleted. This value must be equal to or smaller than recovery_window_goal. Too large a value can result in filling disk_reserved_space with compliance protected backups, whereby new backups are then rejected.
- In the Threshold field of the Unprotected Data Window Threshold section, enter the maximum tolerable interval for data loss.
  
  For example, enter 5 and then select minutes.
- If the protection policy is being configured for compliance operation, Keep Compliance specifies that backups are held until their "keep until time".
- The Autotuned Reserved Space specifies whether or not the Recovery Appliance will automatically define and / or update the reserved_space for databases associated with this policy.
  
  For compliance backups, reserved_space is a hard limit allocated for a given database, so autotune_reserved_space does not apply.
- In the Recovery Window field of the Media Manager Recovery Window Policy section, optionally specify a larger window within which point-in-time recovery from a media manager will be maintained.
  
  For example, if no tape backup is desired, then leave this field blank.
- In the Maximum Retention field of the Maximum Disk Backup Retention section, enter the maximum time that the Recovery Appliance must retain disk backups. This should be greater than or equal to the recovery window goal.
  
  For example, if not specified, backups are retained beyond the disk recovery goal as space permits.
Optionally, you can change items in the Advanced section.
- In the Backup and Redo Failover section, specify whether protection databases associated with this protection policy are using this Recovery Appliance as an alternate destination.
- If not using Recovery Window Compliance or Keep Compliance, then optionally the Backup Deletion section specifies if the Recovery Appliance allows backup deletion with RMAN DELETE (administrator role).
- In the Backup Polling Location section, define a backup polling policy.
  - In the Location field, specify a directory accessible by the Recovery Appliance.
  - In the Frequency field, specify a time interval, and then select the time units.
  For example, to specify that backup polling is disabled, leave the fields blank.
- In the Backup Copy Policy section, specify whether the Recovery Appliance must replicate backups or copy backups to tape before deleting them.
  
  For example, select Always accept new backups even if it requires purging existing backups not yet copied to tape or replicated.
- In the Archived Log Backup Compression, you can select the compression algorithm for archived log backups.
Click OK.

The Protection Policies page appears, with the newly created protection policy listed.

See Also:

"How Recovery Appliance Manages Storage Space"
"Backup Polling Policies"
"Backup Polling Locations"
Cloud Control online help for more information about the Create Protection Policy page

To create a Protection Policy with PL/SQL:

Assume that you want to create a protection policy named bronze_dev for a tier of databases in a development environment. You have the following requirements for all databases protected by this policy:

The disk recovery window goal is 3 days, which means that every database must be recoverable using disk backups to any time within the last 3 days, starting from the current time.
You do not want to archive backups to tape.
You want the Recovery Appliance to receive new backups even if old backups must be deleted because available storage space is low.
No backup polling policy is enabled.

You also want to create policies for gold_dev, with a disk recovery window goal of 35 days, and silver_dev, with a disk recovery window goal of 10 days. Additionally, you create one policy named bronze_dev with a disk recovery window goal of 12 hours.

Start SQL*Plus or SQL Developer, and then log in to the metadata database as RASYS or as a named db_user with user_type=admin.

Run the DBMS_RA.CREATE_PROTECTION_POLICY procedure.

For example, execute the following PL/SQL anonymous block:

BEGIN
 DBMS_RA.CREATE_PROTECTION_POLICY (
  protection_policy_name => 'bronze_dev',
  description            => 'For protected dbs in bronze tier',
  storage_location_name  => 'delta',
  recovery_window_goal   => INTERVAL '3' DAY,
  guaranteed_copy        => 'NO');
 DBMS_RA.CREATE_PROTECTION_POLICY (
  protection_policy_name => 'silver_dev',
  description            => 'For protected dbs in silver tier',
  storage_location_name  => 'delta',
  recovery_window_goal   => INTERVAL '10' DAY,
  guaranteed_copy        => 'NO');
 DBMS_RA.CREATE_PROTECTION_POLICY (
  protection_policy_name => 'gold_dev',
  description            => 'For protected dbs in gold tier',
  storage_location_name  => 'delta',
  recovery_window_goal   => INTERVAL '35' DAY,
  guaranteed_copy        => 'NO');
 DBMS_RA.CREATE_PROTECTION_POLICY (
  protection_policy_name => 'test_dev',
  description            => 'Test policy',
  storage_location_name  => 'delta',
  recovery_window_goal   => INTERVAL '12' HOUR,
  guaranteed_copy        => 'NO');
END;

Note:

Pay attention to the attributes that are mutually exclusive, such as the parameters associated with compliance versus the parameters of back up deletion or autotuning reserved space.

Optionally, query the recovery catalog to confirm creation of the policy.

For example, query RA_PROTECTION_POLICY as follows (sample output included):

COL POLICY_NAME FORMAT a11
COL DESCRIPTION FORMAT a36
SELECT POLICY_NAME, DESCRIPTION, 
       TO_CHAR(EXTRACT(DAY FROM RECOVERY_WINDOW_GOAL),'fm00')||':'||
       TO_CHAR(EXTRACT(HOUR FROM RECOVERY_WINDOW_GOAL),'fm00')||':'||
       TO_CHAR(EXTRACT(MINUTE FROM RECOVERY_WINDOW_GOAL),'fm00')||':'||
       TO_CHAR(EXTRACT(SECOND FROM RECOVERY_WINDOW_GOAL),'fm00')
         AS "DD:HH:MM:SS"
FROM   RA_PROTECTION_POLICY
WHERE  POLICY_NAME LIKE '%DEV'
ORDER BY POLICY_NAME;

POLICY_NAME DESCRIPTION                          DD:HH:MM:SS
----------- ------------------------------------ ---------------
BRONZE_DEV  For protected dbs in bronze_dev tier 03:00:00:00
GOLD_DEV    For protected dbs in gold_dev tier   35:00:00:00
SILVER_DEV  For protected dbs in silver_dev tier 10:00:00:00
TEST_DEV    Test policy                          00:12:00:00

See Also:

Protection Policy Attributes

A protection policy is created with the DBMS_RA.CREATE_PROTECTION_POLICY procedure or with Cloud Control. The protection policy sets some of the following attributes for all protected databases assigned to it: Some attributes are mutually exclusive. The following is a representative list of attributes to consider in new protection policies.

Table 8-3 Protection Policy Attributes (subset)

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 cloud before being considered for deletion.
`allow_backup_deletion`	Setting this to `NO` will prevent RMAN users from deleting backups on the Recovery Appliance, necessary for compliance rules. The default value is set to `YES`.
`store_and_forward`	The setting for the Backup and Redo Failover feature. This setting is used only in a protection policy defined on the alternate Recovery Appliance where the protected databases associated with this policy will redirect backups and redo in the event of an outage on the primary Recovery Appliance.
`max_retention_window`	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.
`autotune_reserved_space`	This setting is used to control whether the Recovery Appliance will automatically define and update the `reserved_space` settings for databases associated with this policy. Do not use `autotune_reserved_space` with any of the compliance parameters: `recovery_window_compliance` or `keep_compliance`
`autotune_space_limit`	This parameter limits unconstrained growth of `reserved_space` by the autotune reserved space feature when a storage location begins to fill. Autotune will not restrict reserved space growth when the total reserved space usage is below this specified limit. When the total reserved space usage is above this specified limit, autotune will restrict subsequent `reserved_space` growth to 10% per week for each database in the storage location. If no unit is specified, then Recovery Appliance interprets the value as a number of bytes. This value may be set to `NULL` if there should never be restrictions on on reserved space growth through the `autotune_reserved_space` option.
`recovery_window_compliance`	This setting specifies a time range for each database backup in which backups will not be deleted. This value must be equal to or smaller than `recovery_window_goal`. Too large a value can result in filling `disk_reserved_space`, whereby new backups are then rejected.
`keep_compliance`	This setting prevents an administrator from using `RMAN CHANGE` command to shrink the "keep until time" specified for an archival backup. If `KEEP_COMPLIANCE` is `YES`, `KEEP FOREVER` backups will never be deleted. `NO` means the "keep until time" for an archival backup may be modified by the `RMAN CHANGE` command. `NO` is the default.
`max_reserved_space`	The maximum `disk_reserved_space` setting permitted for each database in the protection policy. The format of this value is a character string that must contain a number consisting only of the characters `0-9`, followed optionally by one of the following unit specifiers: If `max_reserved_space` is specified as NULL, the `disk_reserved_space` setting for databases will not be constrained except by the restriction that the sum of the reserved spaces for all databases must fit within the storage location.

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.

Updating a Protection Policy

This section explains how to update protection policies using either Cloud Control (recommended) or the DBMS_RA PL/SQL package.

You must be logged in to the metadata database as RASYS or as a named db_user with user_type=admin. The protection policy must exist.

In this example, the protection policy is bronze_dev and is changing its disk recovery window goal from 3 days to 6 days.

Cloud_Control
Command_Line

To update a protected database with Cloud Control:

Access the Protection Policies page, as described in "Accessing the Create Protection Policy Page in Cloud Control".
In the Protection Policies table, select the protection policy that you want to edit.

For example, select the BRONZE_DEV row.
Click Edit.

The Edit Protection Policy page appears.
Change the desired values, and then click OK.

For example, in the Recovery Window field of the Disk Recovery Window Goal section, enter 6.

The Protection Policies page appears, with the newly updated protection policy listed.

To update a protection Policy with DBMS_RA:

To update a protection policy, execute the DBMS_RA.UPDATE_PROTECTION_POLICY procedure. Parameters that are null retain their existing values. For example, if guaranteed_copy is currently NO for a protection policy, and if you specify null for this parameter in DBMS_RA.UPDATE_PROTECTION_POLICY, then the value remains NO.

Start SQL*Plus or SQL Developer, and then log in to the metadata database as RASYS or as a named db_user with user_type=admin.

Run the DBMS_RA.UPDATE_PROTECTION_POLICY procedure.

For example, execute the following PL/SQL anonymous block:

BEGIN
 DBMS_RA.UPDATE_PROTECTION_POLICY(
  protection_policy_name => 'bronze_dev',
  recovery_window_goal   => INTERVAL '6' DAY);
END;

Optionally, query the recovery catalog to confirm the update of the policy.

For example, query RA_PROTECTION_POLICY as follows (sample output included):

COL POLICY_NAME FORMAT a11
COL DESCRIPTION FORMAT a36
SELECT POLICY_NAME, DESCRIPTION, 
       TO_CHAR(EXTRACT(DAY FROM RECOVERY_WINDOW_GOAL),'fm00')    ||':'||
       TO_CHAR(EXTRACT(HOUR FROM RECOVERY_WINDOW_GOAL),'fm00')   ||':'||
       TO_CHAR(EXTRACT(MINUTE FROM RECOVERY_WINDOW_GOAL),'fm00') ||':'||
       TO_CHAR(EXTRACT(SECOND FROM RECOVERY_WINDOW_GOAL),'fm00')
         AS "DD:HH:MM:SS"
FROM   RA_PROTECTION_POLICY
WHERE  POLICY_NAME='BRONZE_DEV';

POLICY_NAME DESCRIPTION                          DD:HH:MM:SS
----------- ------------------------------------ ---------------
BRONZE_DEV  For protected dbs in bronze tier     06:00:00:00

Deleting a Protection Policy

This section explains how to delete protection policies using either Cloud Control (recommended) or the DBMS_RA PL/SQL package.

You must be logged in to metadata database of the Recovery Appliance as RASYS or as a named db_user with user_type=admin.

The protection policy must not be associated with any protected database. To delete a policy that is associated with one or more databases, you must associate those databases with different policies before you can delete the desired policy.

In the following example, assume that you want to delete the bronze_dev policy.

Cloud_Control
Command_Line

To delete a protected database with Cloud Control:

Access the Protection Policies page, as described in "Accessing the Create Protection Policy Page in Cloud Control".
In the Protection Policies table, select the protection policy that you want to delete.

For example, select the BRONZE_DEV row.
Click Delete.

A confirmation window appears.
Click Yes.

The Protection Policies page appears, with the deleted protection policy no longer listed.

To delete a protected database with DBMS_RA:

In the following example, assume that you want to delete the bronze_dev policy.

Start SQL*Plus or SQL Developer, and then log in to the metadata database as RASYS or as a named db_user with user_type=admin..

Confirm that the protection policy that you intend to delete is not currently associated with any protected databases.

For example, query all protection policies not associated with databases:

SELECT POLICY_NAME AS "Currently unused policy"
FROM   RA_PROTECTION_POLICY
WHERE  POLICY_NAME NOT IN (SELECT POLICY_NAME FROM RA_DATABASE)
ORDER BY POLICY_NAME;

Currently unused policy
-----------------------
BRONZE_DEV

Delete the policy.

For example, execute the following PL/SQL anonymous block to delete the protection policy named bronze_dev:
```
BEGIN
  DBMS_RA.DELETE_PROTECTION_POLICY(
    protection_policy_name => 'BRONZE_DEV');
END;
```
Optionally, confirm the deletion.

For example, count the rows for policies named bronze_dev (sample output included):
```
SELECT COUNT(*)
FROM   RA_PROTECTION_POLICY
WHERE  POLICY_NAME = 'BRONZE_DEV';

  COUNT(*)
----------
         0
```

Creating a Backup Polling Policy (Command-Line Only)

An optional backup polling policy defines a directory where a protected database places backup sets without interacting directly with a Recovery Appliance. The backup polling directory must be created on an external file system and made accessible to a Recovery Appliance as an NFS mount point. The polling policy defines the file system path to the storage and how often the Recovery Appliance checks it for new backup sets (not image copies). Specify the polling policy name within a protection policy.

Note:

The separate step of creating a backup polling policy is not necessary in Cloud Control, which includes it in the Create Protection Policy page.

Backup polling policies are useful for the following reasons:

If a Recovery Appliance is offline, then protected databases can continue to send backups to backup polling locations. When a Recovery Appliance comes online, it can poll these locations for backups.
If the storage network is faster than your Ethernet, and if you configure the polling location in network storage, then protected database backups to the polling location may be faster.
You can use a polling location when migrating legacy backups to a Recovery Appliance.

Protected databases that use backup polling store backup pieces and archived redo log files in shared storage. The Recovery Appliance periodically retrieves and processes backups from the shared storage.

Prerequisites

You must log in to the metadata database as RASYS.

Assumptions

Assume that you want to create a polling policy that meets the following requirements:

The Recovery Appliance must poll the /u03/shared/polling1 directory, which is a shared directory accessible by the Recovery Appliance and all protected databases.
You want the Recovery Appliance to poll the shared directory every 4 hours.
You want the Recovery Appliance to delete backups from the shared directory after it has processed them.

To create a backup polling policy:

Start SQL*Plus or SQL Developer, and then log in to the metadata database as RASYS.

Run the DBMS_RA.CREATE_POLLING_POLICY procedure.

For example, execute the following PL/SQL anonymous block:

BEGIN
  DBMS_RA.CREATE_POLLING_POLICY (
    polling_policy_name   => 'nas_polling1',
    polling_location      => '/u03/shared/polling1',
    polling_frequency     =>  INTERVAL '4' HOUR,
    delete_input          =>  TRUE);
END;

Optionally, query the recovery catalog to confirm creation of the policy.

For example, query RA_POLLING_POLICY as follows (sample output included):

COL POLLING_NAME FORMAT a15
COL DEST FORMAT a40
SELECT POLLING_NAME, DEST, DELETE_INPUT,
       TO_CHAR(EXTRACT(DAY FROM FREQUENCY),'fm00')||':'||
       TO_CHAR(EXTRACT(HOUR FROM FREQUENCY),'fm00')||':'||
       TO_CHAR(EXTRACT(MINUTE FROM FREQUENCY),'fm00')||':'||
       TO_CHAR(EXTRACT(SECOND FROM FREQUENCY),'fm00')
         AS "DD:HH:MM:SS"
FROM   RA_POLLING_POLICY;

POLLING_NAME    DEST                                     DELET DD:HH:MM:SS
--------------- ---------------------------------------- ----- ---------------
NAS_POLLING1    /u03/shared/polling1/                    TRUE  00:04:00:00

See Also:

"Backup Polling Policies" for more information about polling
"CREATE_POLLING_POLICY" for descriptions of procedure arguments