Chat now with support
Chat with Support

NetVault Plug-in for Oracle 11.3 - User Guide

Introducing Quest® NetVault® Backup Plug-in  for Oracle Defining a backup strategy Installing and removing the plug-in Configuring the plug-in Backing up data Using the Oracle® Flashback Database Restoring data
Restoring and recovering data: an overview Performing User Managed restores Using advanced User Managed restore procedures Performing RMAN restores Using RMAN types of recovery in a non-RAC environment Using advanced procedures with RMAN restores
Maintaining the Recovery Catalog Using the RMAN CLI Using the Plug-in with Oracle® RAC Using the Plug-in in a failover cluster environment Using the plug-in with Oracle® Data Guard Troubleshooting

Defining an RMAN backup strategy

The first step in defining an RMAN backup strategy is determining the location for the RMAN repository. The second step involves determining the types and frequency of backups that are needed to meet your recovery requirements. These steps are discussed in the following topics:

•
Choosing the location for the RMAN repository
•
Reviewing the RMAN Tablespace and Datafile backup types

Choosing the location for the RMAN repository

The RMAN repository is the collection of metadata about backup and recovery operations on the target database. The authoritative copy of the RMAN repository is always stored in the Control File of the target database. You can also use a Recovery Catalog, that is, an external database, to store this information.

•
Control File: RMAN can conduct all necessary backup and recovery operations using just the Control File to store the RMAN repository information. This ability increases the importance of protecting the Control File as part of your backup strategy.
Storing the RMAN repository in the Control File is especially appropriate for small databases where installation and administration of a separate Recovery Catalog database are burdensome. The only RMAN feature that is not supported in this mode is stored scripts, which are not used by the plug-in.
When using the Control File to store the RMAN repository, Oracle® highly recommends the following:
•
Enable Oracle’s Control File Autobackup feature. This feature causes RMAN to back up the Control File automatically, and also lets RMAN restore the Control File Autobackup without access to a repository.
•
Keep a record of your Oracle Database ID (DBID), which may be required to recover the database when the Control File is lost.
•
Use a minimum of two multiplexed or mirrored Control Files on separate disks.
•
Recovery Catalog: You can also use an external Oracle database to store the RMAN repository. This external database is known as the Recovery Catalog. While the Control File has finite space for records of backup activities, a Recovery Catalog can store a longer history. The complexity of administering a Recovery Catalog database can be offset by the convenience of having the extended backup history available for a recovery that precedes the history in the Control File.
RMAN maintains the Recovery Catalog’s version of the RMAN repository. The database targeted for backup never accesses it directly because RMAN propagates the information about the database structure, archived redo logs, backup sets, and datafile copies into the Recovery Catalog from the target database’s Control File after any operation.
Oracle recommends that you store the Recovery Catalog in a dedicated database. If you store the Recovery Catalog alongside other data in a database and you lose that other database, you lose your Recovery Catalog as well. This configuration makes recovery more difficult. Moreover, if you store the Recovery Catalog in a database that is targeted for backup, you cannot perform whole database restores for that database. You cannot restore the whole database because the database must be in a mounted state for restores, and the plug-in does not have access to the Recovery Catalog to perform the recovery in that state.

Reviewing the RMAN Tablespace and Datafile backup types

Plug‑in for Oracle supports following types of RMAN backups:

•
Full Backup
•
Incremental Backup

The Incremental Backups are further classified as follows:

•
Level 0 Incremental Backup
•
Level 1 Incremental Backup
•
Differential Incremental Backup
•
Cumulative Incremental Backup
Full Backup

An RMAN Full Backup is a backup of a datafile that includes every allocated block in the file being backed up. A Full Backup of a datafile can be an image copy, in which case every data block is backed up. You can also store it in a backup set, in which case datafile blocks not in use may be skipped. An RMAN Full Backup cannot be part of an Incremental Backup strategy, that is, it cannot be the parent or base of a subsequent Incremental Backup.

Incremental Backup

An Incremental Backup of a datafile captures images of blocks in the datafile that have changed since a specific point, usually the time of a previous Incremental Backup. Incremental backups are smaller than full datafile backups, unless every block in the datafile is changed. RMAN Incremental Backups are only available for datafiles.

