In this Document
  Purpose
  Scope and Application
  Rman Enhancements In Oracle 11g.
     Improved handling of long-term backups
     Backup failover for archived redo logs in the flash recovery area
     Archived log deletion policy enhancements
     Network-enabled database duplication without backups
     Rman Duplicate without target and recovery catalog connections.
     Virtual Private Catalog
     Import Catalog command
     Multisection backups
     Undo Optimization
     Improved block media recovery performance
     Improved block corruption detection
     Faster backup compression
     Block change tracking support for standby databases
     Backup of read-only transportable tablespaces
     RMAN Tablespace Point-in-Time Recovery (TSPITR) Enhancements
     SET NEWNAME Options
     CONVERT DATABASE Option
     Expanded Backup Compression Levels
     INCARNATION Specifier Enhancement
     To Destination Syntax

Applies to:

Oracle Server - Enterprise Edition - Version: 11.1.0.6 to 11.2.0.1.0 - Release: 11.1 to 11.2
Information in this document applies to any platform.

Purpose

This article provides us the list of RMAN enhancements in Oracle 11g release.

Scope and Application

This article is intended for DBA's having strong RMAN knowledge.

Rman Enhancements In Oracle 11g.

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.

Prior to Oracle Database 11g, if you needed to preserve an online backup for a specified amount of time, RMAN assumed you might want to perform. point-in-time recovery for any time within that period and RMAN retained all the archived logs for that time period unless you specified NOLOGS. However, you may have a requirement to simply keep the backup (and what is necessary to keep it consistent and recoverable) for a specified amount of time.

From oracle 11g for the backup with keep option,RMAN includes the data files, archived log files (only those needed to recover an online backup), the relevant autobackup files, and spfiles. All these files must go to the same media family (or group of tapes) and have the same KEEP attributes.

The archival backup provides the RESTORE POINT clause which creates a Ã¢Â€ÂœconsistencyÃ¢Â€Â point in the control file. It assigns a name to a specific SCN. The SCN is captured just after the data-file backup completes. The archival backup can be restored and recovered for this point in time, enabling the database to be opened. In contrast, the UNTIL TIME clause specifies the date until which the backup must be kept.

Example
======
RMAN> backup database
2> tag monthly_backup
3> format 'd:\backup_%U'
4> keep forever
5> restore point y2007May;

Starting backup at 01-JUN-2010 19:57:58
current log archived

using channel ORA_DISK_1
backup will never be obsolete
archived logs required to recover from this backup will be backed up
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00001 name=D:\DATABASE\ORA11G\ORA11G\SYSTEM01.
input datafile file number=00002 name=D:\DATABASE\ORA11G\ORA11G\SYSAUX01.
input datafile file number=00004 name=D:\DATABASE\ORA11G\ORA11G\USERS01.D
input datafile file number=00003 name=D:\DATABASE\ORA11G\ORA11G\UNDOTBS01
channel ORA_DISK_1: starting piece 1 at 01-JUN-2010 19:58:04
channel ORA_DISK_1: finished piece 1 at 01-JUN-2010 20:01:00
piece handle=D:\BACKUP_06LF5PAC_1_1 tag=MONTHLY_BACKUP comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:02:56

using channel ORA_DISK_1
backup will never be obsolete
archived logs required to recover from this backup will be backed up
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
including current SPFILE in backup set
channel ORA_DISK_1: starting piece 1 at 01-JUN-2010 20:01:00
channel ORA_DISK_1: finished piece 1 at 01-JUN-2010 20:01:03
piece handle=D:\BACKUP_07LF5PFS_1_1 tag=MONTHLY_BACKUP comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:03

current log archived
using channel ORA_DISK_1
backup will never be obsolete
archived logs required to recover from this backup will be backed up
channel ORA_DISK_1: starting archived log backup set
channel ORA_DISK_1: specifying archived log(s) in backup set
input archived log thread=1 sequence=48 RECID=47 STAMP=720561667
channel ORA_DISK_1: starting piece 1 at 01-JUN-2010 20:01:12
channel ORA_DISK_1: finished piece 1 at 01-JUN-2010 20:01:15
piece handle=D:\BACKUP_08LF5PG7_1_1 tag=MONTHLY_BACKUP comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:03

