What's New in Backup and Recovery?

This section describes the new backup and recovery features in Oracle Database 11g Release 1. The new features for this release greatly improve the manageability of Oracle Database backup and recovery. In particular, manageability is increased by the introduction of Data Recovery Advisor, better integration of RMAN with Data Guard, expansion of the recovery catalog functionality, and improved management of archived redo logs.

The new features in this release include:

• Data Recovery Advisor

  Data Recovery Advisor is a built-in tool to automatically diagnose data failures and recommend repairs. You can repair failures manually or request that they be repaired automatically. Data Recovery Advisor supports the LIST FAILURE, CHANGE FAILURE, ADVISE FAILURE, and REPAIR FAILURE commands.

  See Also:

  Chapter 14, "Diagnosing and Repairing Failures with Data Recovery Advisor", and Oracle Database Backup and Recovery Reference to learn about the Data Recovery Advisor commands

• Improved integration with Data Guard

  You can now set persistent RMAN configurations for a primary or physical standby database when RMAN is not connected as TARGET to the database. RMAN works seamlessly on all databases in the Data Guard environment, enabling you to use backups made on one database for restore and recovery on another database. The same recovery catalog can manage metadata for all primary and standby databases.

  See Also:

  "Configuring RMAN in a Data Guard Environment", and Oracle Data Guard Concepts and Administration

• Improved handling of long-term backups

  You can create a long-term or archival backup with BACKUP ... KEEP that retains only the archived log files needed to make the backup consistent.

  See Also:

  "Making Database Backups for Long-Term Storage", and Oracle Database Backup and Recovery Reference to learn about the BACKUP command

• Backup failover for archived redo logs in the flash recovery area

  When backing up archived redo log files located in the flash recovery area, RMAN can fail over to archiving destinations outside the recovery area. RMAN can use an intact copy of an archived log in an alternative location to continue writing backups when a log in the recovery area is missing or corrupted.

  See Also:

  "Archived Redo Log Failover"

• Archived log deletion policy enhancements

  When you CONFIGURE an archived log deletion policy, the configuration applies to all archiving destinations, including the flash recovery area. Both BACKUP ... DELETE INPUT and DELETE ... ARCHIVELOG obey this configuration, as does the flash recovery area. You can also CONFIGURE an archived redo log deletion policy so that logs are eligible for deletion only after being applied to or transferred to standby database destinations. You can set the policy for mandatory standby destinations only, or for any standby destinations.

  See Also:

  • "Configuring an Archived Redo Log Deletion Policy",

  • Oracle Database Backup and Recovery Reference to learn about the CONFIGURE ARCHIVELOG DELETION POLICY command

  • Oracle Data Guard Concepts and Administration to learn how to use RMAN in a Data Guard environment

• Network-enabled database duplication without backups

  You can use the DUPLICATE command to create a duplicate database or physical standby database over the network without a need for pre-existing database backups. This form of duplication is called active database duplication.

  See Also:

  Chapter 23, "Duplicating a Database", and Oracle Database Backup and Recovery Reference to learn about the DUPLICATE command

• Recovery catalog enhancements

  The owner of a recovery catalog can GRANT or REVOKE access to a subset of the catalog to other database users in the same recovery catalog database. This subset is called a virtual private catalog. You can also use the IMPORT CATALOG command to merge one recovery catalog (or metadata for specific databases in the catalog) into another recovery catalog.

  See Also:

  Chapter 12, "Managing a Recovery Catalog", and Oracle Database Backup and Recovery Reference to learn about the recovery catalog commands

• Multisection backups

  RMAN can back up a single file in parallel by dividing the work among multiple channels. Each channel backs up one file section. You create a multisection backup by specifying SECTION SIZE on the BACKUP command. Restoring a multisection backup in parallel is automatic and requires no option.

  You can parallelize validations of a file with VALIDATE ... SECTION SIZE.

  See Also:

  "Dividing the Backup of a Large Datafile into Sections", and Oracle Database Backup and Recovery Reference to learn about the BACKUP and VALIDATE commands

• Undo optimization

  The BACKUP command does not back up undo that is not needed for recovery of a backup. Undo is not needed if it was generated for a transaction that has already committed. This undo can represent the majority of undo in the database.

  See Also:

  "Overview of Backup Optimization", and Oracle Database Backup and Recovery Reference to learn about the BACKUP command

