4 Creating RMAN Backups

Search in book...
Toggle Font Controls
Create new playlist

Name your new playlist

Playlist description (optional)
Sign In

Email address

Password

Forgot Password?

or

Continue with Facebook

Continue with Google
Sign Up

Full Name

Email address

Confirm Email Address

Password

or

Continue with Facebook

Continue with Google

4
Creating RMAN Backups

CERTIFICATION OBJECTIVES

4.01 Create image file backups

4.02 Create a whole database backup

4.03 Enable fast incremental backup

4.04 Create duplex backup and back up backup sets

4.05 Create an archival backup for long-term retention

4.06 Create a multisection, compressed, and encrypted backup

4.07 Report on and maintain backups

Two-Minute Drill

Self Test

This chapter offers what you’ve all been waiting for: You’ll learn to create backups using Recovery Manager (RMAN). Needless to say, you can create many different types of backups using RMAN and leverage the many features new to Oracle Database 11g to make your backups smaller and less time-consuming.

RMAN supports a number of backup methods that can be used according to your availability needs, the desired size of your recovery window, and the amount of downtime you can endure while the database or a part of the database is involved in a recovery operation. You’ll learn more about configuring and using recovery in Chapter 5.

First, you’ll learn how to create image file backups—in other words, exact copies of your database’s datafiles. Even though you can make copies of your database files manually, RMAN provides a number of added benefits. You’ll also get an overview of the other types of RMAN backups: whole database backups, as well as whole database backups that you can use as part of an incremental backup strategy. RMAN has many features that can make an incremental backup run even faster, such as creating a block change tracking file to mark which datafile blocks have changed since the last backup.

Next, you’ll learn how to create an archival backup for long-term retention. Business requirements and recent changes to record-keeping and privacy laws demand a retention period for corporate data that is frequently beyond the configured RMAN retention policy. An RMAN archival backup gives you a consistent and simple snapshot of your database at a point in time in the past.

As of Oracle Database 11g, RMAN provides enhancements such as multisection backups for very large database (VLDB) environments. In previous versions of RMAN, a bigfile tablespace took a long time to back up because RMAN could only process the bigfile tablespace serially. In Oracle Database 11g, RMAN can back up large datafiles as a multisection backup, leveraging multiple output devices (multiple channels either to disk or tape) to dramatically reduce the time it takes to back up the datafile, among other advantages. RMAN’s alternative compression techniques and encryption methods further reduce backup size and make the backups unavailable to unauthorized parties by using standalone passwords or the database’s encryption wallet.

Finally, you’ll get a whirlwind tour of RMAN reporting capabilities. As a robust backup tool, RMAN has a wealth of commands and many useful data dictionary views. This makes it easy for you to identify the state and contents of your backups, either on the target database or in the repository itself.

Using RMAN to Create Backups

You’ll find very few reasons for not using RMAN as your main tool for managing backups. Following are some of the major features of RMAN, which are either unavailable with traditional backup methods or are limited by significant restrictions using traditional backup methods:

Skip unused blocks Blocks that have never been written to, such as blocks above the high water mark (HWM) in a table, are not backed up by RMAN when the backup is an RMAN backupset. Traditional backup methods have no way to know which blocks have been used.

Backup compression In addition to skipping blocks that have never been used, RMAN can also use one of two Oracle-specific binary compression modes to save space on the backup device. Although operating system–specific compression techniques are available with traditional backup methods, the compression algorithms used by RMAN are customized to maximize the compression for the typical kinds of data found in Oracle data blocks. Although a slight increase in CPU time is required during an RMAN compressed backup or recovery operation, the amount of media used for backup can be significantly reduced, as well as network bandwidth reduction if the backup is performed over the network. Multiple CPUs can be configured for an RMAN backup to help alleviate the compression overhead.

Open database backups Tablespace backups can be performed in RMAN without using the BEGIN/END BACKUP clause with ALTER TABLESPACE. Whether using RMAN or a traditional backup method, however, the database must be in ARCHIVELOG mode.

True incremental backups For any RMAN incremental backup, unchanged blocks since the last backup will not be written to the backup file. This saves a significant amount of disk space, I/O time, and CPU time. For restore and recovery operations, RMAN supports incrementally updated backups. Data blocks from an incremental backup are applied to a previous backup to potentially reduce the amount of time and number of files that need to be accessed to perform a recovery operation. You’ll see an example of an incrementally updated backup later in this chapter.

Block-level recovery To help avoid downtime during a recovery operation, RMAN supports block-level recovery for recovery operations that need to restore or repair only a small number of blocks identified as being corrupt during the backup operation. The rest of the tablespace and the objects within the tablespace can remain online while RMAN repairs the damaged blocks. The rows of a table not being repaired by RMAN are even available to applications and users. You’ll learn about block-level recovery in Chapter 5.

Multiple I/O channels During a backup or recovery operation, RMAN can utilize many I/O channels using separate operating system processes, thus performing concurrent I/O. Traditional backup methods, such as a Unix cp command or an Oracle export, are typically single-threaded operations.

Platform independence Backups written with RMAN commands are syntactically identical regardless of the hardware or software platform used. In other words, RMAN scripts are platform-independent. The only difference will be the media management channel configuration. If you don’t use RMAN, something like a Unix script containing lots of cp commands will not run at all if the backup script is migrated to a Windows platform.

