[轉載] RMAN Enhancements in Oracle Database 11g

RMAN Enhancements in Oracle Database 11g

This article provides an overview of all the RMAN enhancements in Oracle Database 11g

· Improved Integration with Data Guard

· Improved Handling of Long-Term Backups

· Archived Redo Log Failover

· Archived Log Deletion Policy Enhancements

· Network-Enabled Database Duplication Without Backups

· Recovery Catalog Enhancements

· Virtual Private Catalog

· IMPORT CATALOG

· Multisection Backups

· Undo Optimization

· Improved Block Media Recovery Performance

· Faster Backup Compression

· Block Change Tracking Support for Standby Databases

· Improved Scripting with RMAN Substitution Variables

· Integration with VSS-Enabled Applications

· Lost Write Detection

· Backup of Read-Only Transportable Tablespaces

· Improved Media Recovery Performance for Databases on SMP Systems

Related Articles:

· Data Recovery Advisor

· Improved Block Corruption Detection (VALIDATE)

· Backup and Recovery Enhancements in Oracle Enterprise Manager

· Flashback Transaction

· Flashback Data Archive (Oracle Total Recall)

Improved Integration with Data Guard

When RMAN is in a Data Guard environment, the CONFIGURE command allows you to register and configure settings for all physical databases. The databases are distinguished using the DB_UNIQUE_NAME initialization parameter.

A catalog must be connected for RMAN to work properly in a Data Guard environment. Using the SET DBID command allows you to configure a standby database even when RMAN is not connected to the target database. This means a standby database configuration can be created before the database itself exists.

The CONFIGURE DB_UNIQUE_NAME command defines a connection to a physical standby database. This implicitly registers the new database, as does the first connection as TARGET to a new standby database. The CONFIGURE ... FOR DB_UNIQUE_NAME configures settings for the specified database or for all databases in the environment.

# Defines a new connection to a physical standby database.

CONFIGURE DB_UNIQUE_NAME 'STANDBY' CONNECT IDENTIFIER 'STANDBY';

# Configures settings for the physical standby database.

CONFIGURE DEFAULT DEVICE TYPE TO DISK FOR DB_UNIQUE_NAME 'STANDBY';

# Configures settings for the all databases.

CONFIGURE DEFAULT DEVICE TYPE TO DISK FOR DB_UNIQUE_NAME ALL;

The SHOW ... FOR DB_UNIQUE_NAME command shows the configuration for a specific standby database or all known databases.

# Show configuration of a specific standby database.

SHOW ALL FOR DB_UNIQUE_NAME 'STANDBY';

# Show configuration of all databases.

SHOW RETENTION POLICY FOR DB_UNIQUE_NAME ALL;

Improved Handling of Long-Term Backups

The BACKUP command includes a KEEP option to override the default retention policy and create an all-inclusive backup. The backups are considered all-inclusive because they contain all files necessary to restore and recover the database. This allows for long term backups, also known as archival backups.

In previous versions, an archival backup would include all archived redo logs present. Oracle 11g has improved this situation by retaining only the archived redo log files needed to make the backup consistent. This may represent a substantial space saving.

Archived Redo Log Failover

When backing up archived redo logs RMAN only includes a single copy of each archived redo log, regardless of how many archive log destinations are being written to. The Oracle 11g archived redo log failover feature allows RMAN to complete a backup provided at least one valid copy of each archived redo log is present in one of the specified archive destinations. If RMAN finds a log file containing corrupt blocks, it searches the other archive destinations for a valid copy to back up.

Archived Log Deletion Policy Enhancements

The archived log deletion policy of Oracle 11g has been extended to give greater flexibility and protection in a Data Guard environment. The Oracle 10g and Oracle 11g syntax is displayed below.

# Oracle 10g Syntax.

CONFIGURE ARCHIVELOG DELETION POLICY {CLEAR | TO {APPLIED ON STANDBY | NONE}}

# Oracle 11g Syntax.

ARCHIVELOG DELETION POLICY {CLEAR | TO {APPLIED ON [ALL] STANDBY |

BACKED UP integer TIMES TO DEVICE TYPE deviceSpecifier |

NONE | SHIPPED TO [ALL] STANDBY}

[ {APPLIED ON [ALL] STANDBY | BACKED UP integer TIMES TO DEVICE TYPE deviceSpecifier |

NONE | SHIPPED TO [ALL] STANDBY}]...}

The extended syntax allows for configurations where logs are eligible for deletion only after being applied to, or transferred to, one or more standby database destinations.

Network-Enabled Database Duplication Without Backups

Prior to Oracle 11g, an RMAN database duplication to a different host required copies of the relevant backups and archived redo logs to be manually copied to the remote server. Oracle 11g allows active database duplication, so there is no need for the presence of pre-existing database backups and manual copying of files.

Once the DUPLICATE command is initiated, RMAN automatically performs the following steps:

· Copies the spfile to the destination server.

· Starts the auxiliary instance with the spfile.

