立即与支持人员聊天
与支持团队交流

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

Reviewing the other backup types

Other backup types include:

•
Duplicate Database backup
•
Flash Recovery Area (FRA) backups
Duplicate Database backup

A Duplicate Database backup lets you duplicate or clone a source database for special purposes that must not affect the overall backup and restore procedures for the source database. RMAN supports duplicating databases to increase a DBA’s flexibility when performing the following tasks:

•
Testing backup and recovery procedures.
•
Testing an upgrade to a new release of Oracle® Database.
•
Testing the effect of applications on database performance.
•
Generating reports.

For example, you can duplicate the production database on hostA to hostB, and then use the duplicate database on hostB to practice restoring and recovering this database without damaging the production database.

The plug-in’s support for Oracle’s Database Duplication is backup-based duplication. For additional information on Oracle’s Duplicate Database functionality, see Duplicating a Database in the Oracle Database Backup and Recovery User’s Guide.

Flash Recovery Area (FRA) backups

Oracle® introduced FRA in Oracle 10g. FRA is a disk location used to store recovery-related files such as Control Files, archived redo logs, and RMAN backups. Oracle and RMAN manage the files in the FRA automatically.

An FRA minimizes the need to manage disk space manually for backup-related files and balance the use of space among the different types of files stored in the FRA. In this way, FRA simplifies the ongoing administration of your database. Oracle recommends that you enable a recovery area to simplify backup management.

Enabling FRA can speed up restores by enabling RMAN to restore the needed datafiles from the FRA versus restoring the files from backup media managed by NetVault Backup server. However, storing backups in the FRA does not provide you with offsite protection for disaster recovery protection. Therefore, the plug-in provides the following Backup Destination options when FRA is enabled for the database:

•
NetVault Backup Media Manager
•
Disk (Backup to FRA)
•
Both NetVault Backup Media Manager and Disk (Backup to FRA then Backup FRA to NetVault Backup Media)

Additionally, the plug-in lets you perform a separate backup of the backup recovery files stored in the FRA-to-backup media managed by NetVault Backup server. Backup recovery files include: Full and Incremental Backup sets, Control File Autobackups, datafile copies, and archived redo logs. If an archived redo log file is missing or corrupted, RMAN looks outside the recovery area for a good copy of the log that it can use for the backup. Flashback logs, the current Control File, and online redo logs are not backed up.

Developing a Recovery Catalog backup strategy

The Recovery Catalog database is similar to any other database, and must be a key part of your backup-and-recovery strategy.

Oracle® recommends that you back up the Recovery Catalog with the same frequency that you back up the target database. For example, if you make a weekly whole-database backup of the target database, back up the Recovery Catalog immediately after all target database backups to protect the record of the whole-database backup. This backup can also help you in a disaster recovery scenario. Even if you have to restore the Recovery Catalog database using a Control File Autobackup, you can then use the full record of backups in your restored Recovery Catalog database to restore the target database without using a Control File Autobackup for the target database.

Oracle recommends the following guidelines for an RMAN backup strategy for the Recovery Catalog database:

•
Run the Recovery Catalog database in ARCHIVELOG mode so that PIT Recovery is possible.
•
Back up the database onto two separate media, for example, disk and tape.
•
Include Archived Log files in your backups.
•
Do not use a different Recovery Catalog as the repository for the backups.
•
Configure the Control File Autobackup feature to ON.

Examples of backup sequences

Following are a few examples of backup sequences that can be implemented to meet the data protection requirements of your Oracle® Database Server.

•
Full Backups only: When requirements guarantee data protection up to the previous day, performing Full Backups daily should be sufficient. DBAs are only required to recover the database up to the point of the last Full Backup.
•
Full Backup and Archived Log Backups: When requirements mandate PIT data protection but recovery time is not important, Full Backups coupled with Archived Log backups should provide the necessary protection.
For example, Full Backups are performed every Sunday night at 11:00 p.m., while Archived Log backups are performed Monday through Saturday at 11:00 p.m.
This strategy requires RMAN to restore and apply each Archived Log backup between the last Full Backup and the point-of-failure in succession. This strategy can lead to longer recovery as the week progresses. To speed up restores, you can include Incremental backups, which reduce the number of Archived Log backups that must be restored.
•
Incremental Level 0 and Differential Incremental Level 1 and Archived Log Backups: When requirements mandate PIT data protection and backups have to be as fast as possible, Incremental Level 0 and Differential Incremental Backup and Archived Redo Log backups are an ideal strategy.
For example, Incremental Level 0 backups are performed every Sunday night at 11:00 p.m., while Differential Incremental Level 1 backups are performed Monday through Saturday at 11:00 p.m., and Archived Log backups are performed every 5 to 6 hours. Each Differential Incremental Level 1 backup includes all the changes since the last Level 0 or Level 1 backup, and the Archived Log backups include the transaction logs since the last Differential Incremental Level 1 backup.
This strategy can lead to longer recovery because RMAN must restore the Incremental Level 0 backup, each Differential Incremental Level 1 backup since the Incremental Level 0 backup, and the Archived Log backups between the last Differential Incremental backup and the point-of-failure.
•
Incremental Level 0 and Cumulative Incremental Level 1 and Archived Log Backups: When requirements mandate PIT data protection and recovery time should be as fast as possible, Incremental Level 0 and Cumulative Incremental Level 1 and Archived Log backups are the best combination.
For example, Incremental Level 0 backups are performed every Sunday night at 11:00 p.m., while Cumulative Incremental Level 1 backups are performed Monday through Saturday at 11:00 p.m. and Archived Log backups are performed every 5 to 6 hours. Each Cumulative Incremental Level 1 backup includes all the changes since the last Incremental Level 0 backup, and the Archived Log backups include the Redo Logs since the last Cumulative Incremental Level 1 backup.
This strategy leads to quick recovery because RMAN only has to restore the Incremental Level 0 backup, the last Cumulative backup, and the Archived Log backups created between the last Cumulative backup and the point-of-failure.
相关文档

The document was helpful.

选择评级

I easily found the information I needed.

选择评级