Making Backups with RMAN

Backup Sets and Image Copies:
The backup command lets you make two types of RMAN backups: backup sets and image copies. By default, all RMAN backups are in the form of backup sets. Each backup set contains one or more backup pieces, which are files in an RMAN-specific format. Backup sets are the default backup type for both disk- and tape-based backups.

A backup set is a logical structure that consists of a minimum of one backup piece, which is a physical, RMAN-specific format file that actually contains the backed-up data. A backup set can contain data from one or more datafiles, archived redo log files, or control files. By default, a backup set contains just one backup piece. However, you can limit the size of a backup piece by using the maxpiecesize parameter. If you do this and the backup set size is larger than the backup piece size specified by the maxpiecesize parameter, there’ll be multiple backup pieces within that backup set.

Each of the objects you back up with the backup command—database, tablespace, archived redo logs, and so on—will result in at least one backup set if you specify backup set as the backup type. RMAN determines the number of backup sets for a backup according to an internal algorithm. However, you can limit the size of a backup set by specifying the maxsetsize parameter. You can also indirectly control the number of backup sets made by RMAN for each backup by specifying the filesperset parameter, which limits the number of input files (datafiles, archived redo log files, and so on) that can be backed up into a single backup set.

The key difference between an image copy and a backup set is that RMAN can write blocks from many files into the same backup set (known as multiplexing) but can’t do so in the case of an image copy—an image copy is identical, byte by byte, to the original datafile,control file, or archived redo log file. An RMAN image copy and a copy you make with an operating system copy command such as dd (which makes image copies) are identical.

Since RMAN image copies are identical to copies made with operating system copy commands, you may use user-made image copies for an RMAN restore and recovery operation after first making the copies “known” to RMAN by using the catalog command. After this point, there’s no difference between those image copies made by you and those made by RMAN. During a restore operation, if you have both image copies and backup sets from the same time period, RMAN prefers to use an image copy over a backup set. This is because there is more overhead involved in sorting through a backup set to get the files to restore. In addition, image copies offer yet another benefit during a restore and recovery operation. If you need to restore a current datafile and happen to have an image copy of that datafile available, you can use the switch command to simply point the database to the replacement file instead of the original datafile. This eliminates the need to restore the datafile, thus speeding up database recovery considerably.

RMAN Backup Modes:
A control file or an archived redo log file is always backed up completely and in a consistent fashion. A datafile, however, may be backed up partly or completely. You can also make consistent or inconsistent backups with datafiles. The various backup types are as follows:

Full vs. incremental backups: A full backup is a backup of a datafile that includes every allocated block in that file. Note that an image copy backup of a datafile will always include every block in that file. A backup of a datafile as a backup set, however, may skip data blocks that aren’t in use. An incremental backup can be one of two different levels: a level 0 backup including all blocks in the datafile except those blocks compressed because they have never been used or a level 1 backup including only those blocks that have changed since the parent backup.

Consistent vs. inconsistent backups: A backup taken after a database was shut down gracefully (as opposed to using the shutdown abort command or a shutdown following an abrupt database crash) and restarted in mount state is said to be consistent. A consistent backup doesn’t require recovery after you restore the database. A backup taken while the
database is online or after it was brought into mount state after being shut down abruptly is called an inconsistent backup. An inconsistent backup always needs recovery to make the backup consistent.

If you’re running in archivelog mode, the target database must be mounted or be open before you can issue an RMAN backup command. If you’re running the database in noarchivelog mode, the database must first be shut down cleanly and started up in mount state before you can use RMAN for backups. If the database was abruptly shut down and restarted, RMAN can’t make the backups. You mustn’t back up a database running in noarchivelog mode while the database is open.

By default, all RMAN backups—whole database, tablespace level, and so on—are full backups. That is, all data blocks in the datafiles that were ever used, even if they are currently empty, are included in the backup. You can specify the command backup full database, for example, to start a whole-database backup, but it’s not necessary to do so. Just use the command backup database to do the same thing. However, when you are performing an incremental RMAN backup, you must specify the keyword incremental in your backup commands since it isn’t the default backup type.

Types of Files That RMAN Can Back Up:
RMAN lets you back up all the files you’d need for a database recovery, such as the following:

• Datafiles
• Control files
• Archived redo logs
• Image copies of datafiles and control files, including those made by RMAN
• Backup pieces that contain RMAN backups