· Copies the relevant database files and archived redo logs over the network to the destination server.

· Recovers the database.

· Opens the database with the RESETLOGS option.

This method is suitable for creating a duplicate database or physical standby database.

Recovery Catalog Enhancements

Virtual Private Catalog

Oracle 11g has introduced the concept of the virtual private catalog, which is a subset of the base recovery catalog. The owner of the base recovery catalog can now GRANT or REVOKE access on individual databases to other users in the same database. To create a virtual private catalog, you must log in to SQL*Plus as SYS and create a database user with the RECOVERY_CATALOG_OWNER role.

CREATE USER vpc1 IDENTIFIED BY vpc1 QUOTA UNLIMITED ON users;

GRANT RECOVERY_CATALOG_OWNER TO vpc1;

Next, log into RMAN using the base recovery catalog owner and grant access on the relevant databases to the virtual private catalog user. The database can be specified using the database name or the DBID.

$ rman

RMAN> CONNECT CATALOG rman/rman;

RMAN> GRANT CATALOG FOR DATABASE db11g TO vpc1;

Grant succeeded.

RMAN>

The following grant will allow the virtual private catalog to register new target databases.

RMAN> GRANT REGISTER DATABASE TO vpc1;

Grant succeeded.

RMAN>

Next, log into RMAN using the virtual private catalog owner and issue the CREATE VIRTUAL CATALOG command.

$ rman

RMAN> CONNECT CATALOG vpc1/vpc1;

RMAN> CREATE VIRTUAL CATALOG;

found eligible base catalog owned by RMAN

created virtual catalog against base catalog owned by RMAN

RMAN>

If the catalog is to be used for releases earlier than Oracle 11g, log into SQL*Plus as the virtual private catalog owner and run the following procedure, where "rman" represents the name of the base catalog owner.

SQL> CONN vpc1/vpc1

Connected.

SQL> EXEC rman.DBMS_RCVCAT.CREATE_VIRTUAL_CATALOG;

PL/SQL procedure successfully completed.

SQL>

To revoke privileges from a virtual private catalog, log into RMAN as the base catalog owner and revoke access to the relevant databases as follows.

REVOKE CATALOG FOR DATABASE db11g FROM vpc1;

# Prevent it from registering new targets if necessary.

REVOKE REGISTER DATABASE FROM vpc1;

The method used to drop the virtual private catalog varies depending on the database versions of the targets that were registered with it. If only 11g targets were registered, log on to RMAN as the virtual private catalog owner and issue the

$ rman

RMAN> CONNECT CATALOG vpc1/vpc1;

RMAN> DROP CATALOG;

If targets prior to 11g were registered, connect to SQL*Plus as the virtual private catalog owner and run the following procedure, where "rman" represents the name of the base catalog owner.

SQL> CONN vpc1/vpc1

Connected.

SQL> EXEC rman.DBMS_RCVCAT.DROP_VIRTUAL_CATALOG;

PL/SQL procedure successfully completed.

SQL>

You are now safe to drop the virtual private catalog user.

SQL> CONN / AS SYSDBA

Connected.

SQL> DROP USER vpc1 CASCADE;

User dropped.

SQL>

IMPORT CATALOG

Oracle 11g has also introduced the IMPORT CATALOG command to allow recovery catalogs to be merged or moved. Connect to the destination catalog and issue the IMPORT CATALOG command, specifying the owner of the source catalog.

$ rman

RMAN> CONNECT CATALOG rman2/rman2

RMAN> IMPORT CATALOG rman@db11g;

Starting import catalog at 07-JAN-08

source recovery catalog database Password:

connected to source recovery catalog database

import validation complete

database unregistered from the source recovery catalog

Finished import catalog at 07-JAN-08

RMAN>

Each target imported is unregistered from the source catalog. The import can be limited to a subset of the catalog by specifying the DBID or DB_NAME of each target to import.

RMAN> IMPORT CATALOG rman@db11g DBID=1423241, 1423242;

RMAN> IMPORT CATALOG rman@db11g DB_NAME=prod3, prod4;

The version of the source catalog must match that of the RMAN executable for the import to be successful.

To move an entire catalog to a new server, simply create a user on the new server to act as the catalog owner, create a catalog and import the contents of the existing catalog into it.

$ sqlplus / as sysdba

SQL> CREATE USER rman2 IDENTIFIED BY rman2 QUOTA UNLIMITED ON rman_ts;

SQL> GRANT RECOVERY_CATALOG_OWNER TO rman2;

SQL> EXIT;

$ rman catalog=rman2/rman2

RMAN> CREATE CATALOG;

RMAN> IMPORT CATALOG rman@db11g;

Multisection Backups

A file section is defined as a contiguous range of blocks from a single file. The SECTION SIZE parameter in the BACKUP command tells RMAN to create a backup set where each backup piece contains the blocks from one file section, allowing the backup of large files to be parallelized across multiple channels.

The following example of a multisection backup sets the parallelism to 4, allowing a tablespace with a single 1000M datafile to be backed up in 4x250M sections.