Tape manager support All major enterprise backup systems are supported within RMAN by a third-party media management driver, which is provided by a tape backup vendor.

Cataloging A record of all RMAN backups is recorded in the target database control file and optionally in a recovery catalog stored in a different database. This makes restore and recovery operations relatively simple compared to manually tracking operating system–level backups using “copy" commands. The benefits and reviewed catalog configuration are discussed in Chapter 3.

Scripting capabilities RMAN scripts can be saved in a recovery catalog for retrieval during a backup session. The tight integration of the scripting language, the ease of maintaining scripts in RMAN, and the Oracle scheduling facility make RMAN a better choice compared to storing traditional operating system scripts in an operating system directory with the operating system’s native scheduling mechanisms.

Encrypted backups RMAN uses backup encryption integrated into Oracle Database 11g to store encrypted backups. Storing encrypted backups on tape requires the Advanced Security option.

In a few limited cases, a traditional backup method can have an advantage over RMAN. For example, RMAN does not support the backup of password files and other nondatabase files, such as tnsnames.ora, listener.ora, and sqlnet.ora. However, these files are relatively static in nature, and they can be easily backed up and restored using a traditional backup method, such as the Unix cp command.

CERTIFICATION OBJECTIVE 4.01
Create Image File Backups

RMAN supports a number of different backup methods. The choice of method depends on your availability needs, the desired size of your recovery window, and the amount of downtime you can endure while the database (or a part of the database) is involved in a recovery operation.

RMAN stores its backups in one of two formats: backupsets or image copies. This section highlights and defines the differences between the two, and more examples of each backup type are provided later in this chapter.

Creating Backupsets

A backupset is an object specific to RMAN; only RMAN can create and read backupsets. As you learned in Chapter 3, a backupset is a set of files called backup pieces that can be stored on a file system or on an Automatic Storage Management (ASM) disk. Each backup piece can contain one or more database file backups. All backupsets and pieces are recorded in the RMAN repository, the same as any other RMAN-initiated backup.

By default, any backups to disk default to a backupset backup type:

As a result, the following backup command does not need the AS BACKUPSET qualifier, but you can specify it anyway, especially if it’s in a global script that could be run in an RMAN session with different defaults:

The FORMAT clause can use substitution variables to differentiate backupsets by database, by piece, and so forth. Here are a few sample substitution variable types:

%d Database name

%e Archived log sequence number

%f Absolute file number

%F Combines the DBID, day, month, year, and sequence number, separated by dashes

%c Copy number for multiple copies in a duplexed backup

%I Database identifier (DBID)

%n Database name padded to eight characters

%p Piece number within the backupset

%s Backupset number

%t Backupset timestamp

%U System-generated unique filename (the default)

EXERCISE 4-1
Create a Compressed Backupset

In this exercise, you’ll create an RMAN backup to the directory /u06/backup that includes the database name, backupset number, a backupset timestamp, and a piece number within the backupset. You’ll create a second RMAN backup using the default backup location and backupset format.

1. Connect to the target database and the recovery catalog on the HR database:

2. Run the RMAN backup, and explicitly specify AS COMPRESSED BACKUPSET, even if this is already the default:

3. Run the RMAN backup again, this time backing up the SYSAUX tablespace and using the default location and format:

The FORMAT parameter can be provided in two other ways: in the ALLOCATE CHANNEL and as part of the CONFIGURE commands. The default FORMAT applies only to the control file autobackup as in this example:

Creating Image Copies

An image copy is an exact copy of a tablespace’s datafile, an archived redo log file, or a control file. Although you can use an operating system command to perform the copy, using the RMAN command BACKUP AS COPY provides the additional benefits of block verification and automatically recording the backup into the control file and the recovery catalog (if you have configured a recovery catalog). Another spin-off benefit to making image copies is that the copies can be used “asis” outside of RMAN if, for some reason, a recovery operation must occur outside of RMAN.

A restriction applies when you’re using image copies in that image copies can be written only to disk. This can turn out to be a benefit, however: Although disk space may be at a premium compared to tape storage, restoration time is considerably less because the file used for recovery is already on disk.

You can use a disk image copy in a recovery scenario using two different methods: using an RMAN command or a SQL command. If you are in RMAN, you use the SWITCH command. In the next example, you lose the disk containing the tablespace STAR_SCHEMA and you want to switch to a backup copy:

Alternatively, at the SQL prompt, you can use the ALTER DATABASE RENAME FILE command, as long as the tablespace containing the datafile is offline or the database is in MOUNT mode.

Finally, note that an image copy of a tablespace or archived redo log file contains all blocks in the tablespace or archived redo log file. An image copy of a datafile can be used as a full or incremental level 0 backup as long as you add the INCREMENTAL LEVEL 0 parameter:

CERTIFICATION OBJECTIVE 4.02
Create a Whole Database Backup

An RMAN backup can be one of five types:

A whole database backup

A full backup

An incremental level 0 backup

A differential incremental level 1 backup

A cumulative incremental level 1 backup

In the following sections you’ll learn the differences between these types of backups and how to perform them.

Whole Database Backups