The Oracle database uses three types of “live” files during its operation: datafiles, online redo log files, and control files. Of these three types of files, RMAN backs up only the datafiles and the control files. You can’t use RMAN to back up the online redo log files. If you’re operating in noarchivelog mode, then you won’t need the online redo logs, since the database files are always consistent when you back up the database using the only permitted modes of backing up a database in noarchivelog mode, which are closed whole backups. You won’t need the online redo log backups if you’re operating in archivelog mode either, since RMAN is continually backing up all your archived redo logs. However, you must make sure you always multiplex the online redo log so you won’t lose all members of a group and thus all the committed changes as yet unrecorded in the datafiles.

In addition to the previously mentioned types of files, RMAN also can back up the server parameter file, or spfile, which contains the initialization parameter for starting up your database. You can’t, however, back up the following types of files using RMAN:

• External files
• Network configuration files
• Password files
• Any Oracle home-related files

Use normal operating system copy utilities to back up any of these four types of files.

Configuring the RMAN Environment - Showing RMAN Configuration Settings

Problem
You want to see your current RMAN configuration settings. For example, you may be seeing unexpected RMAN behavior, or you may be encountering performance issues because of how you’ve configured RMAN in your environment.

Solution
Use the RMAN command show to view the current value of one or all of RMAN’s configuration settings. The show command will let you view the value of a specified RMAN setting. For example, the following show command displays whether the autobackup of the control file has been enabled:

RMAN> show controlfile autobackup;
RMAN configuration parameters are:
CONFIGURE CONTROLFILE AUTOBACKUP OFF;
RMAN>

The show all command displays both settings that you have configured and any default settings. Any default settings will be displayed with a # default at the end of the line. For example, the following is the output from executing the show all command:

RMAN> connect target /
RMAN> show all;
RMAN configuration parameters are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP OFF; # default
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUPTYPE TO BACKUPSET; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
CONFIGURE COMPRESSION ALGORITHM 'ZLIB'; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO
'C:\ORACLE\PRODUCT\11.1\DB_1\DATABASE\SNCFORCL.ORA'; # default
RMAN>

How It Works
The show command queries the target database control file to retrieve RMAN configuration settings. Configuration settings are stored in the target database control file regardless of whether you are using a recovery catalog. Once configured, settings persist until you change them again. Because RMAN settings are stored in the control file, your target database must
be mounted or open when issuing the show command.

The show all command reveals the present configuration regarding several important RMAN backup and recovery settings. The following list summarizes the meaning of the most important of these settings, shown by issuing the show all command:

• configure retention policy to redundancy 1 means that RMAN retains only one set of backup copies.
• configure backup optimization off means that by default RMAN won’t skip the backing up of unchanged data blocks in the datafiles.
• configure default device type to disk means that by default RMAN sends backup output to a disk drive.
• configure controlfile autobackup off means that by default RMAN doesn’t automatically back up the control files when it performs a backup task.
• configure device type disk parallelism 1 backup type to backupset means that the default RMAN backup type is a backup set (and not an image copy) and the degree of parallelism is 1.
• configure datafile backup copies for device type disk to 1 means that by default RMAN doesn’t make multiple copies of a backup file.
• configure maxsetsize to unlimited means that there’s no limit on the size of a backup set by default.
• configure encryption for database off means that by default RMAN backups aren’t encrypted.

Notice that the output of the show all command shows the existing RMAN configuration in the form of RMAN commands to re-create that configuration. Therefore, if you are planning to use the same type of configuration on a different database, just save the output from the show all command to a text file that you can then execute from the RMAN command line after connecting to the target database to which you’re planning to migrate those settings.

You can view information about RMAN’s persistent configuration settings by querying the V$RMAN_CONFIGURATION view, as shown here:

SQL> select * from v$rman_configuration;
CONF#                     NAME                                           VALUE
---------- ------------------------------                              ------------------------
        1 RETENTION POLICY                       TO REDUNDANCY 3
        2 BACKUP OPTIMIZATION                                           ON
        3 DEFAULT DEVICE TYPE TO                              sbt_tape
        4 CONTROLFILE AUTOBACKUP                                  ON
        5 DEVICE TYPE                             DISK PARALLELISM 2
5 rows selected.

The NAME column in the V$RMAN_CONFIGURATION view shows the type of RMAN configuration, and the VALUE column shows the present configure command setting for that type, for example, configure retention policy to redundancy 3.

RMAN-Checking the Syntax of RMAN Commands

Problem
You want to check the syntax of your RMAN commands without actually executing the commands.

