This chapter describes the basic architecture and concepts for Zero Data Loss Recovery Appliance, commonly known as Recovery Appliance.
This chapter contains the following topics:
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
This section contains the following topics:
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.
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 |
|
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 |
|
|
Recovery Appliance |
|
This database account owns the Recovery Appliance schema, which includes the RMAN recovery catalog and the |
|
Recovery Appliance |
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 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 |
|
Protected Database |
Protected database backup administrator |
User account with |
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 |
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
See Also:
Oracle Database Security Guide to learn how to create database user accounts
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:
Oracle Database Backup and Recovery User's Guide to learn how to make incremental backups
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:
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
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
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 tapeFoot 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
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 |
---|---|
|
|
|
An optional backup polling policy that determines whether Recovery Appliance polls a storage location for backups |
|
The disk recovery window goal for the protected database. |
|
|
|
The guaranteed copy setting, which determines whether backups protected by this policy must be copied to tape or replicated before being considered for deletion |
|
The maximum length of time that the Recovery Appliance retains backups for databases that use this retention policy |
|
The maximum acceptable difference between the current time and the latest time that the database can be restored |
When creating a protection policy, you can define the following two recovery window attributes, expressed as intervals (typically days):
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.
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:
Zero Data Loss Recovery Appliance Protected Database Configuration Guide
Oracle Database Backup and Recovery User's Guide for a thorough discussion of recovery windows
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.
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.
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.
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
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
This section contains the following topics:
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.
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.
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.
See Also:
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.
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"
Oracle Database Backup and Recovery User's Guide to learn how to manage a recovery catalog
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.
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.
Redo staging area
For Recovery Appliance installations that enable real-time redo transport, this is the destination for redo streams that protected databases transmit to Recovery Appliance. The staging area resides on Recovery Appliance disks. The Recovery Appliance collects data into archived redo log files, which it then converts to compressed archived redo log backups that it writes to a Recovery Appliance storage location.
See Also:
Zero Data Loss Recovery Appliance Protected Database Configuration Guide to learn how to configure real-time redo transport
A Recovery Appliance storage location can be shared among multiple protected databases. The Recovery Appliance administrator decides which clients will use each storage location.
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.
A more complex implementation may require multiple storage locations, for reasons such as expansion and space allotment. Figure 2-8 shows a Recovery Appliance configured with two storage locations: DELTA
(default) and DELTA2
(nondefault).
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 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.
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-9 depicts this configuration.
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
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:
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:
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.
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:
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:
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:
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 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 Secure Backup Administrator's Guide to learn more about Oracle Secure Backup
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.
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
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.
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.
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.
The upstream Recovery Appliance forwards the backups to the downstream 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:
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 asymmetry allows for a wide variety of use cases to be configured, some of which are shown in Figure 2-10.
Figure 2-10 Recovery Appliance Replication Use Cases
Figure 2-10 depicts the following use cases:
Backup data flows from local databases to an upstream Recovery Appliance, which forwards it to a remote downstream Recovery Appliance.
Backups flow from local databases to a local Recovery Appliance, which then forwards them to a remote Recovery Appliance. Conversely, backups flow from remote databases to a remote Recovery Appliance, which then forwards them to the local Recovery Appliance.
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.
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.
Any of the preceding use cases could be adapted for cascaded replication, in which a downstream Recovery Appliance forwards its backups to a second downstream Recovery Appliance, creating a one-way chain of Recovery Appliances.
Various encryption options are available for backups and redo sent to the Recovery Appliance, as shown in Figure 2-11. The Recovery Appliance does not provide server-side encryption, which means that the appliance does not itself encrypt and decrypt data.
The following types of encryption are supported:
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
Oracle Net security includes an LDAP-compliant directory server, digital certificates, and Secure Sockets Layer (SSL). Oracle Net security encrypts the transfer of backups and redo to the Recovery Appliance. This technique provides in-transit network encryption that is independent of TDE encryption of the database, redo encryption using LOG_ARCHIVE_DEST_
n
, or RMAN backup encryption.
See Also:
Oracle Database Security Guide to learn how to configure SSL
Oracle Database Advanced Security Guide to learn about Oracle Net security
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
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