Pro Oracle Database 11g Administration (77 page)

Whenever possible, I run the rman client locally on the target server and connect like this: $ rman target /

This approach is simple and adequate for most requirements. You don’t have to worry about network issues or password files, and there are never compatibility issues with the rman client and the target database. If you run RMAN remotely, you need to be sure the remote rman executable is compatible with the target database. For example, is the remote rman executable you’re running an Oracle Database 10
g
version of the RMAN client, and is it possible to connect that client to a remote Oracle Database 8
i
target database? If you run the rman client locally on the target server, there never is a compatibility issue because the rman client is always the same version as the target database.

464

CHAPTER 17 ■ CONFIGURING RMAN

2. Specifying the Backup User

As described in the previous section, RMAN requires that you use a database user with SYSDBA privileges.

Whether I’m running RMAN from the command line or invoking RMAN in a script, in most scenarios, I connect directly as SYS to the target database. For example, here’s how I connect to RMAN from the command line:

$ rman target /

Some DBAs don’t use that approach; they prefer to set up a separate user from SYS and cite security concerns as a reason for doing this.

I prefer to use the SYS account directly because when connecting to RMAN locally on the server, there is no need to specify a username and password. This means you never have to hard-code usernames and passwords into any backup scripts or specify a username and password on the command line that can be viewed by rogue developers or managers looking over your shoulder.

3. Using Online or Offline Backups

Most production databases have 24x7 availability requirements. Therefore, your only option is online RMAN backups. Your database must be in archivelog mode for online backups. You need to carefully consider where to place archive-redo logs, how to format them, how often to back them up, and how long to retain them before deletion. These topics are discussed in subsequent sections.

■
Note
If you make offline backups, you must shut down your database with IMMEDIATE, NORMAL, or TRANSACTIONAL and then place it in mount mode. RMAN needs the database in mount mode so it can read from and write to the control file.

4. Setting the Archive-Redo Log Destination and File Format

Enabling archive-redo log mode is a prerequisite for making online backups. See Chapter 16 for a full discussion of architectural decisions regarding the archive-redo log destination and format and how to enable/disable archivelog mode.

When archivelog mode is enabled, Oracle writes the archive-redo logs to one or more of the following locations (you can configure archive-redo logs to be written both to the FRA and several other locations that you manually set via initialization parameters):

• Default location

• FRA

• Location specified via LOG_ARCHIVE_DEST_N initialization parameter(s) If you don’t use an FRA and if you don’t explicitly set the archive-redo log destination via a LOG_ARCHIVE_DEST_N initialization parameter, then by default the archive-redo logs are written to an OS-dependent location. On many Linux/Unix boxes, the default location is the ORACLE_HOME/dbs/arch directory. The default filename format for archive-redo logs is %t_%s_%r.dbf.

465

CHAPTER 17 ■ CONFIGURING RMAN

If you enable an FRA, then by default the archive-redo logs are written to a directory in the FRA. The default format of the name of archive-redo log files created in the FRA is an Oracle Managed File format.

For example:

///archivelog//o1_mf_1_1078_68dx5dyj_.arc Oracle recommends using an FRA. I prefer not to use an FRA because I don’t like to be surprised with a hung database when there are issues with the FRA filling up and not being purged of old files quickly enough. Instead, I prefer to use the LOG_ARCHIVE_DEST_N parameter to set the location of the archive-redo log files. Here’s an example:

log_archive_dest_1='LOCATION=/oraarch1/CHNPRD'

I also prefer to use this for the default archivelog file name format: log_archive_format='%t_%s_%r.arc'

Sometimes DBAs use .dbf as an extension for both datafiles and archive-redo log files. This format avoids potential confusion with identifying a file as an archive-redo log file or a live database datafile.

5. Configuring the RMAN Backup Location and File Format

When you run a BACKUP command for disk-based backups, RMAN creates backup pieces in one of the following locations:

•

•

•