A whole database backup includes a copy of all datafiles in the database plus the control file. You can also include archived redo log files and the server parameter file (SPFILE).

If your default backup device is disk, the following command will back up your database as image files, including all database files, the control file, all archived redo log files, and the SPFILE:

Even if CONTROLFILE AUTOBACKUP is OFF, RMAN backs up the current control file whenever datafile #1 is included in the backup. Therefore, backing up the entire database in a whole database backup includes datafile #1 and, as a result, backs up the control file. Additionally, setting CONTROLFILE AUTOBACKUP to ON results in no significant performance hit to any RMAN backup unless disk space is extremely tight and the control file is very large after many RMAN backups and a long control file retention period.

If you add the DELETE INPUT clause to the preceding BACKUP command, RMAN deletes the archived log files from all destinations after they are backed up. If you are using a flash recovery area, this clause is generally unnecessary, as RMAN automatically deletes obsolete files in the flash recovery area when space is running low.

Finally, you can back up a previous backup of a database (either image copies or backupset) to another location (such as tape) by using this command:

Full Backups

A full backup is different from a whole database backup. A full backup can consist of a single datafile or tablespace, while a whole database backup includes all datafiles in a database. For full backups of tablespaces or archived redo log files, RMAN copies all data blocks into a backupset; blocks that have never been used are skipped. For an image copy, all blocks are included whether or not they have been used.

A full backup of an individual database object is a logical subset of a whole database backup. When performing database recovery, RMAN may use a more recent full backup of a tablespace than the most recent backup piece, which RMAN uses from an older backup of a whole database backup. This is because a whole database backup is a snapshot of the entire database. You plug in a datafile and let the automated recovery process resynchronize between data in datafiles, redo log entries, and the control file.

You perform a full backup of an individual database object much like a whole database backup, except that you use the TABLESPACE keyword instead of the DATABASE keyword in the BACKUP command. This is because you are backing up tablespaces individually.

EXERCISE 4-2
Perform a Full Backup of Two Tablespaces

In this exercise, you’ll perform a full backup of the USERS and SYSAUX tablespaces in the same BACKUP command.

1. Connect to RMAN and run the BACKUP command with the tablespaces separated by commas:

Note that the control file and SPFILE are not included in this backup unless you have CONTROLFILE AUTOBACKUP set to ON or datafile #1 is included in the backup; by default, it is set to OFF, as in this example.

If you are using Oracle Enterprise Manager Database Control, you can perform an ad-hoc or scheduled full backup of a tablespace using a GUI tablespace, as you can see in Figure 4-1.

FIGURE 4-1 Performing a full backup of the USERS tablespace

A full backup cannot participate in an incremental backup strategy; in other words, a full backup stands alone regardless of other incremental backups you are performing for the same objects. You’ll see how to set up an incremental backup strategy in the next section.

Incremental Backups

As mentioned in Chapter 3, an incremental backup can be one of two types: level 0 or level 1. A level 0 incremental backup includes all blocks in the specified datafiles except for blocks that have never been used. In addition, a level 0 backup is physically identical to a full backup of the same datafiles, except that a full backup cannot be used in an incremental backup strategy—it stands alone. A level 1 backup can be one of two types: either a differential backup that backs up changed blocks since the last backup at level 0 or 1, or a cumulative backup that backs up all changed blocks since the last level 0 backup.

You use the following keywords in the RMAN BACKUP command to specify an incremental level 0 or level 1 backup:

You’ll learn how to set up an incremental backup strategy for the USERS tablespace in the following sections.

Level 0 Incremental Backups

A level 0 backup includes all blocks in a database object except for blocks that were never used above the HWM. Subsequent level 1 backups use the most recent level 0 backup as the base for comparison when identifying changed blocks.

How often you perform a level 0 backup depends on how much the database object, such as a tablespace, changes between backups. A tablespace containing tables that are completely replaced on a weekly basis would most likely have more frequent level 0 backups than a tablespace containing tables that your applications change infrequently—for example, only 5 percent of the table’s rows every week, but the changes might depend on the block distribution of those rows.

In this example, you perform the first level 0 backup of the USERS tablespace in your incremental backup strategy:

Subsequent level 1 backups will use this backup as the starting point for identifying changed blocks.

Differential Incremental Backups

A differential backup is the default type of incremental backup that backs up all changed blocks since the last level 0 or level 1 incremental backup. Again using the USERS tablespace, here’s how you perform an incremental backup:

Differential is the default incremental backup type. Unlike most Oracle commands that allow you to use a keyword that is the default, DIFFERENTIAL can not be specified for the RMAN BACKUP command.

Cumulative Incremental Backups

Cumulative incremental backups back up all changed blocks since the last level 0 incremental backup. You perform a cumulative incremental level 1 backup the same way that you perform a differential level 1 backup, except that you specify the CUMULATIVE keyword, as in this example:

The decision whether to use a cumulative or differential backup is based partly on where you want to spend the CPU cycles and how much disk space is available. Using cumulative backups means that each incremental backup will become progressively larger and take longer until another level 0 incremental backup is performed. This can be beneficial in that only two backupsets will be required during a restore and recovery operation. On the other hand, differential backups record only the changes since the last backup, so each backupset might be smaller or larger than the previous one, with no overlap in data blocks backed up. However, a restore and recovery operation can take longer if you have to restore from several backupsets instead of just two.

