Configuring RMAN
Oracle Recovery Manager (RMAN) is Oracle’s flagship B&R tool. RMAN is provided by default when you install the Oracle software (for both the Standard Edition and Enterprise Edition). RMAN offers a robust and flexible set of B&R features. The following list highlights some of the most salient qualities:
- Easy-to-use commands for backup, restore, and recovery.
- Ability to track which files have been backed up and where to. 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.
- Recovery at the database, tablespace, data file, table, or block level.
- Advanced 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 proposing solutions.
- Ability to detect corrupt blocks in data files.
- Advanced reporting capabilities from the RMAN command line.
The goal of this chapter is to present enough information about RMAN that you can make reasonable decisions about how to implement a solid backup strategy. The basic RMAN components are described first, after which you walk through many of the decision points involved in implementing RMAN.
Note The RMAN-related chapters in this book aren’t intended to be a complete reference on all aspects of B&R. That would take an entire book. These chapters contain the basic information you need to successfully use RMAN for B&R. If you require advanced RMAN information regarding backup, restore, and recovery, see RMAN Recipes for Oracle Database 12c, second edition, by Darl Kuhn (Apress, 2013).
Understanding RMAN
RMAN consists of many different components. Figure 17-1 shows the interactions of the main RMAN pieces. Refer back to this diagram when reading through this section.
Figure 17-1. RMAN architectural components
The following list describes the RMAN architectural components:
- DBA: Appears somewhat short and bald in the diagram, which isn’t far from the truth (in my case).
- Target database: The database being backed up by RMAN. You connect to the target database with the RMAN command-line T ARGET parameter (see the next section for more details).
- RMAN client: The rman utility from which you issue B ACKUP, R ESTORE, and R ECOVER commands. On most database servers the rman utility is located in the ORACLE_HOME/bin directory (along with all the other Oracle utilities, such as sqlplus and expdp).
- Oracle server processes: When you execute the rman client and connect to the target database, two Oracle server background processes are started. The first default server process interacts with the PL/SQL packages to coordinate the backup activities. The secondary polling process occasionally updates Oracle data dictionary structures.
- Channel (s): The Oracle server processes for handling I/O between files being backed up (or restored) and the backup device (disk or tape).
- PL/SQL packages: RMAN uses two internal PL/SQL packages (owned by SYS) to perform B&R tasks: DBMS_RCVMAN and DBMS_BACKUP_RESTORE. DBMS_RCVMAN accesses information in the control file and passes that to the RMAN server processes. The DBMS_BACKUP_RESTORE package performs most of RMAN’s work. For example, this package creates the system calls that direct the channel processes to perform B&R operations.
- Memory buffers (PGA or SGA): RMAN uses a memory area in the PGA (and sometimes in the SGA) as a buffer when reading from data files and copying subsequent blocks to back up files.
- Auxiliary database: A database to which RMAN restores target database data files for the purpose of duplicating a database, creating a Data Guard standby database, or performing a DBPITR.
- Backup/Back up: Can be either a noun or a verb. The physical files (backup) that store the backed up files; or, the act of copying and archiving (backing up) files. Backups can consist of backup sets and backup pieces or image copies.
- Backup set: When you run an RMAN BACKUP command, by default, it creates one or more backup sets. A backup set is a logical RMAN construct that groups backup piece files. You can think of the relationship of a backup set to a backup piece as similar to the relationship between a tablespace and a data file: one is a logical construct, the other is a physical file.
- Backup piece file: RMAN binary backup files. Each logical backup set consists of one or more backup piece files. These are the physical files that RMAN creates on disk or tape. They’re binary, proprietary format files that only RMAN can read or write to. A backup piece can contain blocks from many different data files. Backup piece files are typically smaller than data files, because backup pieces only contain blocks that have been used in the data files.
- Image copy: Initiated with the BACKUP AS COPY command. A type of backup in which RMAN creates identical copies of a data file, archive redo log file, or control file. Image copies can be operated on by OS utilities such as the Linux cp and mv commands. Image copies are used as part of incrementally updated image backups. Sometimes, it’s preferable to use image copies rather than backup sets if you need to be able to restore quickly.
- Recovery catalog: An optional database schema that contains tables used to store metadata information regarding RMAN backup operations. Oracle strongly recommends using a recovery catalog, because it provides more options for B&R.
- Media manager: Third-party software that allows RMAN to back up files directly to tape. Backing up to tape is desirable when you don’t have enough room to back up directly to disk or when disaster recovery requirements necessitate a backup to storage that can be easily moved offsite.
- FRA: An optional disk area that RMAN can use for backups. You can also use the FRA to multiplex control files and online redo logs. You instantiate a fast recovery with the database initialization parameters DB_RECOVERY_FILE_DEST_SIZE and DB_RECOVERY_FILE_DEST.
- Snapshot control fil e: RMAN requires a read-consistent view of the control file when either backing up the control file or synchronizing with the recovery catalog (if it’s being used). In these situations, RMAN first creates a temporary copy (snapshot) of the control file. This allows RMAN to use a version of the control file that is guaranteed not to change while backing up the control file or synchronizing with the recovery catalog.
You can make several types of backups with RMAN:
- Full backup: All modified blocks associated with the data file are backed up. A full backup is not a backup of the entire database. For example, you can make a full backup of one data file.
- Incremental level 0 backup: Backs up the same blocks as a full backup. The only difference between a level 0 backup and a full backup is that you can use a level 0 backup with other incremental backups, but not a full backup.
- Incremental level 1 backup: Backs up only blocks that have been modified since the previous backup. Level 1 incremental backups can be either differential or cumulative. A differential level 1 backup is the default and backs up all blocks that have been modified since the last level 0 or level 1 backup. A cumulative level 1 backup backs up all blocks that have changed since the last level 0 backup.
- Incrementally updated backup: First creates an image copy of the data files, after which subsequent backups are incremental backups that are merged with the image copy. This is an efficient way to use image copies for backups. Media recoveries using incrementally updated backups are fast because the image copy of the data file is used during the restore.
- Block change tracking: Database feature that keeps track of blocks that have changed in the database. A record of the changed blocks is kept in a binary file. RMAN can use the contents of the binary file to improve the performance of incremental backups: instead of having to scan all modified blocks in a data file, RMAN can determine which blocks have changed from the binary block change tracking.
Now that you understand the RMAN architectural components and the types of backups you can make, you’re ready to start up RMAN and configure it for your environment.
Starting RMAN
To connect to RMAN, you need to establish
- OS environment variables
- access to a privileged OS account or a database user with SYSDBA privileges
The easiest way to connect to RMAN is to log in to the server on which the target database resides as the owner of the Oracle software (usually named oracle, on Linux/Unix boxes). When you log in as oracle, you need to establish several OS variables before you can use utilities such as rman and sqlplus. Setting these required OS variables is covered in detail in Chapter 2.
At minimum, you need to set ORACLE_HOME and ORACLE_SID. Additionally, it’s convenient if the PATH variable includes the directory ORACLE_HOME/bin. This is the directory that contains the Oracle utilities.
After you’ve established your OS variables, you can invoke RMAN from the OS, as shown:
$ rman target /
When connecting to RMAN, you don’t have to specify the AS SYSDBA clause (as you do when connecting to a database as a privileged user in SQL*Plus). This is because RMAN always requires that you connect as a database user with SYSDBA privileges.
Tip New in Oracle Database 12c, the SYSBACKUP privilege allows you to assign privileges to a user that include only the permissions needed to perform B&R operations. The SYSBACKUP privilege contains the subset of SYSDBA privileges required for carrying out such operations.
The previous example of logging in to RMAN uses OS authentication. This type of authentication means that if you can log in to an authorized OS account (such as the owner of the Oracle software, usually oracle), then you’re allowed to connect to the database without having to provide a username and password. You administer OS authentication by assigning special groups to OS accounts. When you install the Oracle binaries in a Linux/Unix environment, you’re required to specify at the time of installation the names of the OS groups that are assigned the database privileges of SYSDBA, SYSOPER, SYSBACKUP—typically, the dba, oper, and backupdba groups, respectively (see Chapter 1 for details).
(NOT) CALLING RMAN FROM SQL*PLUS
I teach Oracle B&R classes at a local institute of higher learning. Nearly every term, one of the students asks why the following RMAN command doesn’t work:
SQL> rman
SP2-0042: unknown command "rman" - rest of line ignored.
The answer is short: the rman client is an OS utility, not an SQL*Plus function. You must invoke the rman client from the OS prompt.
If you don’t have access to log in directly to a server as the Oracle software owner, you need a privileged database user account to connect to RMAN. Granting SYSDBA privileges to database users requires that you first implement a password file. To create a password file on Linux/Unix servers, first navigate to the ORACLE_HOME/dbs directory, and then use the orapwd utility to create a password file:
$ cd $ORACLE_HOME/dbs
$ orapwd file=orapw<ORACLE_SID> password=<sys password>
Before you grant SYSDBA to a database user, ensure that the initialization parameter REMOTE_LOGIN_PASSWORDFILE is set to EXCLUSIVE (the default):
SQL> show parameter remote_login_passwordfile
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
remote_login_passwordfile string EXCLUSIVE
You can now grant the SYSDBA privilege to a database user:
SQL> grant sysdba to lellison;
You can view the users that have SYSDBA privileges via the following query:
SQL> select * from v$pwfile_users;
Note If you want to connect remotely to RMAN via Oracle Net, you need to first implement a password file.
RMAN Architectural Decisions
If archiving is enabled for your database (see Chapter 5 for details on archiving), you can use RMAN out of the box to run commands such as this to back up your entire target database:
$ rman target /
RMAN> backup database;
If you experience a media failure, you can restore all data files, as follows:
RMAN> shutdown immediate;
RMAN> startup mount;
RMAN> restore database;
After your database is restored, you can fully recover it:
RMAN> recover database;
RMAN> alter database open;
You’re good to go, right? No, not quite. RMAN’s default attributes are reasonably set for simple backup requirements. The RMAN out-of-the-box settings may be appropriate for small development or test databases. But, for any type of business critical database, you need to consider carefully where the backups are stored, how long to store backups on disk or tape, which RMAN features are appropriate for the database, and so on. The following sections in this chapter walk you through many of the B&R architectural decisions necessary to implementing RMAN in a production environment. RMAN has a vast and robust variety of options for customizing B&R; and, typically, you don’t need to implement many of RMAN’s features. However, each time you implement RMAN to back up a production database, you should think through each decision point and decide whether you require an attribute.
Table 17-1 summarizes the RMAN implementation decisions and recommendations. Each of the decision points in the table is elaborated on in subsequent sections. Many DBAs will have differing opinions concerning some of these recommendations; that’s fine. The point is that you need to consider each architectural aspect and determine what makes sense for your business requirements.
Table 17-1. Overview of Architectural Decisions and Recommendations
Running the RMAN Client Remotely or Locally
It’s possible to run the rman utility from a remote server and connect to a target database via Oracle Net:
$ rman target sys/foo@remote_db
This allows you to run RMAN backups on disparate remote servers from one central location. When you run RMAN remotely, the backup files are always created on the target database server.
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, you may establish that the remote rman executable you’re running is an Oracle Database 12c version of the RMAN client and need to determine if it’s possible to connect that client to a remote Oracle Database 9i target database. If you run the rman client locally on the target server, there is never a compatibility issue because the rman client is always the same version as the target database.
As discussed previously, 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 is how I connect to RMAN from the command line:
$ rman target /
Some DBAs don’t use this approach; they opt to set up a user separate from SYS and cite security concerns as a rationale 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 that 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.
Using Online or Offline Backups
Most production databases have 24-7 availability requirements. Therefore, your only option is online RMAN backups. Your database must be in archivelog mode for online backups. You need to consider carefully 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 that it can read from and write to the control file.
Setting the Archive Redo Log Destination and File Format
Enabling archive redo log mode is a prerequisite for making online backups (see Chapter 5 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 to the FRA as well as to several other locations that you manually set via initialization parameters):
- Default location
- FRA
- Location specified via the 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 directory. The default file name format for archive redo logs is %t_%s_%r.dbf.
If you enable an FRA (and don’t set LOG_ARCHIVE_DEST_N), then, by default, the archive redo logs are written to a directory in the FRA. The default file name format of the of archive redo log files created in the FRA is an OMF format. The files are stored in a subdirectory given the same name as the database’s unique name; for example,
/<fra>/<dbuname>/archivelog/<YYYY_MM_DD>/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’s filling up and not being purged of old files quickly enough. Instead, I use the LOG_ARCHIVE_DEST_N parameter to set the location of the archive redo log files. Here is an example:
log_archive_dest_1='LOCATION=/oraarch1/CHNPRD'
I also prefer to use this format for the default archivelog file name:
log_archive_format='%t_%s_%r.arc'
Sometimes, DBAs use .dbf as an extension for both data files and archive redo log files. I prefer to use .arc for the archive redo log files. The .arc extension avoids the potentially confusing task of identifying a file as an archive redo log file or a live database data file.
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:
- Default location
- FRA
- Location specified via the BACKUP... FORMAT command
- Location specified via the CONFIGURE CHANNEL...FORMAT command
Of these choices, I lean toward the last of them; I prefer specifying a target location via a backup channel.
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;
The default 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 OMF format; for example,
<ORACLE_HOME>/dbs/01ln9g7e_1_1
Tip The default location is okay for small development databases. However, for most other environments (especially production), you’ll need to plan ahead for how much disk space you’ll need for backups and explicitly set the location for the backups via one of the other methods (such as implementing an FRA or CONFIGURE CHANNEL).
When backing up to disk, if you don’t explicitly instruct RMAN to write the backups to a specific location (via the F ORMAT or C ONFIGURE command), and you’re using an FRA, RMAN automatically writes the backup files to directories in the FRA. The files are stored in a subdirectory with the same name as the database’s unique name. Also, the default format of the name of the backup files created in the FRA is an OMF format; for example,
/<fra>/<dbuname>/backupset/<YYYY_MM_DD>/o1_mf_nnndf_TAG20100907T025402_68czfbdf_.bkp
I don’t usually 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 entirety 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 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.
BACKUP…FORMAT
If you’ve configured an FRA and don’t want to place RMAN backup files in the FRA automatically, you can directly specify where you want backups to be placed when you issue the BACKUP command; for example,
RMAN> backup database format '/u01/O12C/rman/rman_%U.bkp';
Here is a corresponding file generated by RMAN:
/u01/O12C/rman/rman_0jnv0557_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 the BACKUP command, you see this message:
RMAN> backup database format '/u01/O12C/rman/rman_%U.bkp';
RMAN allocates multiple channels and writes in parallel to two different backup files. The U% in the format string guarantees that unique file names are created.
I don’t usually 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 frequently writing to multiple disk locations and need the flexibility to specify directories located on different mount points. Here is a typical configuration specifying CONFIGURE CHANNEL...FORMAT:
RMAN> configure device type disk parallelism 3;
RMAN> configure channel 1 device type disk format '/u01/O12C/rman/rman1_%U.bk';
RMAN> configure channel 2 device type disk format '/u02/O12C/rman/rman2_%U.bk';
RMAN> configure channel 3 device type disk format '/u03/O12C/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 instance, if you specify a degree of parallelism of 2, RMAN allocates only two channels, regardless of the number of channels you configured via the C ONFIGURE CHANNEL command.
In this example of configuring three channels, suppose the BACKUP command is issued, like this:
RMAN> backup database;
RMAN allocates three channels, all on separate mount points (/u01, /u02, /u03), 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.
If you need to unconfigure a channel, do so as follows:
RMAN> configure channel 3 device type disk clear;
Note Also consider what happens if you configure a degree of parallelism higher than the number of preconfigured channels. RMAN will open a channel for each degree of parallelism, and if the number of channels opened is greater than the number of preconfigured channels, for the unconfigured channels, RMAN will write backup files to the FRA (if configured) or the default location.
Setting the Autobackup of the Control File
You should always configure RMAN to back up the control file automatically 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 data file). Use the SHOW command to display the current setting of the control file autobackup:
RMAN> show controlfile autobackup;
Here is some sample output:
RMAN configuration parameters for database with db_unique_name O12C are:
CONFIGURE CONTROLFILE AUTOBACKUP ON;
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 data file 1 (SYSTEM tablespace data file), RMAN automatically backs up the control file.
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 CONFIGURE CONTROLFILE AUTOBACKUP 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 Linux/Unix environments the default location is ORACLE_HOME/dbs; for example,
/u01/app/oracle/product/12.1.0.1/db_1/dbs/c-3423216220-20130109-01
If you’ve enabled an FRA, then RMAN automatically writes the control file autobackup files to directories in the FRA, using an OMF format for the name; for example,
/<fra>/<dbuname>/autobackup/<YYYY_MM_DD>/o1_mf_s_729103049_68fho9z2_.bkp
I don’t usually 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 is an example:
RMAN> configure controlfile autobackup format for device type disk to
'/u01/O12C/rman/rman_ctl_%F.bk';
If you want to set the autobackup format back to the default, do so as follows:
RMAN> configure controlfile autobackup format for device type disk clear;
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 since the last good RMAN backup.
Generally, I instruct RMAN to back up the archive redo logs while the data files are being backed up. This is a sufficient strategy in most situations. Here is the command to back up the archive redo logs along with the data files:
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 frequency different from that of the data files. DBAs may 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, if a data file has experienced media failure, you need to restore the data file from a backup and then apply any archive redo logs that were generated during and after the backup of the data file.
On some occasions, you may need archive redo logs that were generated before the last backup. For instance, 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.
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
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/format is ORACLE_HOME/dbs/[email protected]. Note that the default location isn’t in the FRA (even if you’ve implemented an FRA).
You can display the current snapshot control file details, using the SHOW command:
RMAN> show snapshot controlfile name;
Here is some sample output:
CONFIGURE SNAPSHOT CONTROLFILE NAME TO
'/ora01/app/oracle/product/12.1.0.1/db_1/dbs/snapcf_o12c.f'; # default
For most situations the default location and format of the snapshot control file are sufficient. This file doesn’t use much space or have any intensive I/O requirements. I recommend that you use the default setting.
If you have a good reason to configure the snapshot control file to a nondefault location, you can do so as follows:
RMAN> configure snapshot controlfile name to '/u01/O12C/rman/snapcf.ctl';
If you accidentally configure the snapshot control file location to a nonexistent directory, then when running a BACKUP or COPY command, the autobackup of the control file will fail, with this error:
ORA-01580: error creating control backup file ...
You can set the snapshot control file back to the default, like this:
RMAN> configure snapshot controlfile name clear;
RMAN always stores its latest backup operations in the target database control file. You can set up an optional recovery catalog to store metadata regarding RMAN backups. The recovery catalog is a separate schema (usually in a database different from that of the target database) that contains database objects (tables, indexes, and so on) that store the RMAN backup information. The recovery catalog doesn’t store RMAN backup pieces—only backup metadata.
The main advantages of using a recovery catalog are as follows:
- 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.
- Offers access to all RMAN features. Some restore and recovery features are simpler when using a recovery catalog.
The disadvantage of using a recovery catalog is that this is another database you have to set up, maintain, and back up. Additionally, when you start a backup and attempt to connect to the recovery catalog, if the recovery catalog isn’t available for any reason (server down, network issues, and so on), you must decide whether you want to continue with the backup without a recovery catalog.
You must also be aware of versioning aspects when using a recovery catalog. You need to make sure the version of the database you use to store the recovery catalog is compatible with the version of the target database. When you upgrade a target database, be sure the recovery catalog is upgraded (if necessary).
Note See Chapter 18 for details on how to implement a recovery catalog.
RMAN works fine with or without a recovery catalog. For several of the databases I maintain, I don’t use a recovery catalog; this eliminates having to set it up and maintain it. For me, simplicity takes precedence over the features available with the recovery catalog.
However, if you have good business reasons for using a recovery catalog, then implement and use one. The recovery catalog isn’t that difficult to set up and maintain, and Oracle recommends that you use it.
A media manager is required for RMAN to back up directly to tape. Several vendors provide this feature (for a cost). Media managers are used in large database environments, such as data warehouses, in which you may not have enough room to back up a database to disk. You may also have a disaster recovery requirement to back up directly to tape.
If you have such requirements, then you should purchase a media management package and implement it. If you don’t need to back up directly to tape, there’s no need to implement a media manager. RMAN works fine backing up directly to disk.
Keep in mind that many shops use RMAN to back up directly to disk and then have the system administrator back up the RMAN backups to tape afterward. If you do this, you have to be sure your RMAN backups aren’t running while the tape backups are running (because you may get partial files backed up to tape).
Tip See Chapter 20 for details on how to implement Oracle Secure Backup as a media management layer.
Setting the CONTROL_FILE_RECORD_KEEP_TIME Initialization Parameter
The CONTROL_FILE_RECORD_KEEP_TIME initialization parameter specifies the minimum number of days a reusable record in the control file is retained before the record can be overwritten. The RMAN metadata are stored in the reusable section of the control file and therefore are eventually overwritten.
If you’re using a recovery catalog, then you don’t need to worry about this parameter because RMAN metadata are stored in the recovery catalog indefinitely. Therefore, when you use a recovery catalog, you can access any historical RMAN metadata.
If you’re using only the control file as the RMAN metadata repository, then the information stored there will eventually be overwritten. The default value for CONTROL_FILE_RECORD_KEEP_TIME is 7 days:
SQL> show parameter control_file_record_keep_time
NAME TYPE VALUE
------------------------------------ ----------- -----
control_file_record_keep_time integer 7
You can set the value to anything from 0 to 365 days. Setting the value to 0 means that the RMAN metadata information can be overwritten at any time.
The CONTROL_FILE_RECORD_KEEP_TIME parameter was more critical in older versions of Oracle, in which it wasn’t easy to repopulate the control file with RMAN information, in the event that metadata were overwritten. Starting with Oracle Database 10g, you can use the C ATALOG command to quickly make the control file aware of RMAN backup files.
If you run daily backups, then I recommend that you leave this parameter at 7 days. However, if you only back up your database once a month, or if, for some reason, you have a retention policy greater than 7 days, and you’re not using a recovery catalog, then you may want to consider increasing the value. The downside to increasing this parameter is that if you have a significant amount of RMAN backup activity, this can increase the size of your control file.
Configuring RMAN’s Backup Retention Policy
RMAN retention policies allow you to specify how long you want to retain backups. RMAN has two mutually exclusive methods of specifying a retention policy:
- Recovery window
- Number of backups (redundancy)
Recovery Window
With a recovery window, you specify a number of days in the past for which you want to be able recover to any point in that window. For example, if you specify a retention policy window of 5 days, then RMAN doesn’t mark as obsolete backups of data files and archive redo logs that are required to be able to restore to any point in that 5-day window:
RMAN> configure retention policy to recovery window of 5 days;
For the specified recovery, RMAN may need backups older than the 5-day window because it may need an older backup to start with to be able to recover to the recovery point specified. For example, suppose your last good backup was made 6 days ago, and now you want to recover to 4 days in the past. For this recovery window, RMAN needs the backup from 6 days ago to restore and recover to the point specified.
You can also specify that RMAN keep a minimum number of backups. For instance, if redundancy is set to 2, then RMAN doesn’t mark as obsolete the latest two backups of data files and archive redo log files:
RMAN> configure retention policy to redundancy 2;
I find that a retention policy based on redundancy is easier to work with and more predictable with regard to how long backups are retained. If I set redundancy to 2, I know that RMAN won’t mark as obsolete the latest two backups. In contrast, the recovery window retention policy depends on the frequency of the backups and the window length to determine whether a backup is obsolete.
Deleting Backups, Based on Retention Policy
You can report on backups that RMAN has determined to be obsolete per the retention policy, as follows:
RMAN> report obsolete;
To delete obsolete backups, run the D ELETE OBSOLETE command:
RMAN> delete obsolete;
You’re prompted with this:
Do you really want to delete the above objects (enter YES or NO)?
If you’re scripting the procedure, you can specify the delete not to prompt for input:
RMAN> delete noprompt obsolete;
I usually have the D ELETE NOPROMPT OBSOLETE command coded into the shell script that backs up the database. This instructs RMAN to delete any obsolete backups and obsolete archive redo logs, as specified by the retention policy (see the section “Segueing from Decisions to Action,” later in this chapter, for an example of how to automate the deleting of obsolete backups with a shell script).
Clearing the Retention Policy
The default retention policy is redundancy of 1. You can completely disable the RMAN retention policy via the TO N ONE command.
RMAN> configure retention policy to none;
When the policy is set to NONE, no backups are ever considered obsolete and therefore cannot be removed via the DELETE OBSOLETE command. This normally is not the behavior you want. You want to let RMAN delete backups per a retention policy based on a window or number of backups.
To set the retention policy back to the default, use the CLEAR command:
RMAN> configure retention policy clear;
Configuring the Archive Redo Logs’ Deletion Policy
In most scenarios, I have RMAN delete the archive redo logs based on the retention policy of the database backups. This is the default behavior. You can view the database retention policy, using the SHOW command:
RMAN> show retention policy;
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
To remove archive redo logs (and backup pieces) based on the database retention policy, run the following:
RMAN> delete obsolete;
As of Oracle Database 11g, you can specify an archive redo log deletion policy that is separate from that of the database backups. This deletion policy applies to archive redo logs both outside and in the FRA.
Note Prior to Oracle Database 11g the archive deletion policy only applied to archive redo logs associated with a standby database.
To configure an archive redo log deletion policy, use the C ONFIGURE ARCHIVELOG DELETION command. The following command configures the archive redo deletion policy so that archive redo logs aren’t deleted until they have been backed up twice to disk:
RMAN> configure archivelog deletion policy to backed up 2 times to device type disk;
To have RMAN delete obsolete archive redo logs, as defined by the archivelog deletion policy, issue the following command:
RMAN> delete archivelog all;
Tip Run the C ROSSCHECK command before running the D ELETE command. Doing so ensures that RMAN is aware of whether a file is on disk.
To see whether a retention policy has been set specifically for the archive redo log files, use this command:
RMAN> show archivelog deletion policy;
To clear the archive deletion policy, do this:
RMAN> configure archivelog deletion policy clear;
Setting the Degree of Parallelism
You can significantly increase the performance of RMAN backup and restore operations if your database server is equipped with the hardware to support multiple channels. If your server has multiple CPUs and multiple storage devices (disks or tape devices), then you can improve performance by enabling multiple backup channels.
If you require better performance from backup and restore operations and have hardware that facilitates parallel operations, you should enable parallelism and perform tests to determine the optimal degree. If your hardware can take advantage of parallel RMAN channels, there is little downside to enabling parallelism.
If you have multiple CPUs, but just one storage device location, you can enable multiple channels to write to and read from one location. For example, if you’re backing up to an FRA, you can still take advantage of multiple channels by enabling parallelism. Suppose you have four CPUs on a server and want to enable a corresponding degree of parallelism:
RMAN> configure device type disk parallelism 4;
You can also write to separate locations in parallel by configuring multiple channels associated with different mount points; for example,
RMAN> configure device type disk parallelism 4;
RMAN> configure channel 1 device type disk format '/u01/O12C/rman/rman1_%U.bk';
RMAN> configure channel 2 device type disk format '/u02/O12C/rman/rman2_%U.bk';
RMAN> configure channel 3 device type disk format '/u03/O12C/rman/rman3_%U.bk';
RMAN> configure channel 4 device type disk format '/u04/O12C/rman/rman4_%U.bk';
This code configures four channels that write to separate locations on disk. When you configure separate channels for different locations, make sure you enable the degree of parallelism to match the number of configured device channels. If you allocate more channels than the specified degree of parallelism, RMAN only writes to the number of channels specified by the degree of parallelism and ignores the other channels.
If you need to clear the degree of parallelism, you can do so as follows:
RMAN> configure device type disk clear;
Similarly, to clear the channel device types, use the C LEAR command. This example clears channel 4:
RMAN> configure channel 4 device type disk clear;
Using Backup Sets or Image Copies
When you issue an RMAN BACKUP command, you can specify that the backup be one of the following:
- Backup set
- Image copy
A backup set is the default type of RMAN backup. A backup set contains backup pieces, which are binary files that only RMAN can write to or read from. Backup sets are desirable because they’re generally smaller than the data files being backed up. If you’re using Oracle Database 10g Release 2 or higher, RMAN automatically attempts to create backup pieces with unused block compression. In this mode, RMAN reads a bitmap to determine which blocks are allocated and only reads from those blocks in the data files. This feature is supported only for disk-based backup sets and Oracle Secure Backup tape backups.
If you’re using a database version prior to Oracle Database 10g Release 2, by default, backup sets are created, using null block compression (sometimes referred to, more aptly, as block skipping). In this mode, RMAN checks blocks in the data file; if the blocks haven’t been used, they aren’t backed up.
Note RMAN can also create backup sets using true binary compression. This is the type of compression you get from an OS compression utility (such as zip). Oracle supports several levels of binary compression. The B ASIC compression algorithm is available without an additional license. Oracle provides further compression features with the Oracle Advanced Compression option (see the section “Configuring Binary Compression,” later in this chapter, for details on how to enable binary compression).
When you create a backup as a backup set, the binary backup piece files can only be manipulated by RMAN processes. Some DBAs view this as a disadvantage because they must use RMAN to back up and restore these files (you have no direct access to or control over the backup pieces). But, these perceptions aren’t warranted. Unless you hit a rare bug, RMAN is dependable and works reliably in all backup-and-restore situations.
Contrast the backup set with an image copy. An image copy creates a byte-for-byte identical copy of each data file. The advantage of creating an image copy is that (if necessary) you can manipulate the image copy without using RMAN (as with an OS copy utility). Additionally, in the event of a media failure, an image copy is a fast method of restoring data files, because RMAN only has to copy the file back from the backup location (there is no reconstructing of the data file, because it’s an exact copy).
I almost always use backup sets for database backups, rather than image copies. Usually, I require some form of RMAN compression (block skipping). The size of the backup to disk is almost always a concern. Backup sets are more efficient regarding disk space consumption. Because backup sets can take advantage of RMAN compression, there is also less I/O involved, compared with an image copy. In many environments, reducing the I/O so as not to impact other applications is a concern.
However, if you feel that you need direct control over the backup files that RMAN creates, or you’re in an environment in which the speed of the restore process is paramount, consider using image copies.
For most of the databases I’m responsible for, I run a daily level 0 backup. I don’t usually implement any type of incremental backup strategy.
Incremental backup strategies are appropriate for large databases in which only a small portion of the database blocks change from one backup to the next. If you’re in a data warehouse environment, you may want to consider an incremental backup strategy, because it can greatly reduce the size of your backups. For example, you may want to run a weekly level 0 backup and then run a daily level 1 incremental backup.
Note See Chapter 18 for details on how to back up a database using incremental backups.
Using Incrementally Updated Backups
Incrementally updated backups are an efficient way to implement an image copy backup strategy. This technique instructs RMAN to first create image copies of data files; then, the next time the backup runs, instead of creating a fresh set of image copies, RMAN makes an incremental backup (changes to blocks since the image copy was created) and applies that incremental backup to the image copies.
If you have the disk space available for full image copies of your database and you want the flexibility to use the image copies directly, in the event of a media failure, consider this backup strategy.
One potential disadvantage of this approach is that if you’re required to restore and recover to some point in the past, you can only restore and recover to the point at which the image copies were last updated with the incremental backup.
Note See Chapter 18 for details on how to back up a database using incrementally updated backups.
This feature keeps track of when a database block changes. The idea is that if you’re using an incremental backup strategy, you can enhance performance, because by implementing this feature, RMAN doesn’t have to scan each block (under the high-water mark) in the data files to determine whether it needs to be backed up. Rather, RMAN only has to access the block change tracking file to find which blocks have changed since the last backup and directly access those blocks. If you work in a large, data warehouse environment and are using an incremental backup strategy, consider enabling block change tracking to enhance performance.
Note See Chapter 18 for details on how to implement block change tracking.
Configuring Binary Compression
You can configure RMAN to use true binary compression when generating backup sets. You can enable compression in one of two ways:
- Specify AS COMPRESSED BACKUPSET with the B ACKUP command.
- Use a one-time C ONFIGURE command.
Here is an example of backing up with compression when issuing the B ACKUP command:
RMAN> backup as compressed backupset database;
In this example, compression is configured for the disk device:
RMAN> configure device type disk backup type to compressed backupset;
If you need to clear the device-type compression, issue this command:
RMAN> configure device type disk clear;
I’ve found the default compression algorithm to be quite efficient. For a typical database the backups are usually approximately four to five times smaller than the regular backups. Of course, your compression results may vary, depending on your data.
Why not compress all backups? Compressed backups consume more CPU resources and take longer to create and restore from, but they result in less I/O, spread out over a longer period. If you have multiple CPUs, and the speed of making a backup isn’t an issue, then you should consider compressing your backups.
You can view the type of compression enabled, using the S HOW command:
RMAN> show compression algorithm;
Here is some sample output:
CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT'
OPTIMIZE FOR LOAD TRUE ; # default
The basic compression algorithm doesn’t require an extra license from Oracle. If you’re using Oracle Database 11g Release 2 or higher, and if you have a license for the Advanced Compression option, then you have available three additional configurable levels of binary compression; for example,
RMAN> configure compression algorithm 'HIGH';
RMAN> configure compression algorithm 'MEDIUM';
RMAN> configure compression algorithm 'LOW';
In my experience the prior compression algorithms are very efficient, both in compression ratios and time taken to create backups.
You can query V$RMAN_COMPRESSION_ALGORITHM to view details regarding the compression algorithms available for your release of the database. To reset the current compression algorithm to the default of BASIC, use the CLEAR command:
RMAN> configure compression algorithm clear;
Configuring Encryption
You may be required to encrypt backups. Some shops especially require this for backups that contain sensitive data and that are stored offsite. To use encryption when backing up, you must use the Oracle Enterprise Edition, possess a license for the Advanced Security option, and use Oracle Database 10g Release 2 or higher.
If you’ve configured a security wallet (see the Oracle Advanced Security Administrator’s Guide, which can be freely downloaded from the Technology Network area of the Oracle website (http://otn.oracle.com, for details), you can configure transparent encryption for backups, as shown:
RMAN> configure encryption for database on;
Any backups that you make now will be encrypted. If you need to restore from a backup, it’s automatically unencrypted (assuming the same security wallet is in place as when you encrypted the backup). To disable encryption, use the C ONFIGURE command:
RMAN> configure encryption for database off;
You can also clear the encryption setting with CLEAR:
RMAN> configure encryption for database clear;
You can query V$RMAN_ENCRYPTION_ALGORITHMS to view details regarding the encryption algorithms available for your release of the database.
RUNNING SQL FROM WITHIN RMAN
Starting with Oracle Database 12c, you can run SQL statements (and see the results) directly from within RMAN:
RMAN> select * from v$rman_encryption_algorithms;
Prior to 12c, you could run the prior SQL statement with the RMAN sql command, but no results would be displayed:
RMAN> sql 'select * from v$rman_encryption_algorithms';
The RMAN sql command was meant more for running commands such as ALTER SYTEM:
RMAN> sql 'alter system switch logfile';
Now, in 12c, you can run the SQL directly:
RMAN> alter system switch logfile;
This ability to run SQL from within RMAN is a really nice enhancement; it allows you to see the results of SQL queries and eliminates the need for specifying the sql keyword as well as for placing quotation marks around the SQL command itself.
Configuring Miscellaneous Settings
RMAN provides a flexible number of channel configuration commands. You will occasionally need to use them, depending on special circumstances and the requirements for your database. Here are some of the options:
- Maximum backup set size
- Maximum backup piece size
- Maximum rate
- Maximum open files
By default the maximum backup set size is unlimited. You can use the MAXSETSIZE parameter with the CONFIGURE or BACKUP command to specify the overall maximum backup set size. Make sure the value of this parameter is at least as great as the largest data file being backed up by RMAN. Here is an example:
RMAN> configure maxsetsize to 2g;
Sometimes, you may want to limit the overall size of a backup piece because of physical limitations of storage devices. Use the MAXPIECESIZE parameter of the CONFIGURE CHANNEL or ALLOCATE CHANNEL command do this; for example,
RMAN> configure channel device type disk maxpiecesize = 2g;
If you need to set the maximum number of bytes that RMAN reads each second on a channel, you can do so, using the RATE parameter. This configures the maximum read rate for channel 1 to 200MB per second:
configure channel 1 device type disk rate 200M;
If you have a limit on the number of files you can have open simultaneously, you can specify a maximum open files number via the MAXOPENFILES parameter:
RMAN> configure channel 1 device type disk maxopenfiles 32;
You may need to configure any of these settings when you need to make RMAN aware of some OS or hardware limitation. You’ll rarely need to use these parameters but should know of them.
Note New with 12c, you can configure the number of days RMAN will store output logging of commands within V$RMAN_OUTPUT. You can configure the number of days worth of commands to log via the CONFIGURE RMAN OUTPUT TO KEEP FOR command.
Configuring Informational Output
A good practice is to always set the OS NLS_DATE_FORMAT variable (before running RMAN) so that both the date and time information are displayed in the RMAN log instead of just the date, which is the default:
export NLS_DATE_FORMAT='dd-mon-yyyy hh24:mi:ss'
This is useful during troubleshooting, especially when RMAN fails, because we can use the exact date/time information for when the RMAN error occurred and compare it with the alert.log and OS/MML logs to verify what other events occurred in the database/server.
Also consider executing SET ECHO ON to ensure that RMAN commands are displayed within the log before the command is executed. Execute SHOW ALL as well to display the current settings of RMAN variables. These settings are useful when troubleshooting and tuning.
CLEARING ALL RMAN CONFIGURATIONS
There is no CLEAR ALL command for resetting all RMAN configurations back to the default values. However, you can easily simulate this by running a script that contains CONFIGURE...CLEAR commands:
CONFIGURE RETENTION POLICY clear;
CONFIGURE BACKUP OPTIMIZATION clear;
CONFIGURE DEFAULT DEVICE TYPE clear;
CONFIGURE CONTROLFILE AUTOBACKUP clear;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK clear;
CONFIGURE DEVICE TYPE DISK clear;
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK clear;
CONFIGURE CHANNEL 1 DEVICE TYPE DISK clear;
CONFIGURE CHANNEL 2 DEVICE TYPE DISK clear;
CONFIGURE CHANNEL 3 DEVICE TYPE DISK clear;
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK clear;
CONFIGURE MAXSETSIZE clear;
CONFIGURE ENCRYPTION FOR DATABASE clear;
CONFIGURE ENCRYPTION ALGORITHM clear;
CONFIGURE COMPRESSION ALGORITHM clear;
CONFIGURE RMAN OUTPUT clear; # 12c
CONFIGURE ARCHIVELOG DELETION POLICY clear;
CONFIGURE SNAPSHOT CONTROLFILE NAME clear;
Depending on what you’ve set (and the version of your database), you may need to set additional configurations.
Segueing from Decision to Action
Now that you have a good understanding of what types of decisions you should make before implementing RMAN, it’s instructional to view a script that implements some of these components. I mainly work with Linux/Unix servers. In these environments, I use shell scripts to automate the RMAN backups. These shell scripts are automated through a scheduling utility such as cron.
This section contains a typical shell script for RMAN backups. The shell script has line numbers in the output for reference in the discussion of the architectural decisions I made when writing the script. (If you copy the script, take out the line numbers before running it.)
Following is the script. Table 17-2 details every RMAN architectural decision point covered in this chapter, how it’s implemented (or not) in the shell script, and the corresponding line number in the shell script. The script doesn’t cover every aspect of how to use RMAN. If you use the script, be sure to modify it to meet the requirements and RMAN standards for your own environment:
Table 17-2. Implementation of Architectural Decisions
| Decision Point | Implementation in Script | Line Number in Script |
|---|---|---|
| Running the RMAN client remotely or locally | Running script locally on the database server | Line 26, connecting locally (not a network connection) |
| Specifying the backup user | Using SYS to connect | Line 27, starting rman connecting with forward slash (/) |
| Using online or offline backups | Online backup | N/A. Database is assumed to be up during the backup |
| Setting the archive redo log destination and file format | LOG_ARCHIVE_DEST_N and LOG_ARCHIVE_FORMAT initialization parameters set outside the script in a database parameter file | N/A; set outside the script |
| Configuring the RMAN backup location and file format | Using the CONFIGURE command directly in the script | Lines 33–37 |
| Setting the autobackup of the control file | Enabled in the script | Line 32 |
| Specifying the location of the autobackup of the control file | Placed in the same directory as the backups | Line 33 |
| Backing up archive redo logs | Backing up with the rest of the database; specifically, using the PLUS ARCHIVELOG clause | Line 38 |
| Determining the location for the snapshot control file | Using the default location | N/A |
| Using a recovery catalog | Not using | Line 26, connecting as nocatalog |
| Using a media manager | Not using | Lines 35–37, device type disk |
| Setting the CONTROL_FILE_RECORD_KEEP_TIME initialization parameter | Using the default | N/A |
| Configuring RMAN’s backup retention policy | Configuring to a redundancy of 1, cross-checking, and deleting obsolete backups and archive redo log files | Line 34, configuring; lines 30 and 31 cross-check; line 39, using RMAN to delete old files |
| Configuring the archive redo logs’ deletion policy | Using the same retention policy applied to the backups | N/A |
| Setting the degree of parallelism | Setting a degree of 2 | Lines 35–37 |
| Using backup sets or image copies | Using backup sets | Line 38 |
| Using incremental backups | Incremental level 0, the same as a full backup | Line 38 |
| Using incrementally updated backups | Not using | N/A |
| Using block change tracking | Not using | N/A |
| Configuring binary compression | Using basic compression | Line 38 |
| Configuring encryption | Not using | N/A |
| Configuring miscellaneous settings | Not using | N/A |
| Configuring informational output | Setting | Lines 15, 28, and 29 |
1. #!/bin/bash
2. HOLDSID=${1} # SID name
3. PRG=`basename $0`
4. USAGE="Usage: ${PRG} <database name> "
5. if [ -z "${HOLDSID}" ]; then
6. echo "${USAGE}"
7. exit 1
8. fi
9. #----------------------------------------------
10. # source environment variables (see Chapter 2 for details on oraset)
11. /etc/oraset $HOLDSID
12. BOX=`uname -a | awk '{print$2}'`
13. MAILX='/bin/mailx'
14. MAIL_LIST=' [email protected] '
15. export NLS_DATE_FORMAT='dd-mon-yyyy hh24:mi:ss'
16. date
17. #----------------------------------------------
18. LOCKFILE=/tmp/$PRG.lock
19. if [ -f $LOCKFILE ]; then
20. echo "lock file exists, exiting..."
21. exit 1
22. else
23. echo "DO NOT REMOVE, $LOCKFILE" > $LOCKFILE
24. fi
25. #----------------------------------------------
26. rman nocatalog <<EOF
27. connect target /
28. set echo on;
29. show all;
30. crosscheck backup;
31. crosscheck copy;
32. configure controlfile autobackup on;
33. configure controlfile autobackup format for device type disk to
'/u01/O12C/rman/o12c_ctl_%F.bk';
34. configure retention policy to redundancy 1;
35. configure device type disk parallelism 2;
36. configure channel 1 device type disk format '/u01/O12C/rman/o12c_%U.bk';
37. configure channel 2 device type disk format '/u02/O12C/rman/o12c_%U.bk';
38. backup as compressed backupset incremental level=0 database plus archivelog;
39. delete noprompt obsolete;
40. EOF
41. #----------------------------------------------
42. if [ $? -ne 0 ]; then
43. echo "RMAN problem..."
44. echo "Check RMAN backups" | $MAILX -s "RMAN issue: $ORACLE_SID on $BOX" $MAIL_LIST
45. else
46. echo "RMAN ran okay..."
47. fi
48. #----------------------------------------------
49. if [ -f $LOCKFILE ]; then
50. rm $LOCKFILE
51. fi
52. #----------------------------------------------
53. date
54. exit 0
A few aspects of this script need further discussion. Line 11 sets the required OS variables by running a script named oraset (see Chapter 2 for details on running oraset and sourcing OS variables). Many DBAs choose to hard-code OS variables, such as ORACLE_HOME and ORACLE_SID, into the script. However, you should avoid hard-coding variables and instead use a script to source the required variables. Running a script is much more flexible, especially when you have many databases on a box with different versions of Oracle installed.
Line 15 sets the NLS_DATE_FORMAT OS variable to a value that includes hours, minutes, and seconds. This ensures that when RMAN runs commands that are appropriate, it displays the date output with a time component. This can be invaluable when you’re debugging and diagnosing issues. By default, RMAN displays only the date component. Knowing just the date when a command ran is rarely enough information to determine the timing of the commands as they were executed. At minimum, you need to see hours and minutes (along with the date).
Lines 18–24 check for the existence of a lock file. You don’t want to run this script if it’s already running. The script checks for the lock file, and, if it exists, the script exits. After the backup has finished, the lock file is removed (lines 49–51).
Line 28 sets the ECHO parameter to on. This instructs RMAN to display in the output the command before running it. This can be invaluable for debugging issues. Line 29 displays all the configurable variables. This also comes in handy for troubleshooting issues because you can see what the RMAN variables were set to before any commands are executed.
Lines 32–37 use the CONFIGURE command. These commands run each time the script is executed. Why do that? You only need to run a CONFIGURE command once, and it’s stored in the control file—you don’t have to run it again, right? That is correct. However, I’ve occasionally been burned when a DBA with poor habits configured a setting for a database and didn’t tell anybody, and I didn’t discover the misconfiguration until I attempted to make another backup. I strongly prefer to place the C ONFIGURE commands in the script so that the behavior is the same, regardless of what another DBA may have done outside the script. The CONFIGURE settings in the script also act as a form of documentation: I can readily look at the script and determine how settings have been configured.
Lines 30 and 31 run CROSSCHECK commands. Why do that? Sometimes, files go missing, or a rogue DBA may remove archive redo log files from disk with an OS command outside RMAN. When RMAN runs, if it can’t find files that it thinks should be in place, it throws an error and stops the backup. I prefer to run the CROSSCHECK command and let RMAN reconcile which files it thinks should be on disk with those that are actually on disk. This keeps RMAN running smoothly.
You run DELETE NOPROMPT OBSOLETE on line 39. This removes all backup files and archive redo log files that have been marked as OBSOLETE by RMAN, as defined by the retention policy. This lets RMAN manage which files should be kept on disk. I prefer to run the DELETE command after the backup has finished (as opposed to running it before the backup). The retention policy is defined as 1, so if you run DELETE after the backup, RMAN leaves one backup copy on disk. If you run DELETE before the backup, RMAN leaves one copy of the backup on disk. After the backup runs, there are be two copies of the backup on disk, which I don’t have room for on this server.
You can execute the shell script from the Linux/Unix scheduling utility cron, as follows:
0 16 * * * $HOME/bin/rmanback.bsh INVPRD >$HOME/bin/log/INVPRDRMAN.log 2>&1
The script runs daily at 1600 hours military time on the database server. A log file is created (INVPRDRMAN.log) to capture any output and errors associated with the RMAN job. See Chapter 21 for details on automating jobs through cron.
Again, the script in this section is basic; you’ll no doubt want to enhance and modify it to meet your requirements. This script gives you a starting point, with concrete RMAN recommendations and how to implement them.
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. RMAN is easy to use and configure. It 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 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.