CHAPTER 17 Configuring RMAN

Introduction to RMAN RMAN was introduced in Oracle 8.0. RMAN is Oracle’s tool for backup and recovery. RMAN is much more powerful and feature rich than the old user managed backup strategies. DBAs should be highly proficient with using RMAN.

RMAN Advantages/Features Easy-to-use commands for backup, restore, and recovery. Ability to track which files have been backed up and to where. Manages the deletion of obsolete backups and archive-redo logs. Parallelization: can use multiple processes for backup, restore, and recovery. Incremental backups that only back up changes since the previous backup. Block-level recovery, which allows you to recover individual blocks in a datafile. Compression and encryption features. Integration with media managers for tape backups. Backup validation and testing. Cross-platform data conversion. Data Recovery Advisor, which assists with diagnosing failures and providing solutions. Ability to detect corrupt blocks in datafiles. Advanced reporting capabilities from the RMAN command line.

Understanding RMAN

Before Starting RMAN Client... Set OS environment variables Have access to a privileged operating-system account or a database user with SYSDBA privileges

Running the RMAN client remotely or locally $ rman target / or $ rman target Author recommends local connections when possible.

Specifying the Backup User Some DBAs prefer OS authentication like : $ rman target / Others prefer to setup a specific user and grant it SYSDBA privileges and use that for B&R. This approach requires that you implement a password file: SQL> create user rmanstuff identified by glenn; SQL> grant sysdba to rmanstuff;

Using Online or Offline Backups Depends on your business requirements. Most 7x24 production databases require as little downtime as possible, and therefore require online backups. There seems to be some misconception out there about whether online backups are as good as offline backups. Online backups are just as good as offline backups. There is no need to periodically shut down your database and take an offline backup.

Setting the Archive-Redo Log Destination and File Format Three choices: Default location FRA Location specified via LOG_ARCHIVE_DEST_N initialization parameter(s) Author recommends setting LOG_ARCHIVE_DEST_N, but many DBAs use the FRA.

Configuring the RMAN Backup Location and File Format Depends on your business requirements This example backs up to three separate mount points in parallel: 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';

Setting Autobackup of the Control File Always set the autobackup to the control file to on; there is no downside to doing this and it ensures that you frequently get a backup of your control file RMAN> configure controlfile autobackup on;

Specifying the Location of the Autobackup of the Control File 3 choices: Default location FRA Location specified via the BACKUP or FORMAT command Example of explicitly configuring: RMAN> configure controlfile autobackup format for device type disk to '/ora01/O11R2/rman/rman_ctl_%F.bk';

Backing Up Archive-Redo Logs You should backup the archive redo logs as part of your regular backup strategy RMAN> backup database plus archivelog;

Determining the Location for the Snapshot Control File Author recommends to just use the default setting Sufficient for most scenarios

Using a Recovery Catalog Author typically does not use a recovery catalog. However be aware that there are some significant advantages to using a recovery catalog: Provides a secondary repository for RMAN metadata. If you lose all your control files and backups of your control files, you can still retrieve RMAN metadata from the recovery catalog. Stores RMAN metadata for a much longer period than is possible when you just use a control file for the repository. Provides access to all RMAN features. Some restore and recovery features are simpler when using a recovery catalog.

Using a Media Manager Depends on your business requirements. Some shops may have a requirement to write backups of large databases directly to tape. Requires a MML and extra moving parts to enable.

Setting the CONTROL_FILE_RECORD_KEEP_TIME Initialization Parameter Usually the default of 7 days is sufficient

Configuring RMAN’s Backup-Retention Policy Depends on your business requirements. Author recommends something like: RMAN> configure retention policy to redundancy 2;

Configuring the Archive-Redo Logs’ Deletion Policy Have RMAN delete the archive-redo logs based on the retention policy of the database backups. This is the default behavior.

Setting the Degree of Parallelism Depends on your hardware. If you have multiple CPUs and disks then consider setting parallelism to 2 or more.

Using Backup Sets or Image Copies Usually backup sets are more efficient. Backup sets don’t include blocks that haven’t been used.

Using Incremental Backups Take full or level 0 backups if you have the disk space and resources. If you don’t have the disk space, then use an incremental strategy.

Using Incrementally Updated Backups Incrementally updated backups are an efficient way to implement an image-copy backup strategy. If you prefer image copies to backup sets, then consider using an incrementally updated backup strategy.

Using Block-Change Tracking Keeps track of which blocks have been modified since the prior backup. For large databases, this can considerably reduce the time required to perform incremental level 1 backups.

Configuring Binary Compression Makes the backups much smaller. But takes more time for backup and restore operations. Depends on your business requirements.

Configuring Encryption Depends on your business requirements. Do you ship backups offsite?

Configuring Miscellaneous Settings Maximum backup-set size Maximum backup-piece size Maximum rate Maximum open files

Scripting an RMAN Backup 1 #!/bin/bash 2 HOLDSID=${1} # SID name 3 PRG=`basename $0` 4 USAGE="Usage: ${PRG} " 5 if [ -z "${HOLDSID}" ]; then 6 echo "${USAGE}" 7 exit 1 8 fi

Summary Spend some time and carefully consider all of the RMAN architectural implementation decisions. There is no right or wrong way (for most of the decisions). Many depend on your B&R business requirements.