CERTIFICATION OBJECTIVE 4.03
Enable Fast Incremental Backup

Another way to improve the performance of incremental backups is to enable block change tracking. For a traditional incremental backup, RMAN must inspect every block of the tablespace or datafile to be backed up to see if the block has changed since the last backup. For a very large database, the time it takes to scan the blocks in the database can easily exceed the time it takes to perform the actual backup.

By enabling block change tracking, RMAN knows which blocks have changed within a datafile by using a change tracking file. Although a slight overhead is incurred in space usage and maintenance of the tracking file every time a block is changed, the trade-off is well worth it if frequent incremental backups are performed on the database.

Once block change tracking is enabled, RMAN can perform fast incremental backups. In addition, database recovery is faster because fewer changed blocks need to be applied to a restored datafile. The following sections explain how block change tracking works, show you how to enable block change tracking and fast incremental backups, and show you how to monitor how well block change tracking is working in your database.

Understanding Block Change Tracking

Once you create a block change tracking file for your database, the maintenance of the tracking file is automatic and transparent. The size of the tracking file is proportional to the size of your database, the number of instances if you have a Real Application Cluster (RAC) database, and the number of previous backups maintained in the block change tracking file. (Oracle maintains up to eight previous backups in the block change tracking file.) The first incremental level 0 backup reads every block in the datafile, and subsequent incremental level 1 backups use the block change tracking file.

Updates to the block change tracking file occur in parallel with redo generation to the online redo log files. Figure 4-2 shows a committed transaction in the SGA that both generates redo in the online redo log files, and is processed by the CTWR (Change Tracking Writer) process and recorded in the change tracking file.

FIGURE 4-2 Committed transactions and the change tracking file

Enabling Fast Incremental Backup

You enable or disable block change tracking with the ALTER DATABASE command. In its simplest form, the following command is used to create and enable block change tracking:

If you do not specify a filename for the tracking file, Oracle creates it in the location specified by the initialization parameter DB_CREATE_FILE_DEST as an Oracle Managed File (OMF). If you want to explicitly specify the name and location of the tracking file, use the USING FILE clause. This example creates a block change tracking file in the DATA disk group and enables block change tracking:

Since the tracking file now exists in an ASM disk group, you can discover its size and where it is located within the DATA disk group by using the asmcmd utility:

The next time a level 1 incremental backup is performed after an initial level 0 backup, RMAN will have to use only the contents of the file ctf.270.632356105 (an OMF-named file in the DW/CHANGETRACKING directory of the DATA disk group), to determine which blocks need to be backed up. The space needed for the block change tracking file is approximately 1/30,000 the size of the database.

You turn off block change tracking by using this command:

This ALTER DATABASE command drops the block change tracking file. If you re-create it later, you will have to create another level 0 incremental backup before RMAN can use the block change tracking file, which minimizes the number of blocks that have to be read for the next level 1 incremental backup.

Finally, you can rename the tracking file by using the same command you use to rename any database file: ALTER DATABASE RENAME. Your database must be in the MOUNT state to rename a tracking file.

EXERCISE 4-3
Relocate the Block Change Tracking File

In this exercise, you’ll locate the block change tracking file and move it to another file system on the same server.

1. Find the location of the current block change tracking file:

2. Shut down the database and restart it in MOUNT mode:

3. Relocate the existing block change tracking file to the new location using operating system commands; using SQL*Plus on most platforms, you can execute operating system commands from the SQL< prompt:

4. Change the location of the file in the target database control file:

5. Start the database:

6. Verify the new location of the block change tracking file:

If you cannot afford to have your database down, even for a few minutes, then the only alternative is to drop and re-create the block change tracking file at a new location while the database is open using the ALTER DATABASE [ENABLE|DISABLE] BLOCK CHANGE TRACKING command.

Monitoring Block Change Tracking

The dynamic performance view V$BLOCK_CHANGE_TRACKING contains the name and size of the block change tracking file plus the status of change tracking:

To see the benefits of block change tracking, you can use the following query on the dynamic performance view V$BACKUP_DATAFILE to calculate the percentage of blocks read and the number of blocks backed up during an incremental level 1 backup:

The dynamic performance view V$BACKUP_DATAFILE contains one row for each datafile backed up using RMAN. This query further refines the results to pick the backups that used block change tracking during an incremental level 1 backup.

CERTIFICATION OBJECTIVE 4.04
Create Duplex Backup and Back Up Backupsets

RMAN provides a number of options to make multiple copies of your backup simultaneously, to create backups of your existing backupsets, and to skip unnecessary backups of read-only tablespaces. Each of these topics is covered in the following sections along with relevant examples.

Creating Duplexed Backupsets

To make multiple backups of the same backupset simultaneously, you can configure RMAN to make up to four duplexed copies of each backup piece. As with most RMAN commands, you can specify a default value for the COPIES parameter using the CONFIGURE command, as in this example:

Duplexing has a few restrictions: You cannot duplex backups to the flash recovery area, and you cannot duplex image copies—only backupsets. For duplexed disk backups, you specify multiple locations for a backup using the FORMAT clause. You can specify multiple locations either in the BACKUP command or when setting default values for device type DISK in the CONFIGURE command.