If you don’t configure any RMAN variables and don’t set up an FRA, by default RMAN allocates one disk-based channel and writes the backup files to a default location. For example, you can run the following command without configuring any RMAN parameters:

RMAN> backup database;

If nothing has been configured, RMAN allocates a disk-based channel and writes the backups to the default disk location. This location varies by OS. In many Linux/Unix environments, the default location is ORACLE_HOME/dbs. The default format of the name of the backup files created is an Oracle Managed File format. For example:

/dbs/01ln9g7e_1_1

When backing up to disk, if you don’t explicitly instruct RMAN to write the backups to a specific location (via the FORMAT or CONFIGURE command), and if you’re using an FRA, RMAN automatically writes the backup files to directories in the FRA. The default format of the name of the backup files created in the FRA is an Oracle Managed File format. For example:

///backupset//o1_mf_nnndf_TAG20100907T025402_68czfbdf_.bkp I usually don’t use an FRA for the placement of RMAN backups. In many of the environments I work in, there isn’t enough disk space on a single mount point to accommodate the entire size of the database backups. In such situations, you need to allocate two or more channels that point to different mount points. Using an FRA in these environments is somewhat unwieldy.

Also, for performance reasons, you may want to instruct RMAN to write to multiple disk locations. If you can ensure that different mount points are based on different physical disks and are written to by 466

CHAPTER 17 ■ CONFIGURING RMAN

separate controllers, you can reduce I/O contention by allocating multiple channels pointing to separate mount points.

When you’re using an FRA, RMAN automatically creates separate directories when backing up a database for the first time on a given date. I prefer to have the backups written to one directory and not separate the directories and backups by date. I find it easier to manage, maintain, and troubleshoot the backups if I use one standard directory for each database on each server.

If you don’t want to place RMAN backup files in the FRA, there are a couple of methods for directly specifying a backup location:

• BACKUP...FORMAT

• CONFIGURE CHANNEL...FORMAT

You can directly specify where you want backups to be placed when you issue the BACKUP command.

For example:

RMAN> backup database format '/ora01/O11R2/rman/rman_%U.bkp';

Here’s a corresponding file generated by RMAN:

/ora01/O11R2/rman/rman_05ln9hk6_1_1.bkp

The %U instructs RMAN to dynamically construct a unique string for the backup file name. A unique name is required in most situations, because RMAN won’t write over the top of a file that already exists.

This is important because if you instruct RMAN to write in parallel, it needs to create unique file names for each channel. For example:

RMAN> configure device type disk parallelism 2;

Now, when you run this command, RMAN allocates multiple channels and write in parallel to two different backup files. The U% in the format string guarantees that unique file names are created.

I usually don’t use the BACKUP...FORMAT syntax to specify the location for RMAN backups. I prefer to use the CONFIGURE CHANNEL...FORMAT command. This is because I’m usually writing to multiple disk locations and need the flexibility to specify directories located on different mount points. Here’s a typical configuration specifying CONFIGURE CHANNEL...FORMAT:

RMAN> configure device type disk parallelism 3;

RMAN> configure channel 1 device type disk format '/ora01/O11R2/rman/rman1_%U.bk'; RMAN> configure channel 2 device type disk format '/ora02/O11R2/rman/rman2_%U.bk'; RMAN> configure channel 3 device type disk format '/ora03/O11R2/rman/rman3_%U.bk'; In these lines of code, you should configure the device-type parallelism degree to match the number of channels that you allocated. RMAN only allocates the number of channels as specified by the degree of parallelism; other configured channels are ignored. For example, if you specify a degree of parallelism of 2, RMAN allocates only two channels regardless of the number of channels you configured via the CONFIGURE CHANNEL command.

In this example of configuring channels, suppose the BACKUP command is issued like this: RMAN> backup database;

RMAN allocates three channels, all on separate mount points (/ora01, /ora02, /ora03), and writes in parallel to the specified locations. RMAN creates as many backup pieces in the three locations as it deems necessary to create a backup of the database.

467