Solution
To check the syntax of RMAN commands, you must start the RMAN client with the operating system command-line argument checksyntax. You can easily check the syntax of commands prior to their execution either by entering them at the command prompt or by reading in the commands through a command file. Here’s how you check the syntax of a single RMAN command (run {backup database;}) by first starting the RMAN client with the checksyntax argument:

$. /rman checksyntax
Recovery Manager: Release 11.1.0.1.0 - Beta on Mon Apr 2 08:31:11 2007
Copyright (c) 1982, 2005, Oracle. All rights reserved.
RMAN> run {backup database;}
The command has no syntax errors
RMAN>

In this example, there were no errors in the syntax of the simple run block, and RMAN confirms that. You can also use the checksyntax argument to check the syntax of RMAN commands that are part of a command file. Simply specify the checksyntax argument before invoking the command file that consists of the RMAN commands. In the following example,
the file goodcmdfile contains a couple of restore and recovery commands:

$ rman checksyntax @/tmp/goodcmdfile
Recovery Manager: Release 11.1.0.1.0 - Beta on Mon Apr 2 08:31:11 2007
Copyright (c) 1982, 2005, Oracle. All rights reserved.
RMAN> # file with legal syntax
2> restore database;
3> recover database;
4>
The cmdfile has no syntax errors
Recovery Manager complete.
$

You can also open an RMAN session solely for the purpose of checking the syntax of commands
that you type interactively:

$ rman checksyntax

An important point about the checksyntax argument is that you can’t use it after starting RMAN. That is, you can’t include the checksyntax argument from the RMAN command line. You must pass checksyntax as an argument to the rman command when you start the RMAN client and without connecting to any target or recovery catalog.

How It Works
When you either execute an RMAN command file by preceding it with the checksyntax argument or enter any RMAN commands after starting RMAN with the checksyntax argument, RMAN won’t actually execute any RMAN commands. RMAN will check and report only on the syntax of those commands. If the RMAN commands that you type at the command line or that you include as part of a command file have no errors, you get the “the command (cmdfile) has no errors” message from RMAN. Otherwise, RMAN will issue an error, as shown in the following example:

$ rman checksyntax @/tmp/badcmdfile
Recovery Manager: Release 11.1.0.1.0 - Beta on Mon Apr 2 08:31:11 2007
Copyright (c) 1982, 2005, Oracle. All rights reserved.
RMAN> # file with illegal syntax
RMAN> run (backup database);
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-00558: error encountered while parsing input commands
RMAN-01009: syntax error: found "(": expecting one of: "{"
RMAN-01007: at line 1 column 5 file: standard input
RMAN>

The output of the checksyntax command reveals there is a syntax error in your run block. The checksyntax command is handy for checking scripts for syntax errors. With RMAN, there’s no need for a script to fail unexpectedly because you mangled the syntax of a command. If you’re surprised by an error, it’s because you didn’t test with checksyntax first.

RMAN-Creating Dynamic Command Files

Problem
You want to create dynamic command files that can be used for multiple jobs by passing substitution variables.

Solution
You can create dynamic shell scripts by using substitution variables in the RMAN command files inside the shell scripts. You can specify values for use in substitution variables through the new using clause when calling an RMAN command file. You use the &integer syntax (&1, &2, and so on) to indicate to which variable your substitution values should be assigned, just as in SQL*Plus.
Let’s review an example that shows how to create a dynamic backup shell script.

1. Create the RMAN command file that uses two substitution variables:

#backup.cmd
connect target sys/<sys_password>@prod1
run {
backup database
tag &1
format &2
}
exit;

The command file shown here will back up the database using two substitution variables (&1 and &2), one for the backup tag and the other for the string value in the format specification.
2. Create the shell script to run the backup command file you created in step 1:

#!/bin/tcsh
# script name: nightly_backup.sh
set tag=$argv(1)
set format=$argv[2]
rman @backup.cmd using $tag $format

3. Now that you have created a dynamic shell script, you can specify the arguments for the tag and format variables on the command line, thus being able to modify them for different jobs. Here’s an example:

$ nightly_backup.sh longterm_backup back0420

The example shows how to execute the shell script nightly_backup.sh with two dynamic parameters, longterm_backup (tag) and back0420 (format string).

How It Works
The ability to use substitution variables in RMAN scripts is new in Oracle Database 11g. The use of substitution variables in RMAN scripts is similar to the way you specify substitution variables in operating system and SQL*Plus scripts. Specifying substitution variables lets you use the same command file by modifying it appropriately for different backup tasks, thus
making the command file dynamic.

RMAN-Executing Operating System Commands from Within RMAN

Problem
You’ve invoked the RMAN client, and now you need to issue some operating system commands.

Solution
Use the RMAN command host to invoke an operating system subshell. You can execute this command in two ways: you can issue it from the RMAN prompt, or you can execute it from inside a run block, which is a group of RMAN commands executed as a single unit. If you issue the host command stand-alone, without any parameters, RMAN will take you to the operating
system command line. Thus, the host command works the same in RMAN as it does from within SQL*Plus. If you issue the command host followed by a valid operating system command as a parameter, then RMAN will execute that operating system command and continue to process the rest of the commands in the run block, if there are any.
In the following example, we use the host command to list all files ending with dbf, after backing up a datafile from the RMAN prompt:

RMAN> shutdown immediate;
RMAN> startup mount;
RMAN> backup datafile '/u01/app/oracle/oradata/targ/system01.dbf' format '/tmp/system01.dbf';
RMAN> host 'ls -l /tmp/*dbf';
RMAN> alter database open;

The following example uses the host command with no parameters to temporarily escape to the operating system level during an interactive RMAN session:

RMAN> backup datafile 3 format '/u01/app/oracle/oradata/targ_db/dbs01.cpy';
RMAN> host;
$ ls $ORACLE_HOME/oradata/dbs01.cpy /net/oracle/oradata/dbs01.cpy
$ exit
RMAN>

How It Works
As you can see in the two examples, you can use the host command with or without an operating system command as a parameter. If you run the host command as part of a series of RMAN commands, RMAN executes the host command and continues with the rest of the commands. When you execute the host command by itself, RMAN displays the operating
system command prompt and resumes after you exit the command-line subshell.

Creating an Oracle Password File

You can easily create an Oracle password file with the help of the orapwd utility. Just type orapwd at the operating system command line to view the syntax of the command:

$ orapwd
Usage: orapwd file=<fname> password=<password> entries=<users> force=<y/n> ignorecase=<y/n> nosysdba=<y/n>

where
file - name of password file (required),
password - password for SYS (required),
entries - maximum number of distinct DBA (required),
force - whether to overwrite existing file (optional),
ignorecase - passwords are case-insensitive (optional),
nosysdba - whether to shut out the SYSDBA logon (optional Database Vault only).
There must be no spaces around the equal-to (=) character.

Of the six options for the orapwd utility, the file, password, and entries options are mandatory. You can create a simple Oracle password file using the following syntax:

$ orapwd file=mydb_pwd password=sammyy1 entries=20

This command will create an Oracle password file. The default location for the password file is the $ORACLE_HOME/dbs directory. Once you create the password file, edit your init.ora file or your spfile in the following manner:

remote_login_passwordfile = 'EXCLUSIVE'

Once your restart your database after this, you’ll be able to log in as the sys user.

RMAN - Logging Command-Line RMAN Output

Problem
You want to log the output of RMAN commands you issue in command-line mode.

Solution
If you want RMAN to log all its output when you use RMAN from the operating system command line, just add the keyword log to the command line, and supply the name of the log file to use. For example:

$ rman target / cmdfile commandfile1.rcv log /u01/app/oracle/outfile.txt

In this case, RMAN will write the output of the RMAN commands in the command file named commandfile.rcv to the log file outfile.txt. If you later want to run another set of RMAN commands and want to append the log messages to the same log file, you can do this by using the append option along with the log option. Here’s an example:

$ rman target / cmdfile commandfile2.rcv log /u01/app/oracle/outfile.txt append

The previous command will append the output from executing the command file commandfile2.rcv to the text file outfile.txt.

How It Works
The command-line argument log causes RMAN to send all its output to the log file you specify.Failure to add the keyword append when referring to an already existing log file will result in the overwriting of that older log file. If you are running RMAN interactively and you want to see output on your terminal screen as well as have it written to a log file, you can take advantage of the Unix/Linux tee command. The tee command sends output both to a text file and to the terminal. Here’s how you use the tee command:

$ rman | tee rman.log
RMAN>

All is not lost if you don’t specify a log file to capture the RMAN output. The view V$RMAN_OUTPUT returns detailed information about RMAN jobs in progress. For example, if your media manager runs into a problem with a tape drive, RMAN records the associated error messages in V$RMAN_OUTPUT and also outputs the message to the terminal or to a log file. As with all dynamic performance views, the contents of the V$RMAN_OUTPUT view are refreshed when you restart the database. The V$RMAN_STATUS view contains information about completed RMAN jobs as well as all RMAN jobs in progress.