In this example, you back up the USERS tablespace to two different disk locations simultaneously:

Note that even though you have the same format for each copy of the backupset, RMAN’s default format, %U, is a shorthand for %u_%p_%c. As you may remember from the discussion on RMAN substitution variables, %c translates to a copy number in a duplexed backup operation.

EXERCISE 4-4
Configuring Multiple Disk Locations for a Duplexed Disk Backup

In this exercise, you will use the RMAN CONFIGURE command to set the default disk locations for duplexed backups so you don’t have to specify FORMAT for each BACKUP operation to device type DISK.

1. Connect to RMAN and show the current RMAN default values:

2. Change the value for the DISK device type to include two backup locations and two copies as the default:

3. Perform a backup of the USERS tablespace and confirm that RMAN creates two copies of the backupset:

Creating Backups of Backupsets

One option for creating a second copy of a backup is to create a backup of existing backupsets. This is especially useful if you forgot to duplex a previous backup and you don’t want to perform a time-consuming backup again. If your backupsets are on disk (you cannot back up existing backupsets that are on tape), you can use the BACKUP . . . BACKUPSET command to copy all backupsets on one disk, to another disk, or to tape. This command copies all existing disk-based backupsets to the default tape device and channel:

If you want to keep recent backupsets on disk and older backupsets on tape, you can use the COMPLETED and DELETE INPUT options. In the following, example, all backupsets older than two weeks are backed up to tape and deleted from the disk:

Backing Up Read-Only Tablespaces

As you might expect, backing up a read-only tablespace needs to happen often enough to satisfy the retention period configured in RMAN. You can force RMAN to skip a read-only tablespace by using the SKIP READONLY option of the BACKUP command.

If you configured RMAN for backup optimization (covered in Chapter 3), RMAN backs up read-only tablespaces only when there are not enough backups of the tablespace to satisfy the retention policy.

CERTIFICATION OBJECTIVE 4.05
Create an Archival Backup for Long-term Retention

Archival backups, new to Oracle Database 11g, give you the flexibility to take a snapshot of the database and retain it indefinitely or for a specific period of time. The following sections explain how archival backups work, how to perform an archival backup, and how to manage archival backups using the CHANGE command.

Understanding Archival Backups

By default, RMAN keeps your backups and archived log files not only to satisfy the configured retention policy, but also to provide a mechanism to restore your database to any point in time between the backup and the present. RMAN uses a combination of full backups, incremental backups, and archived redo log files.

In certain situations, you may want only a snapshot of the database at a certain point in time for archival or regulatory purposes. This causes two complications with the default RMAN configuration: First, your snapshot will most likely fall outside of your retention policy, and you certainly don’t want your yearly database snapshot to disappear before the end of the week! Second, you don’t want RMAN to maintain one, two, or more years’ worth of archived redo log files if you are not going to restore your database to a point in time between the snapshot and the current time.

RMAN addresses the need for a database snapshot by supporting an archival backup. If you label a backup as an archival backup, RMAN does not consider the backup to be obsolete using the configured retention policy; instead, RMAN marks an archival backup as obsolete after the amount of time you specify. Alternatively, you can specify that RMAN keep the archival backup indefinitely.

You can use an archival backup to migrate a copy of the database to another system for testing purposes without affecting the retention policy of the original database. Once you have created the database on the test system, you can delete the archival backup.

Performing an Archival Backup

One restriction for archival backups is that you cannot use the flash recovery area to store an archival backup. If you have a flash recovery area configured, you will have to use the FORMAT parameter to specify an alternative disk location for the backup. Additionally, a tape device might be the best option for long-term storage of archival backups.

This example creates an archival backup to be retained for one year using the KEEP UNTIL clause:

Since the HR database has a flash recovery area defined, you use the FORMAT clause to specify a location in which to store the archival backup. Note also that RMAN backs up any archived logs, which would be required to use the backup in a possible future recovery scenario.

Alternatively, you can perform the same backup but retain it indefinitely:

Managing Archival Backups

In some situations, you might want to change the status of a backup. For example, you might want to change an archival backup’s retention period, change an archival backup to a standard backup, or change a consistent backup to an archival backup. As you might expect, you can use the CHANGE command to accomplish this task. Although the CHANGE command has many other uses (such as to change the availability of a backup or to change the priority of failures in the database), the CHANGE command in relation to archival backups is covered here.

This example changes the backup created earlier with the tag SAVEFOREVER to fall under the existing retention policy instead:

Depending on the retention policy and the other older or newer backups for this database, the backup could be deleted the next time RMAN starts. The backup could be retained longer if the configured retention policy needs this backup to fulfill the retention policy.

You can also use the CHANGE command to change all backups of a certain type. For example, if you want to remove the archive flag from all image copies of the database, you use the NOKEEP parameter:

CERTIFICATION OBJECTIVE 4.06
Create a Multisection, Compressed, and Encrypted Backup

