Database Reference
In-Depth Information
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.
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.