using channel ORA_DISK_1
backup will never be obsolete
archived logs required to recover from this backup will be backed up
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
including current control file in backup set
channel ORA_DISK_1: starting piece 1 at 01-JUN-2010 20:01:24
channel ORA_DISK_1: finished piece 1 at 01-JUN-2010 20:01:31
piece handle=D:\BACKUP_09LF5PGC_1_1 tag=MONTHLY_BACKUP comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:07
Finished backup at 01-JUN-2010 20:01:31

Backup failover for archived redo logs in the flash recovery area

The 11g Archived Redo Log Failover feature enables RMAN to complete a backup even when some archiving destinations are missing logs or contain logs with corrupt blocks where a local archivelog destination is configured alongside the FRA. If at least one log corresponding to a given log sequence and thread is available in the flash recovery area or any of the archiving destinations, then RMAN tries to back it up. If RMAN finds a corrupt block in a log file during backup, it searches other destinations for a copy of that log without corrupt blocks.

The following article explains this feature in detail.

Note 464860.1 11g New Features: 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.

Examples
=======
RMAN> configure archivelog deletion policy to applied on standby;
RMAN> configure archivelog deletion policy to applied on standby;
RMAN> configure archivelog deletion policy to backed up 2 times to disk;

Network-enabled database duplication without backups

From Oracle 11g release 1 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.

Please refer the following article for good understanding of active duplicate operation.

Note 452868.1 RMAN 'Duplicate Database' Feature in 11G

Rman Duplicate without target and recovery catalog connections.

Oracle 11g release 2 provides the leverage of creating a duplicate database without connecting to the target database and recovery catalog.

Please refer the following article for good understanding of this feature.

For disk backups:

Note 1113713.1 Creation Of Rman Duplicate Without Target And Recovery Catalog Connection.

For disk and tape backups:

Note 1375864.1 Perform. Backup Based RMAN DUPLICATE Without Connecting To Target Database For Both Disk & Tape Backups

Virtual Private Catalog

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.

The owner of a centralized recovery catalog, which is also called the base recovery catalog, cangrant or revoke restricted access to the catalog to other database users. All metadata is stored in the base catalog schema.Each restricted user has full read-write access to his or her own metadata, which is called a virtual private catalog.

Import Catalog command

With the IMPORT CATALOG command, you can import the metadata from one recovery catalog schema into a different catalog schema. If you created catalog schemas of different versions to store metadata for multiple target databases, then this command enables you to maintain a single catalog schema for all databases.

The following article explains about this feature.

RMAN 11G Import Catalog

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.

The following article explains about this feature.

RMAN 11G MultiSection Backups

Undo Optimization

In backup undo optimization, RMAN excludes undo not needed for recovery from the backup, that is, for transactions which have already been committed. For example, a user updates the salaries table in the USERS tablespace. The change is written to the USERS tablespace, while the before image of the data is written to the UNDO tablespace. The user commits. A subsequent RMAN backup of the UNDO tablespace does not include the undo information for the salary changes as a restore of this backup would already have the committed data.

The following article explains about this feature.

Note.406468.1 RMAN 11G RMAN UNDO backup optimization

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.

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.Improved block corruption detection

You can use the VALIDATE command to manually check for physical and logical corruptions in database files. This command performs the same types of checks as BACKUP VALIDATE, but VALIDATE can check a larger selection of objects. For example, you can validate individual blocks with the VALIDATE DATAFILE ... BLOCK command.

Examples
========
RMAN > validate database;
RMAN > validate backupset 10;
RMAN > validate datafile 1 block 10;

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. ZLIB requires the Oracle Advanced Compression option. You can use the CONFIGURE COMPRESSION ALGORITHM command to choose between BZIP2 (default) and ZLIB for RMAN backups.

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.

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.

RMAN Tablespace Point-in-Time Recovery (TSPITR) Enhancements

From oracle 11g release 2 TSPITR can be used to recover a dropped tablespace and to recover to a point-in-time before the tablespace is brought online. The latter TSPITR operation can be repeated as many times as necessary.