In previous versions of RMAN (before Oracle Database 11g), using bigfile tablespaces had one big advantage and one big disadvantage. The big advantage was that you could have a database with a much larger size than in previous versions of Oracle (up to 1022 bigfile tablespaces of 128 terabytes each). The big disadvantage was that backing up a single bigfile tablespace took a long time because RMAN could back up a bigfile tablespace only using a single channel. In general, backing up four 32TB datafiles in parallel took less time than backing up a single 128TB datafile. As a result, some organizations (with a lot of data) were somewhat restricted to how big they could make their bigfile tablespaces.

As of Oracle Database 11g, RMAN solves the problem of backing up large bigfile tablespaces by supporting multisection backups. A multisection backup produces a multipiece backupset from a single datafile and uses several channels, to disk or tape, to back up each piece of the datafile in parallel.

This section shows you not only how to create a multisection backup, but also how to compress your backups with new compression algorithms. It also examines how to ensure the privacy of the data in your backup by encrypting backups using two different methods.

Creating a Multisection Backup

Creating a multisection backup is easy, but you must specify the section size with each BACKUP command. In addition, you can run the RMAN VALIDATE command by section. New data dictionary views, both the V$ and RC_ views, help you to identify which backups are multisection and how many blocks are in each section of a multisection backup.

Specifying the Section Size

To create a multisection backup, you add the SECTION SIZE parameter to the BACKUP command. The section size can be specified in kilobytes, megabytes, or gigabytes. Here is the general syntax for specifying a multisection backup:

In this example HR database, the USERS tablespace is approximately 25MB, and we want to back it up with a section size of 10MB:

This backup created three backup pieces: the first two of 10MB each, and the third piece approximately 5MB, which is the remainder of the datafile.

Don’t use a high value for parallelism in your multisection backups to back up a large file on a small number of disks. The I/O contention of multiple RMAN threads accessing the same disk will erase any time savings gained by using a high value for parallelism.

Validating a Backup with a Section Size

You can also use the SECTION SIZE parameter with the VALIDATE command. The benefits of parallel operations for datafile block validation are the same as the benefits of using the BACKUP command: It will take you significantly less time to ensure that a datafile’s blocks are readable and have valid checksums. This example validates the datafile backed up in the previous section:

Multisection Data Dictionary Views

The views V$BACKUP_SET and RC_BACKUP_SET have a MULTI_SECTION column that indicates whether the backup is a multisection backup. Similarly, the V$BACKUP_DATAFILE and RC_BACKUP_DATAFILE views have a SECTION_SIZE column that indicates the number of blocks in each piece of a multisection backup. Remember that the V$ views exist on the target database and the RC_ views exist on the recovery catalog database.

Compressing Backups

In addition to skipping unused blocks during a backup, RMAN can also apply one of two compression methods to the used blocks in a backup when you specify the COMPRESSED parameter: BZIP2 or ZLIB. By default, RMAN uses BZIP2 as follows:

The ZLIB algorithm is significantly faster than BZIP2 but doesn’t compress the backup as much. In addition, it can be used only if you set the COMPATIBLE initialization parameter to 11.1.0 or higher.

The BZIP2 algorithm, as you might expect, creates much smaller backups but requires more CPU time to compress the blocks. If not too many other server processes are demanding CPU resources when your backups run, use ZLIB or BZIP2. On the other hand, if a lot of disk space is available and the network path from the database to your backup location is not congested, it might take less time overall not to use compression.

Regardless of what compression method you use, restoring a compressed backup requires no knowledge of the compression method used during the original backup. RMAN automatically detects the compression method used and decompresses accordingly.

Encrypting Backups

To ensure the security and privacy of your backups, you can encrypt them in one of three ways: via transparent encryption, password encryption, or dual mode encryption. By default, encryption is turned off:

In the following sections, you’ll learn how to enable each type of encryption.

Using Transparent Encryption

You can set transparent (wallet-based) encryption as the default RMAN encryption method using the CONFIGURE command as follows:

Keep in mind that your database wallet must be open as well. If it is not open, you might think that everything is going as planned—until the encryption process attempts to start. This is shown by the backup failure error message in the following output:

As you might expect, even if transparent encryption is not the default, you can turn it on just for the duration of a single backup. As in the previous example, the database wallet must be open. Here is an example:

To restore or recover from an encrypted backup, the database wallet must be open and either the encryption default must be ON or you must use SET ENCRYPTION ON before the recovery operation.

Using Password Encryption

To enable password encryption for a specific backup, use the SET ENCRYPTION command as follows:

Password encryption is inherently less secure and reliable than transparent (wallet-based) encryption, because a password can be lost, forgotten, or intercepted easily. Use password encryption only when backups must be transportable to a different database.

When you want to restore this backup, either to the same database (if wallet-based encryption is off) or to a different database, you must specify the decryption password with SET DECRYPTION:

If you are recovering one or more tablespaces or the entire database from backups that have different passwords, you can conveniently specify all the passwords at once with SET DECRYPTION:

RMAN will try each password in turn for every encrypted backup until it finds a match. RMAN will terminate with an error only if no passwords match any of the passwords in any of the backups.

Using Dual Mode Encryption

You can use both transparent encryption and password encryption at the same time. This is useful if your backup might be used to restore or recover within the same database, and on occasion it can be used to recover another database. When both methods are in effect, you can use either the password or the database wallet to restore the backup. When recovering to a remote database, you must specify the password before recovering, as follows:

If you want to use only password-based encryption for a backup, add the ONLY clause to SET ENCRYPTION:

As a result, even if ENCRYPTION defaults to ON (and therefore uses the wallet), all subsequent backups use password encryption only until you turn off password encryption or exit RMAN altogether.

Report On and Maintain Backups

Once you have successfully completed your backups, you will probably need to find out which backups are available, which backups are obsolete, and which backups need to occur to satisfy your retention policy. RMAN has the LIST and REPORT commands to help you extract this metadata from the recovery catalog or the target database control file.

The LIST command provides basic information about the backupsets, image copies, proxy copies, and stored scripts recorded in the recovery catalog. In contrast, the REPORT command provides a more detailed analysis of the backup information in the recovery catalog. For example, the REPORT NEED BACKUP command lists all datafiles that don’t have enough backups to satisfy the database’s retention policy. In contrast, the REPORT OBSOLETE command identifies files that are no longer needed to satisfy the database’s retention policy, such as extra datafile copies or archived redo log files that are superseded by a more recent datafile backup. If you are low on disk space, you can use DELETE OBSOLETE to remove these files.

Occasionally, you can lose a disk containing backups due to a hardware failure. Also, tapes containing backups can sometimes wear out and are no longer writeable or readable. As a result, you should run the CROSSCHECK command on a regular basis to ensure that the recovery catalog reflects the existence and integrity of these backups. Files that are no longer available for recovery are marked as EXPIRED, and you can remove them with the DELETE EXPIRED command.

The following sections describe each of these commands with numerous examples.

Using the LIST Command

The LIST command displays information about backupsets and image copies in the repository and can also store the contents of scripts stored in the repository catalog. The following example shows a summary of the backups, and then lists the stored script names:

Another variation on the LIST command is LIST FAILURE, which displays database failures; LIST FAILURE, ADVISE FAILURE, and REPAIR FAILURE are covered in Chapter 13.

Using the REPORT Command

In contrast to the LIST command, the REPORT command performs a more detailed analysis of the information in the recovery catalog, such as which files need more backups to comply with the defined retention policy. The next example changes the retention policy to two copies, and then queries the recovery catalog to see which datafiles don’t have two copies:

As this report indicates, the datafiles for the USERS and SYSAUX tablespaces have enough backup copies to satisfy the retention policy.

This example finds out what the datafiles looked like back on 8/30/2007, and then queries the current status of the datafiles:

At some point between 8/30/2007 and today, the tablespaces INET_STAR and INET_INTL_STAR were created.

You can query the recovery catalog using Enterprise Manager Database Control (or Grid Control using Oracle RAC) as well. From the database home page, select the Availability tab, and click the Manage Current Backups link. You can see in Figure 4-3 the current list of backupsets and image copies recorded in the recovery catalog.

FIGURE 4-3 Querying the recovery catalog using EM Database Control

Using the DELETE Command

Once you have identified which datafiles and archived redo log files are obsolete (as defined by your database’s retention policy), you can remove them manually with the DELETE OBSOLETE command. You can remove obsolete files either one at a time or remove all obsolete backups using this command:

Note that if you are using a flash recovery area, RMAN automatically removes obsolete files when the free space in the flash recovery area is low.

Using the CROSSCHECK Command

On occasion, a backup tape can get lost or a disk containing backup files can fail. To keep the recovery catalog up to date, you can use the CROSSCHECK command to mark the missing backups as EXPIRED. In the following example, a backup directory on the /u05 file system has failed. A backup of the USERS tablespace on this file system and the backup are recorded in the recovery catalog. To synchronize the recovery catalog with the backups that are still valid and exist, use the CROSSCHECK command:

RMAN identifies the backup on /u05/oradata/rmtbak as EXPIRED. Once you have marked expired backups as EXPIRED in the recovery catalog with the CROSSCHECK command, you can remove the entries in the recovery catalog by using the DELETE EXPIRED command:

Note that you don’t always have to delete expired backups. If the disk or tape becomes available in the future, you can run CROSSCHECK again. RMAN will find the backup and mark it as AVAILABLE; as a result, it can be used again in a recovery operation.

CERTIFICATION SUMMARY

This chapter dove into the mechanics of performing backups after presenting a thorough introduction to the key features of RMAN: optimized backup compression, true incremental backups, parallel operations, and advanced scripting capabilities. There are very few situations in which a non-RMAN backup method is required or can back up your database quickly while the database is available to users.

The first part of the chapter covered the basics of creating a backupset (the default) or image copies. You can create image copies of database datafiles and archived redo logs using operating system commands. However, RMAN provides a number of advantages when performing an image copy, such as block verification and backupset compression and decompression. When compressing a backup, RMAN provides two different encryption methods depending on your available disk space and CPU contention.

Next, the chapter explained the somewhat subtle distinctions between a whole database backup, a full backup, and an incremental backup. A whole database backup is a snapshot of all datafiles, the control file, and all archived redo log files. In contrast, a full backup is a complete backup of one or more individual database objects and cannot participate in an incremental backup strategy. Incremental backups can be level 0 or level 1. Level 0 backups are logically equivalent to full backups but can be used as the base for level 1 incremental backups, which can be either cumulative or differential.