During media recovery, RMAN uses the block images from Incremental Backups to update changed blocks to their contents at the SCN where the block was created. RMAN completes this process in a single step. Without Incremental Backups, all changes must be applied one at a time from the archived redo logs. To reduce downtime, RMAN always chooses an Incremental Backup over reapplying individual changes stored in archived redo logs.

Multilevel Incremental Backups

RMAN’s Incremental Backups are multilevel. Each incremental level is denoted by a value of 0 or 1.

•
Level 0 Incremental Backup: A Level 0 Incremental Backup, which is the base for subsequent Incremental Backups, copies all blocks containing data, backing up the datafile into a backup set just as a Full Backup would.
The only difference between a Level 0 Incremental Backup and a Full Backup is that a Full Backup cannot be included in an incremental strategy.
•
Level 1 Incremental Backup: A Level 1 Incremental Backup can be either of the following types:
•
Cumulative Incremental Backup: In a Cumulative Incremental Backup, RMAN backs up all the blocks used since the most recent Level 0 Incremental Backup. Cumulative Incremental Backups speed up restores by reducing the number of Incremental Backups you need to include in the recovery process. Cumulative Backups require more space and time than Differential Backups because they duplicate the work done by previous backups at the same level.
Cumulative Backups are preferred over Differential Backups when recovery time is more important than disk space, because fewer Incremental Backups need to be applied during recovery.
•
Differential Incremental Backup: In a Differential Incremental Backup, RMAN backs up all blocks that have changed since the most recent Cumulative or Differential Incremental Backup, whether at Level 1 or Level 0.
RMAN determines which Level 1 backup occurred most recently and backs up all blocks modified since that backup. If no Level 1 is available, RMAN copies all blocks changed since the Level 0 backup.
Differential Incremental Backups lead to longer restores because multiple Incremental Backups must be applied during recovery.
Archive Log backup

Archived redo logs are important for PIT Recovery and must be backed up regularly. You can back up the archive logs separately or together with the datafiles and other supported files. The plug-in also provides the option to force an additional log switch before backing up the archive logs and the option to delete the archive logs from the disk after backing them up to the backup sets.

Reviewing the Control File backup types

Protecting the Control File is critical in many recovery situations. Plug‑in for Oracle provides two methods for protecting the Control File: Manual Backups and Autobackups. However, when using the RMAN method, you can perform either Control File Autobackups or Manual Backups but not both. When the Control File Autobackups are enabled for a database, Manual Control File Backups are not available.

Manual Backups of Control File

The User Managed and RMAN backup methods both support Manual Backup of the Control File.

•
Manual Backup of Control File with User Managed backup method: With the User Managed backup method, the plug-in does not use the active Control File for backup and restore. During backup, the plug-in saves a snapshot of the Control File to the user-specified Control File Save Filename (Full Path), and then backs up this copy of the Control File. This process ensures that a consistent copy of the Control File is protected. During restoration, the plug-in restores the Control File to the Control File Save Filename (Full Path) to ensure that the active Control File is not inadvertently overwritten. Manually copy this file to the original location as required. To ensure that a recent copy of the Control File is always available, include it with each User Managed backup.
•
Manual Backup of Control File with RMAN backup method: When Control File Autobackups are disabled and the Control File node is explicitly selected on the NetVault Backup Selections page, the plug-in uses RMAN’s BACKUP CURRENT CONTROLFILE to back up the Control Files. To ensure that a recent copy of the Control File is always available, include it with each RMAN backup.
Autobackups of Control File

An Autobackup of the Control File also includes the SPFILE. The Autobackups are made after every RMAN-based backup or after making structural changes to the database. Structural changes include adding a tablespace, altering the state of a tablespace or datafile, adding an online redo log, renaming a file, adding a redo thread, and so on.

Manual vs. Autobackups

A Manual Control File backup lets you restore a specific copy of a Control File. This option is ideal when data corruption has occurred and you need to restore the version most recently saved before data corruption. You are responsible for ensuring that the Control File is backed up with every RMAN-based backup and after every database structural change. While Manual Control File backups offer the ability to restore specific Control File backups, they cannot be used during disaster recovery or in multi-instance RAC environments.

Control File Autobackups provide the most reliability to ensure that there is always a recent backup of the Control File. In addition, they are required for disaster recovery and in multi-instance RAC environments.

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating