Pro Oracle Database 11g Administration (83 page)

Here's an example of taking an incremental level 0 backup:

RMAN> backup incremental level=0 database;

Suppose for the next several backups you only want to back up the blocks that have changed since the last level 0 baseline backup. This line of code takes a level 1 backup: RMAN> backup incremental level=1 database;

There are two different types of incremental backups: differential and cumulative. Which type of incremental (differential or cumulative) you use depends on your requirements. Differential backups (the default) are smaller but take more time to recover from. Cumulative backups are larger than differential backups but take less time to recover from.

A differential incremental level 1 backup instructs RMAN to back up blocks that have changed since the last level 1 or level 0 backups, whereas a cumulative incremental level 1 backup instructs RMAN to back up blocks that have changed since the last level 0 backup. Cumulative incremental backups, in effect, ignore any level 1 incremental backups.

■
Note
The RMAN incremental level 0 backups are used to restore the datafiles, while the RMAN incremental level 1 backups are used to recover the datafiles.

When using incremental backups, I almost always use the default of differential. Usually I don't worry about the differences between incremental and cumulative backups. If you require cumulative backups, you must specify the key word CUMULATIVE. Here's an example of taking a cumulative level 1

backup:

RMAN> backup incremental level=1 cumulative database;

Here are some other examples of taking incremental backups at more granular level than the database:

497

CHAPTER 18 ■ RMAN BACKUPS AND REPORTING

RMAN> backup incremental level=0 tablespace sysaux;

RMAN> backup incremental level=1 tablespace sysaux plus archivelog; RMAN> backup incremental level=1 datafile 3;

Making Incrementally Updating Backups

The basic idea behind an incrementally updating backup is to create image copies of datafiles and then use incremental backups to update the image copies. In this manner, you have image copies of your database that are kept somewhat current by applying an incremental backup to them. This can be an efficient way to combine image copy backups with incremental backups.

To understand how this backup technique works, you'll need to inspect the commands that perform an incrementally updating backup. You need two lines of RMAN code to enable this feature: RMAN> recover copy of database with tag 'incupdate';

RMAN> backup incremental level 1 for recover of copy with tag 'incupdate' database; In the first line, a tag is specified (this example uses incupdate). You can use whatever you want for the tag name; the tag name lets RMAN associate the backup files being used each time the commands are run. Then, this code will do the following the first time you run the script:

• RECOVER COPY generates a message saying there's nothing for it to do.

• If no image copies exist, the BACKUP INCREMENTAL creates an image copy of the database datafiles.

You should see messages like this in the output when the RECOVER COPY command runs the first time:

no parent backup or copy of datafile ... found

In the output for the BACKUP INCREMENTAL, you should see text like this indicating that image copies are being created:

channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:25

The second time you run the incrementally updating backup, it does as follows:

• RECOVER COPY still has nothing to do.

• BACKUP INCREMENTAL makes an incremental level 1 backup and assigns it the tag name specified; this backup will subsequently be used by the RECOVER COPY

command.

The third time you run the incrementally updating backup, it does this:

• Now that an incremental backup has been created, the RECOVER COPY applies the incremental backup to the image copies.

• BACKUP INCREMENTAL makes an incremental level 1 backup and assigns it the tag name specified; this backup will subsequently be used by the RECOVER COPY

command.

Going forward, each time that you run the two lines of code you will have a regularly repeating backup pattern. If you use image copies for backups, you might consider using an incrementally updating backup strategy because you avoid creating entire image copies each time the backup runs.

498

CHAPTER 18 ■ RMAN BACKUPS AND REPORTING

The image copies are updated each time the backup runs with the incremental changes from the previous backup.

Using Block Change Tracking

Block change tracking is where a binary file is used to record changes to database datafile blocks. The idea is that incremental backup performance can be improved because RMAN can use the block change tracking file to pinpoint which blocks have changed since the last backup. This saves a great deal of time because otherwise RMAN would have to scan all blocks that have been backed up to determine if they've changed since the last backup. You can enable block change tracking by doing the following: 1. If not already enabled, set the
DB_CREATE_FILE_DEST
parameter to a location. For example:

SQL> alter system set db_create_file_dest='/ora01/O11R2/bct' scope=both; 2. Enable block change tracking via the ALTER DATABASE command:

SQL> alter database enable block change tracking;

This example creates a file with an OMF name in the directory specified by DB_CREATE_FILE_DEST. In this example, the file created is named as:

/ora01/O11R2/bct/O11R2/changetracking/o1_mf_68wxc16g_.chg

You can also enable block change tracking by directly specifying a file name, which does not require DB_CREATE_FILE_DEST to be set. For example:

SQL> alter database enable block change tracking using file '/ora01/O11R2/bct/btc.bt'; You can verify the details of block change tracking by running the following query: SQL> select * from v$block_change_tracking;

For space planning purposes, the size of the block change tracking file is approximately 1/30,000 the size of the total size of the blocks being tracked in the database. Therefore, the size of the block change tracking file is proportional to the size of the database and not the amount of redo generated.

To disable block change tracking, run the following command:

SQL> alter database disable block change tracking;

■
Note
When you disable block change tracking, Oracle will automatically delete the block change tracking file.

Checking for Corruption in Datafiles and Backups

You can use RMAN to check for corruption in datafiles, archive redo logs, and control files. You can also verify whether a backup set is restorable. The RMAN VALIDATE command is used to perform these types of integrity checks. There are three ways you can run the VALIDATE command:

• VALIDATE

• BACKUP...VALIDATE

499

CHAPTER 18 ■ RMAN BACKUPS AND REPORTING

• RESTORE...VALIDATE

■
Note
The standalone VALIDATE command is available in Oracle Database 11g or higher. The BACKUP...VALIDATE and RESTORE...VALIDATE commands are available in Oracle Database 10g or higher.

