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.
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 4-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:
A few aspects of this script need further discussion. Lines 9, 10, and 11 set the required OS variables by hard-coding the required OS variables into the script (see Chapter 1 for details on sourcing OS variables). I generally prefer not to hard-code variables into a script like this, but did so here to provide a simple example of how to script RMAN to backup your database. You’ll find that many DBAs do hard-code these variables into scripts.
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 CONFIGURE 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 >$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.
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.