• Improved block media recovery performance

  When performing block media recovery, RMAN automatically searches the flashback logs, if they are available, for the required blocks before searching backups. Using blocks from the flashback logs can significantly improve block media recovery performance.

  See Also:

  "Overview of Block Media Recovery"

• Improved block corruption detection

  Several database components and utilities, including RMAN, can now detect a corrupt block and record it in V$DATABASE_BLOCK_CORRUPTION. When instance recovery detects a corrupt block, it records it in this view automatically. Oracle Database automatically updates this view when block corruptions are detected or repaired. The VALIDATE command is enhanced with many new options such as VALIDATE ... BLOCK and VALIDATE DATABASE.

  See Also:

  Chapter 15, "Validating Database Files and Backups", and Oracle Database Backup and Recovery Reference to learn about the VALIDATE command

• Faster backup compression

  In addition to the existing BZIP2 algorithm for binary compression of backups, RMAN also supports the ZLIB algorithm. ZLIB runs faster than BZIP2, but produces larger files. You can use the CONFIGURE COMPRESSION ALGORITHM command to choose between BZIP2 (default) and ZLIB for RMAN backups.

  See Also:

  "Configuring the Backup Compression Algorithm", and Oracle Database Backup and Recovery Reference to learn about the CONFIGURE command

• Block change tracking support for standby databases

  You can enable block change tracking on a physical standby database. When you back up the standby database, RMAN can use the block change tracking file to quickly identify the blocks that changed since the last incremental backup.

  See Also:

  "Making and Updating Incremental Backups"

• Improved scripting with RMAN substitution variables

  You can create RMAN command files and stored scripts that accept user input at runtime. Thus, backup scripts can use RMAN substitution variables for tags, filenames, restore point names, and so on.

  See Also:

  "Using Substitution Variables in Command Files" and "Creating and Executing Dynamic Stored Scripts"

• Integration with VSS-enabled applications

  The Oracle VSS writer is integrated with applications that use the Volume Shadow Copy Service (VSS) infrastructure on Windows. You can use VSS-enabled software and storage systems to back up and restore an Oracle database. A key benefit is the ability to make a shadow copy of an open database.

  See Also:

  Oracle Database Platform Guide for Microsoft Windows to learn how to perform backup and recovery with VSS-enabled applications, and Oracle Database Backup and Recovery Reference to learn about the BACKUP command

• Lost write detection

  You can enable the DB_LOST_WRITE_PROTECT initialization parameter to detect a lost write during managed recovery of a standby database or media recovery of a primary database. Lost write detection is disabled by default.

  See Also:

  "Enabling Lost Write Detection"

• Backup of read-only transportable tablespaces

  In previous releases, RMAN could not back up transportable tablespaces until they were made read/write at the destination database. Now RMAN can back up transportable tablespaces when they are not read/write and restore these backups.

  See Also:

  "Backing Up Tablespaces and Datafiles with RMAN"

• Backup and recovery enhancements in Oracle Enterprise Manager

  Enterprise Manager includes an interface for Data Recovery Advisor.

  See Also:

  Oracle Database 2 Day DBA for details about Enterprise Manager enhancements related to backup and recovery

• Oracle Flashback Transaction Backout

  You can reverse a transaction. Oracle Database determines the dependencies between transactions and in effect creates a compensating transaction that reverses the unwanted changes. The database rewinds to a state as if the transaction, and any transactions that could be dependent on it, never occurred.

  See Also:

  Oracle Database Advanced Application Developer's Guide to learn how to use this feature

• Flashback data archive

  A flashback data archive enables the database to automatically track and store all transactional changes to a table for the duration of its lifetime. Thus, you do not need to build this functionality into database applications.

  A flashback data archive is especially useful for compliance, audit reports, data analysis, and DSS (Decision Support Systems). You can use some of the logical flashback features with a flashback data archive to access data from far in the past.

  See Also:

  Oracle Database Advanced Application Developer's Guide to learn how to configure and use a flashback data archive, and "Oracle Flashback Technology" for an overview of flashback features

• Improved media recovery performance for databases on SMP systems

  Media recovery of databases on symmetric multiprocessing (SMP) computers is now faster. The performance improvements include the following:

  • More parallelism

  • More efficient asynchronous redo read, parse, and apply

  • Fewer synchronization points in the parallel apply algorithm

  • The media recovery checkpoint at a redo log boundary no longer blocks the apply of the next log

  No configuration is necessary, although you can use new parallel recovery wait events for tuning if the default apply rate is not satisfactory.

  See Also:

  Oracle Database Reference to learn about Oracle wait events