CHAPTER 17 ■ CONFIGURING RMAN

6. Setting Autobackup of the Control File

You should always configure RMAN to automatically back up the control file after running any RMAN

BACKUP or COPY command or after you make physical changes to the database that result in updates to the control file (such as adding/removing a datafile). Use the SHOW command to display the current setting of the control file autobackup:

RMAN> show controlfile autobackup;

Here’s some sample output:

RMAN configuration parameters for database with db_unique_name O11R2 are: CONFIGURE CONTROLFILE AUTOBACKUP OFF;

The following line of code shows how to enable automatic backup of the control-file feature: RMAN> configure controlfile autobackup on;

The automatic control-file backup always goes into its own backup set. When autobackup of the control file is enabled, if you’re using an spfile, it’s automatically backed up along with the control file.

If for any reason you want to disable automatic backup of the control file, you can do so as follows: RMAN> configure controlfile autobackup off;

■
Note
If autobackup of the control file is off, then any time you back up datafile 1 (SYSTEM tablespace datafile), RMAN automatically backs up the control file.

7. Specifying the Location of the Autobackup of the Control File

When you enable autobackup of the control file, RMAN creates the backup of the control file in one of the following locations:

• Default location

• FRA

• Location specified via the BACKUP or FORMAT command

If you aren’t using an FRA or if you haven’t specified a location for the control-file autobackups, the control-file autobackup is written to an OS-dependent default location. In many Linux/Unix environments, the default location is ORACLE_HOME/dbs. For example:

/oracle/app/oracle/product/11.2.0/db_1/dbs/c-3453199553-20100907-04

If you’ve enabled an FRA, then RMAN automatically writes the control-file autobackup files to directories in the FRA using an Oracle Managed File format for the name. For example:

///autobackup//o1_mf_s_729103049_68fho9z2_.bkp I usually don’t use the default location or the FRA for control-file autobackups. I prefer these backups to be placed in the same directory the database backups are in. Here’s an example: RMAN> configure controlfile autobackup format for device type disk to

'/ora01/O11R2/rman/rman_ctl_%F.bk';

468

CHAPTER 17 ■ CONFIGURING RMAN

8. Backing Up Archive-Redo Logs

You should back up your archive-redo logs on a regular basis. The archivelog files shouldn’t be removed from disk until you’ve backed them up at least once. I usually like to keep on disk any archive-redo logs that have been generated after the last good RMAN backup.

Usually, I instruct RMAN to back up the archive-redo logs at the same time the datafiles are backed up. This is a sufficient strategy in most situations. Here is the command to back up the archive-redo logs along with the datafiles:

RMAN> backup database plus archivelog;

Sometimes, if your database generates a great deal of redo, you may need to back up your archive-redo logs at a different frequency than the datafiles. Sometimes DBAs back up the archive-redo logs two or three times a day; after the logs are backed up, the DBAs delete them to make room for more current archivelog files.

In most situations, you don’t need any archive-redo logs that were generated before your last good backup. For example, a datafile has experienced media failure, you need to restore the datafile from a backup and then apply any archive-redo logs that were generated during and after the backup of the datafile.

On some occasions, you may need archive-redo logs that were generated before the last backup. For example, you may experience a media failure, attempt to restore your database from the last good backup, find corruption in that backup, and therefore need to restore from an older backup. At that point, you need a copy of all archive-redo logs that have been generated since that older backup was made.

9. Determining the Location for the Snapshot Control File

RMAN requires a read-consistent view of the control file for the following tasks:

• Synchronizing with the recovery catalog

• Backing up the current control file

In these situations, RMAN creates a snapshot copy of the current control file that it uses as a read-consistent copy while it’s performing these tasks. This ensures that RMAN is working from a copy of the control file that isn’t being modified.

The default location of the snapshot control file is OS-specific. On Linux platforms, the default location is ORACLE_HOME/dbs/[email protected]. Notice that the default location isn’t in the FRA (even if you’ve implemented an FRA).