Using VALIDATE

The VALIDATE command can be used alone (without BACKUP or RESTORE) to check for missing files or physical corruption in database datafiles, archive redo log files, control files, spfile, and backup set pieces. For example, this command will validate all datafiles and the control files: RMAN> validate database;

You can also validate just the control file as follows:

RMAN> validate current controlfile;

You can validate the archive redo log files like so:

RMAN> validate archivelog all;

You can combine all of the prior three integrity checks into one command, as shown: RMAN> validate database include current controlfile plus archivelog; Under normal operations the VALIDATE command only checks for physical corruption. You can specify that you want to also check for logical corruption by using the CHECK LOGICAL clause like so: RMAN> validate check logical database include current controlfile plus archivelog; You can use VALIDATE in a variety of ways. Here are a few more examples: RMAN> validate database skip offline;

RMAN> validate copy of database;

RMAN> validate tablespace system;

RMAN> validate datafile 3 block 20 to 30;

RMAN> validate spfile;

RMAN> validate backupset ;

RMAN> validate recovery area;

If RMAN detects any corrupt blocks, the V$DATABASE_BLOCK_CORRUPTION is populated. This view contains information on the file number, block number, and the number of blocks affected. You can use this information to perform a block level recovery. See Chapter 19 for details on block level recovery.

■
Note
Physical corruption is when the block contents don’t match the physical format that Oracle expects. By default, RMAN checks for physical corruption when backing up, restoring, or validating datafiles. Logical corruption is when the block is in the correct format but the contents aren’t consistent with what Oracle expects. Logical corruption would be issues such as corruption in a row piece or an index entry.

500

CHAPTER 18 ■ RMAN BACKUPS AND REPORTING

Using BACKUP...VALIDATE

The BACKUP VALIDATE command is very similar to the VALIDATE command in that it can check to see if datafiles are available and if the datafiles contain any corrupt blocks. For example: RMAN> backup validate database;

This command doesn't actually perform any type of backup or create any files. It only scans the datafiles and checks for corruption. Like the VALIDATE command, BACKUP VALIDATE by default only checks for physical corruption. You can instruct it to also check for logical corruption as shown: RMAN> backup validate check logical database;

Here are some other variations of the BACKUP...VALIDATE command:

RMAN> backup validate database current controlfile;

RMAN> backup validate check logical database current controlfile plus archivelog; Like the VALIDATE command, BACKUP...VALIDATE will populate V$DATABASE_BLOCK_CORRUPTION if it detects any corrupt blocks. The information in this view can be used to determine which blocks can potentially be restored by block level recovery. See Chapter 19 for more details on block level recovery.

Using RESTORE...VALIDATE

The RESTORE...VALIDATE command is used to verify backup files that would be used to restore. This command validates backup sets, datafile copies, and archive redo log files: RMAN> restore validate database;

No actual files are restored when using RESTORE...VALIDATE. This means you can run the command while the database is online and available.

Logging RMAN Output

When troubleshooting RMAN output or checking on the status of a backup job, it's essential to have a record of what RMAN ran and the status of each command. There are several methods for logging RMAN

output. Some of them are built-in aspects of the Linux/Unix operating system and others are RMAN-specific features:

• Linux/Unix redirect output to file

• Linux/Unix logging commands

• RMAN LOG command

• V$RMAN_OUTPUT view

These logging features are discussed in the next sections.

Redirecting Output to a File

I run almost all RMAN backup jobs from shell scripts. The shell scripts are usually run automatically from a scheduling tool such as cron. When running RMAN commands in this fashion, I always capture the output by instructing the shell command to redirect standard output messaging and standard error 501

CHAPTER 18 ■ RMAN BACKUPS AND REPORTING

messaging to a log file. This is done with the redirection > character. This example runs a shell script (rmanback.bsh) and redirects both standard output and standard error output to a log fie named rmanback.log:

$ rmanback.bsh 1>/home/oracle/bin/log/rmanback.log 2>&1

Here, 1> instructs standard output to be redirected to the specified file. The 2>&1 instructs the shell script to send standard error output to the same location as standard output.

■
Tip
For full details on how DBAs use shell scripts and Linux features see Linux Recipes for Oracle DBAs (Apress, 2008).

Capturing Output with Unix/Linux Logging Commands

You can instruct Unix/Linux to create a log file to capture any output that is also being displayed on your screen. This can be done in one of two ways:

• tee

• script

Capturing Output with tee

When you start RMAN, you can send the output you see on your screen to an operating system text file using the tee command:

$ rman | tee /tmp/rman.log

Now you can connect to the target database and run commands. All of the output seen on your screen will be logged to the /tmp/rman.log file:

RMAN> connect target /

RMAN> backup database;

RMAN> exit;

The tee party session stops writing to the log file when you exit from RMAN.

Capturing Output with the script Command

The script command is useful because it instructs the operating system to log any output that appears on the terminal to a log file. To capture all output, run the script command before connecting to RMAN: $ script /tmp/rman.log

Script started, file is /tmp/rman.log

$ rman target /

RMAN> backup database;

RMAN> exit;

To end a script session, type in Ctrl+D or type in exit. The /tmp/rman.log file will contain all output that was displayed on your screen. The script command is useful when you need to capture all output 502

CHAPTER 18 ■ RMAN BACKUPS AND REPORTING

from one point in time to another point in time. For example, you may be running RMAN commands, exiting from RMAN, running SQL*Plus commands, and so on. The script session lasts from the point you start script to where you type in Ctrl+D.

Logging Output to a File

An easy way to capture RMAN output is to use the SPOOL LOG command to send the output to a file. This example spools a log file from within RMAN:

RMAN> spool log to '/tmp/rmanout.log'