Pro Oracle Database 11g Administration (81 page)

Recovery Catalog Versions

I recommend that you create a recovery catalog for each version of target databases that you’re backing up. Doing so will save you some headaches with compatibility issues and upgrades. I’ve found it easier to use a recovery catalog when the database version of the rman client is the same version of the database used when creating the catalog.

Yes, having multiple versions of the recovery catalog can cause some confusion. However, if you’re in an environment where you have several different versions of the Oracle database, then multiple recovery catalogs may be more convenient.

Dropping a Recovery Catalog

If you determine that you’re not using a recovery catalog and you no longer need the data, you can drop it. To do so, connect to the catalog database as the catalog owner, and issue the DROP CATALOG command: $ rman catalog rcat/foo

RMAN> drop catalog;

You’re prompted as follows:

recovery catalog owner is RCAT

enter DROP CATALOG command again to confirm catalog removal

If you enter the DROP CATALOG command again, all the objects in the recovery catalog are removed from the catalog database.

The other way to drop a catalog is to drop the owner. To do so, connect to the recovery catalog as a user with DBA privileges, and issue the DROP USER statement:

$ sqlplus system/manager

SQL> drop user rcat cascade;

SQL*Plus doesn’t prompt you twice. It does as you instructed and drops the user and its objects.

Again, the only reason to do this is when you’re certain you don’t need the recovery catalog or its data any longer. Use caution when dropping a user or the recovery catalog: I recommend that you take a Data Pump export of the recovery-catalog owner before dropping it.

485

CHAPTER 17 ■ CONFIGURING RMAN

Summary

RMAN is Oracle’s flagship B&R tool. If you’re still using the older user-managed backup technologies, then I strongly recommend that you switch to RMAN. RMAN contains a powerful set of features that are unmatched by any other backup tool available. It’s easy to use and configure. RMAN will save you time and effort and give you peace of mind when you’re implementing a rock-solid B&R strategy.

If you’re new to RMAN, it may not be obvious which features should always be enabled and implemented and likewise which aspects you’ll rarely need. This chapter contains a checklist for you to follow that walks you through each architectural decision point. You may disagree with some of my conclusions, or some recommendations may not meet your business requirements—that’s fine. The point is that you should carefully consider each component and how to implement the features that make sense.

The chapter ended with a real-world example of a script used to implement RMAN in a production environment. Now that you have a good idea of RMAN’s features and how to use them, you’re ready to start making backups. The next chapter deals with RMAN backup scenarios.

486

CHAPTER 18 ■ RMAN BACKUPS AND REPORTING

The bulleted items are discussed in the following sections.

Setting NLS_DATE_FORMAT

Before running any RMAN job, I set the operating system variable NLS_DATE_FORMAT to include a time (hours, minutes, and seconds) component. For example:

$ export NLS_DATE_FORMAT='dd-mon-yyyy hh24:mi:ss'

Additionally, if I have a shell script that calls RMAN, I put the prior line directly in the shell script (see the shell script at the end of Chapter 17 for an example):

NLS_DATE_FORMAT='dd-mon-yyyy hh24:mi:ss'

This ensures that when RMAN displays a date, it always includes the hours, minutes, and seconds as part of the output. By default, RMAN only includes the date component (DD-MON-YYYY) in the output.

For example, when starting a backup, here is what RMAN displays:

Starting backup at 15-sep-2010

When you set the NLS_DATE_FORMAT OS variable to include a time component, the output will look like this instead:

Starting backup at 15-sep-2010 03:20:17

When troubleshooting, it's essential to have a time component so that you can determine how long a command took to run, or how long a command was running before a failure occurred. Oracle Support will almost always ask you to set this variable to include the time component before capturing output and sending it to them.

The only downside to setting the NLS_DATE_FORMAT is if you set it to a value unknown to RMAN, it can cause connectivity issues. For example, here the NLS_DATE_FORMAT is set to an invalid value: $ export NLS_DATE_FORMAT='dd-mon-yyyy hh24:mi:sd'

$ rman target /

When set to an invalid value, you get this error when logging into RMAN: RMAN-03999: Oracle error occurred while converting a date: ORA-01821: To unset the NLS_DATE_FORMAT variable, set it to a blank value, like so: $ export NLS_DATE_FORMAT=''

Setting ECHO Setting ECHO

Another value that I always set in any RMAN scripts is the ECHO command, seen here: RMAN> set echo on;

This instructs RMAN to display the command that it's running in the output, so you can see what RMAN command is running along with any relevant error or output messages associated with the command. This is especially important when you're running RMAN commands within scripts, because you're not directly typing in a command (and may not know what command was issued within the shell script). For example, without SET ECHO ON, here's what is displayed in the output for a command: 488

CHAPTER 18 ■ RMAN BACKUPS AND REPORTING

Starting backup at 15-sep-2010 03:49:55

using target database control file instead of recovery catalog

With SET ECHO ON, this output shows the actual command that was run:

backup datafile 4;

Starting backup at 15-sep-2010 03:49:55

using target database control file instead of recovery catalog

From the prior output you can see which command is running, when it started, and so on.

Showing Variables

Another good practice is to run the SHOW ALL command within any script, like so: RMAN> show all;

This displays all of the RMAN configurable variables. When troubleshooting, you may not be aware of something that another DBA has configured. This gives you a snapshot of the settings as they were when the RMAN session executed.

Running Backups

Before you run an RMAN backup, make sure you read Chapter 17 for details on how to configure RMAN