The steps to perform. this operation remain the same as they were in previous release but the time/scn/sequence which you provide in the until clause should be prior to the tablespace drop.

SET NEWNAME Options

The SET NEWNAME command is more powerful and easier to use. You can use this command on a specific tablespace or on all datafiles and tempfiles. You can also change the names for multiple files in the database.

The oracle 11g release 2 provides the the following options for set newname.

1.SET NEWNAME FOR DATAFILE and SET NEWNAME FOR TEMPFILE
2.SET NEWNAME FOR TABLESPACE
3.SET NEWNAME FOR DATABASE

The following Substitution Variables are introduced for SET NEWNAME in oracle 11g release 2.

%b Specifies the file name stripped of directory paths. For example, if a datafile is named
    /oradata/prod/financial.dbf, then %b results in financial.dbf.
%f Specifies the absolute file number of the datafile for which the new name is generated. For
    example, if datafile 2 is duplicated, then %f generates the value 2.
%I Specifies the DBID.
%N Specifies the tablespace name.
%U Specifies the following format: data-D-%d_id-%I_TS-%N_FNO-%f.

Here are a few examples which depict the usage of these variables.

1) If you want to restore the datafiles of a tablespace to a different location and retain the name file names, The following command can be used.

RMAN > run
{
set newname for tablespace users to '/home/oradata/%b'
restore tablespace;
}

2) If you want to restore the entire database to a different location and you need the file names to be uniquely identified by their absolute filenumber,dbid and tablespace name then you can use the following syntax.

RMAN > run
{
set newname for database to '/home/oradata/%U';
restore database;
}

The resulting filename will be something like: /home/oradata/data-D-PROD_id-87650928_TS-SYSTEM_FNO-1

CONVERT DATABASE Option

A new option, SKIP UNNECESSARY DATAFILES, is now supported for the CONVERT DATABASE command. When the option is invoked, the only datafiles that are converted are those that require RMAN processing during transfer between the specified platforms. The rest of the datafiles can be used by the destination database via shared storage or pathname. By skipping the conversion of datafiles that do not contain undo segments, overall database transport time can be reduced. You can use this option when converting at the source or converting ON DESTINATION PLATFORM.

Expanded Backup Compression Levels

RMAN now offers a wider range of compression levels with the Advanced Compression Option (ACO). Although the existing BASIC compression option may be suitable for most environments, you may want to explore the ACO backup compression levels (LOW, MEDIUM, and HIGH) to achieve better performance or higher compression ratios.

If you have enabled the Oracle Database 11g Release 2 Advanced Compression Option, you can choose from the following compression levels:

HIGH    Best suited for backups over slower networks where the limiting factor is network speed
MEDIUM   Recommended for most environments. Good combination of compression ratios and speed
LOW          Least impact on backup throughput and suited for environments where CPU resources are the limiting factor.

Example
======
RMAN> CONFIGURE COMPRESSION ALGORITHM 'HIGH';

INCARNATION Specifier Enhancement

Incarnations may now be used to further qualify archived redo log ranges for the BACKUP, RESTORE, and LIST commands. You can now specify ALL or CURRENT or designate a particular incarnation number when listing ranges of archived logs.

From oracle 11g release 2 the archivelogs can be listed,backed up and restored based on the incarnation to which they belong. This can be achieved by using the key word "incarnation all/current/integer". The incarnation integer is nothing but the Inc Key obtained from "list incarnation" output.

Examples
=======
RMAN> list archivelog sequence between 10 and 20 incarnation 2;
RMAN> backup archivelog sequence between 10 and 20 incarnation 1;
RMAN> restore archivelog sequence between 10 and 20 incarnation 1;

To Destination Syntax

TO DESTINATION syntax has been added to the BACKUP command. This addition allows you to designate a specific directory location for backups to disk and is primarily for use with the BACKUP RECOVERY AREA command. If backup optimization is enabled, then RMAN only skips backups of identical files that reside in the directory location specified by the TO DESTINATION option.

Examples
========
RMAN> backup tablespace users to destination 'd:\database';
RMAN> backup recovery area to destination 'd:\database';

ITPub博客

Rman Enhancements In Oracle 11g. [ID 1115423.1]