# One-off configuration of device type and parallelism.

CONFIGURE DEVICE TYPE sbt PARALLELISM 4;

CONFIGURE DEFAULT DEVICE TYPE TO sbt;

# Backup large tablespace in 4 sections.

RUN {

BACKUP SECTION SIZE 250M TABLESPACE my_1000M_ts;

}

Some points to remember about multisection backups include:

· If the section size is larger than the file size, RMAN does not use a multisection backup for the file.

· If the section size is so small that more than 256 sections would be produced, RMAN increases the section size such that 256 sections will be created.

· SECTION SIZE and MAXPIECESIZE cannot be used together.

· A backup set never contains a partial datafile, regardless of whether or not it is a multisection backup.

Undo Optimization

The BACKUP command no longer backs up undo that is not needed for recovery. As the majority of the undo tablespace is filled with undo generated for transactions that have subsequently been committed, this can represent a substantial saving.

This functionality is not configurable. It is not affected by the CONFIGURE BACKUP OPTIMIZATION {ON | OFF} command.

Improved Block Media Recovery Performance

If flashback logs are present, RMAN will use these in preference to backups during block media recovery (BMR), which can significantly improve BMR speed.

Faster Backup Compression

RMAN now supports the ZLIB binary compression algorithm as part of the Oracle Advanced Compression option. The ZLIB algorithm is optimized for CPU efficiency, but produces larger zip files than the BZIP2 algorithm available previously, which is optimized for compression. The choice of compression algorithm is set using the CONFIGURE command.

CONFIGURE COMPRESSION ALGORITHM 'ZLIB';

CONFIGURE COMPRESSION ALGORITHM 'BZIP2';

To perform a compressed backup using the ZLIB algorithm you might do something like this.

# One-off configuration.

CONFIGURE COMPRESSION ALGORITHM 'ZLIB';

CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO COMPRESSED BACKUPSET;

# Backup.

BACKUP DATABASE PLUS ARCHIVELOG;

Block Change Tracking Support for Standby Databases

Block change tracking is now supported on physical standby databases, which in turn means fast incremental backups are now possible on standby databases.

Improved Scripting with RMAN Substitution Variables

Substitution variables can now be used in RMAN command scripts in a similar manner to SQL*Plus scripts. For example, the following command script requires a tag name to be entered for each backup run.

CONNECT TARGET /

BACKUP DATABASE TAG '&1';

BACKUP ARCHIVELOG ALL TAG '&2';

EXIT;

Notice the "&1" and "&2" placeholders. Assuming this were saved with a filename of "/scripts/backup.cmd", it might be called with the following syntax.

$ rman @'/tmp/backup.cmd' USING DB_20070108 ARCH_20070108

Notice the use of the USING keyword, which accepts a space-separated list of values that are substituted for the placeholders.

Integration with VSS-Enabled Applications

The Volume Shadow Copy Service (VSS) infrastructure on Windows allows VS enabled applications to make a shadow copy of open files on Windows servers. The Oracle VSS writer integrates with VSS-enabled software and storage systems to back up and restore an Oracle database.

Lost Write Detection

A lost write happens when Oracle writes a block to disk and the I/O subsystem signals the write is complete, even though it isn't. When the block is next read the stale data is returned, which can result in data corruption.

The DB_LOST_WRITE_PROTECT parameter can provide protection against lost writes depending on the value set:

· NONE - No lost write protection. The default.

· TYPICAL - The instance logs buffer cache reads for read/write tablespaces in the redo log. This has a approximate overhead of 5-10% in a RAC environment.

· FULL - The instance logs buffer cache reads for read/write and read-only tablespaces in the redo log. This has a approximate overhead of 20% in a RAC environment.

Lost write detection is most effective in Data Guard environments. Once the primary and standby databases are protected, the SCNs of blocks applied to the standby database are compared to the SCN logged in the redo logs. If the SCN on the primary database is smaller than the SCN on the standby database, a lost write on the primary database has occurred and is signaled with an external error (ORA-752). At this point you should failover to the standby database. If the SCN on the primary database is bigger than on the standby database, a lost write on the standby database has occured and is signalled with an internal error (ORA-600 [3020]). At this point the standby database should be recreated.

Lost write protection can also be used in normal databases, although there is no signal that the lost write has occurred. If you suspect a problem due to inconsistent data, you must recovery the database to the SCN of the stale block from a backup taken before the suspected problem occurred. This restore operation will generate the lost write error (ORA-752). If the error is detected during a recovery, you have no alternative but to open the database with the RESETLOGS option. All data after this point is lost.

Backup of Read-Only Transportable Tablespaces

In previous versions of Oracle, transportable tablespaces could only be backed up if they were in read/write mode. It is now possible to backup read-only transportable tablespaces.

Improved Media Recovery Performance for Databases on SMP Systems

Several performance improvements have been made to media recovery on symmetric multiprocessing (SMP) systems with no extra configuration steps, including:

· Greater 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.