with settings for a production environment. For production databases, I mainly run RMAN from a shell script similar to the script shown at the end of Chapter 17. Within the shell script, I configure every aspect of RMAN that I want to use for a particular database. If you run RMAN out-of-the-box with its default settings, you will be able to back up your database. However, these settings will not be adequate for most production database applications.

Backing up the Entire Database

If you're not sure where RMAN will be backing up your database files, you need to read Chapter 17

because it describes how to configure RMAN to create the backup files in the location of your choice.

Here is how I usually configure RMAN to write to specific locations on disk (note that the CONFIGURE

command must be executed before you run the BACKUP command):

RMAN> configure channel 1 device type disk format '/ora01/O11R2/rman/rman1_%U.bk'; After a backup location is configured, I almost always use a command similar to the one shown next to back up the entire database:

RMAN> backup incremental level=0 database plus archivelog;

This command ensures that RMAN will back up all datafiles in the database, all archive redo logs generated prior to the backup, and all archive redo logs generated during the backup. This command also ensures that you have all of the datafiles and archive redo logs that would be required to restore and recover your database.

If you have the autobackup of the control file feature enabled (see Chapter 17 for details), the last task RMAN does as part of the backup is generate a backup set that contains a backup of the control file.

This control file will contain all information regarding the backup that took place and any archive redo logs that were generated during the backup.

489

CHAPTER 18 ■ RMAN BACKUPS AND REPORTING

■
Tip
Always enable the autobackup of the control file feature.

There are many nuances to the RMAN BACKUP command. For production databases, I usually back up the database with the BACKUP INCREMENTAL LEVEL=0 DATABASE PLUS ARCHIVELOG command. That's usually sufficient. However, you will encounter many situations where you need to run a backup that uses a specific RMAN feature or you might troubleshoot an issue where you need to be aware of the other ways to invoke an RMAN backup. These aspects are discussed in the next several sections of this chapter.

Full Backup versus Incremental Level=0

The term "RMAN full backup" sometimes causes confusion. A more apt way of phrasing what a full backup is doing would be "RMAN is backing up all modified blocks within one or more datafiles." The term "full" does not mean that all blocks are backed up or that all datafiles are backed up. It simply refers to the fact that all blocks that would be required to rebuild a datafile (in the event of a failure) are being backed up. You can take a full backup of a single datafile and the contents of that backup piece may be quite a bit smaller than the datafile itself.

The term "RMAN level 0 incremental backup" doesn't exactly describe itself very well, either. A level 0 incremental backup is backing up the exact same blocks as a full backup. In other words, the following two commands back up the exact same blocks in a database:

RMAN> backup as backupset full database;

RMAN> backup as backupset incremental level=0 database;

The only difference between the prior two commands is that an incremental level 0 backup can be used in conjunction with other incremental backups whereas a full backup can not participate in an incremental backup strategy.

Therefore, I almost always prefer to use the INCREMENTAL LEVEL=0 syntax (as opposed to a full backup). This is because it gives me the flexibility to use the level 0 incremental backup with different incremental level backups.

Backup Sets versus Image Copies

The default backup mode of RMAN instructs it to only back up blocks that have been used in a datafile; these are known as backup sets. RMAN can also make byte-for-byte copies of the datafiles; these are known as image copies. Creating a backup set is the default type of backup that RMAN creates. The next command creates a backup set backup of the database:

RMAN> backup database;

If you prefer, you can explicitly place the AS BACKUPSET command when creating backups: RMAN> backup as backupset database;

You can instruct RMAN to create image copies by using the AS COPY command. The following creates image copies of every datafile in the database:

RMAN> backup as copy database;

Since image copies are identical copies of the datafiles, they can be directly accessed by the DBA with operating system commands. For example, say you had a media failure and you didn't want to use 490

CHAPTER 18 ■ RMAN BACKUPS AND REPORTING

RMAN to restore an image copy. You could use an operating system command to copy the image copy of a datafile to a location where it can be used by the database, whereas a backup set consists of binary files that only the RMAN utility can write to or read from.

I prefer to use backup sets when working with RMAN. The backup sets tend to be smaller than the datafiles and can have true binary compression applied to them. Also, I don’t find it inconvenient to use RMAN as the mechanism for creating backup files that only RMAN can restore. Using RMAN with backup sets is efficient and very reliable.

Backing up Tablespaces

RMAN has the ability to back up at the entire database level (as shown in prior examples), the tablespace level, or even more granularly at the datafile level. When you back up a tablespace, RMAN backs up any datafiles associated with the tablespaces(s) that you specify. For example, the following command will back up all of the datafiles associated with the SYSTEM and SYSAUX tablespaces: RMAN> backup tablespace system, sysaux;

One scenario where I back up at the tablespace level is if I've recently created a new tablespace and want to take a backup of just the datafiles (associated with the newly added tablespace). Note that when troubleshooting backup and recovery issues, it's often more efficient to work with one tablespace (because it's usually much faster to back up one tablespace than the entire database).

Backing up Datafiles

You may occasionally need to back up individual datafiles. For example, when troubleshooting issues with backups, it's often helpful to attempt to successfully backup one datafile. You can specify datafiles by filename or by file number like so:

RMAN> backup datafile '/ora01/dbfile/O11R2/system01.dbf';

Here's an example where file numbers are specified:

RMAN> backup datafile 1,3;

Here are some other examples of backing up datafiles using various features: RMAN> backup as copy datafile 3;