RMAN has a number of features to make your backups more reliable and take less time to complete. Incremental backups use a block change tracking file to identify which data blocks have changed since the last incremental backup. As a result, RMAN does not have to read all blocks in every datafile to successfully back up only the changed blocks. Duplexed backups decrease the amount of time it takes to make simultaneous multiple copies of datafiles. You can send one copy to a local disk at the same time you send another copy to an offsite disk, all in less time than it takes to make two sequential backups or a local backup, followed by a copy of the backup to an offsite location. To further decrease the time it takes to complete your backups, RMAN can skip backing up a read-only tablespace by using the SKIP READONLY option or by configuring backup optimization.

Archival backups, another new RMAN feature as of Oracle Database 11g, are backups that never expire and provide a snapshot of your database for regulatory compliance. Because they provide a snapshot of your database at a point of time in the past with a specific retention time or an indefinite retention time, you keep your recovery area clean of archived redo log files that would otherwise have to remain in your flash recovery area for an equivalent recovery window.

Multisection RMAN backups give you the flexibility to back up and validate backups of very large datafiles in sections. In previous versions, large datafiles (such as those found in bigfile tablespaces) took a prohibitively long amount of time to back up because RMAN could allocate only one thread to back up the datafile sequentially.

To enhance the security of your backups, RMAN can use either password-based or wallet-based encryption, or it can use both at the same time. Wallet-based encryption is the preferred method, but in cases where you must restore your datafiles to another database, providing a strong password keeps the backup secure until you are ready to restore it into a target database.

Finally, you were introduced to two commands used to query the contents of your recovery catalog: the LIST and REPORT commands. The LIST command gives you a high-level view of your backups, including backupsets, image copies, and stored scripts. The REPORT command gives you a more in-depth analysis of your backups, such as identifying missing backups or database objects that need to be backed up again to satisfy your configured retention policy. Once you identify any extra backups, you can use the DELETE command to remove them. You can also use the DELETE command to remove backups from the recovery catalog that have been identified as missing with the CROSSCHECK command.

TWO-MINUTE DRILL

Create Image File Backups

RMAN backups are either backupsets or image backups.

Backupsets can be created only by RMAN and can be read only by RMAN.

The FORMAT clause of the BACKUP command specifies the substitution variables for the destination backup filename.

You can create image copies of datafiles, archived redo log files, and control files.

Image copies can be written only to disk.

You can use the SWITCH command to quickly and easily switch between a datafile and its image copy during a recovery operation.

Create a Whole Database Backup

A whole database backup includes all datafiles plus the control file.

A full backup of a datafile is a logical subset of a whole database backup.

A full backup cannot be used as the basis for an incremental backup strategy.

An incremental backup is level 0 or level 1.

An incremental level 0 backup can be used as the basis for an incremental backup strategy.

Differential backups back up all changed blocks since the last level 0 or level 1 incremental backup.

Cumulative incremental backups back up all changed blocks since the last level 0 backup.

Enable Fast Incremental Backup

Enable fast incremental backup by creating a block change tracking file.

Perform a level 0 incremental backup before configuring RMAN to use a block change tracking file.

The data dictionary view V$BLOCK_CHANGE_TRACKING provides the name and status of the block change tracking file.

Create Duplex Backup and Back Up Backupsets

Duplexed backupsets can significantly reduce the time it takes to create multiple copies of the same backup.

Backups cannot be duplexed to the flash recovery area, and you cannot duplex image copies.

Use the BACKUP . . . BACKUPSET commands to create a copy of an existing RMAN backup to disk or tape.

RMAN will skip the backup of read-only tablespaces if you use SKIP READONLY in the BACKUP command.

If you configure RMAN for backup optimization, RMAN will back up only additional copies of read-only tablespaces to satisfy the configured retention policy.

Create an Archival Backup for Long-term Retention

An archival backup is a snapshot of the database at a certain point in time created to satisfy archival or regulatory purposes.

Archival backups make it easy to migrate a copy of the database to another system without affecting the retention policy of the original database.

To create an archival backup, you specify either the KEEP UNTIL TIME or KEEP FOREVER option in the BACKUP command.

An RMAN archival backup also includes any archived logs required to use the backup in a recovery scenario.

You can use the CHANGE command to change the status of an archival backup.

Create a Multisection, Compressed, and Encrypted Backup

Multisection RMAN backups can significantly reduce the time it takes to back up very large datafiles to multiple destinations.

You can run the VALIDATE command in multisection mode.

The SECTION SIZE parameter determines the size for each section in a multisection backup or validate operation.

The V$BACKUP_SET and RC_BACKUP_SET views contain a MULTI_SECTION column to indicate whether the backup is a multisection backup.

The V$BACKUP_DATAFILE and RC_BACKUP_DATAFILE views contain a SECTION_SIZE column that contains the number of blocks in each piece of a multisection backup.

RMAN can compress backups of used blocks using BZIP2 or ZLIB.

ZLIB is faster but compresses less. BZIP2 is slower but compresses more.

Transparent encryption uses a database wallet to encrypt a backup, and the backup can be restored only to the source database.

Password encryption uses a password to encrypt a backup, and the backup can be restored either to the source database or another database.

You can use both transparent encryption and password encryption on the same backup.

Transparent encryption can be enabled for a single backup using the SET ENCRYPTION command.