Database Reference
In-Depth Information
CHAPTER 36
■ ■ ■
Recovery Manager
Pipe Interface
T
he Oracle DBMS supports pipes as a means of interprocess communication among database
sessions. It distinguishes private pipes from public pipes. To enforce security, private pipes
owned by the user SYS may not be accessed by any other database user. The Recovery Manager
(RMAN) pipe interface leverages private pipes. It is ideally suited to integrate RMAN into
portable third-party backup and restore tools. It is also very well suited to implement robust
scripts, which can handle catalog instance failures, block corruptions, and internode parallel
backup and restore for Real Application Clusters (RAC) installations.
The RMAN pipe interface is documented. It is also documented that all message content
sent to and received from RMAN with
DBMS_PIPE
must consist of
VARCHAR2
data. However, all
the details on how to pack
VARCHAR2
data into pipe messages (one or multiple
VARCHAR2
items
per message) and how error stacks are packaged into messages are undocumented. Further-
more, the behavior of RMAN in case of an error (termination or continuation) is undocumented.
Introduction to Recovery Manager
Anyone who has worked with RMAN, the backup and recovery utility of choice since the release
of Oracle8, knows that it can be used interactively in a terminal window. RMAN can also read
commands from a script (e.g.,
rman
CMDFILE
script_name
.rvc
). Success or failure of RMAN can
be determined by examining the exit code it passes to the calling program or shell. Exit code
zero means success, whereas a nonzero exit code means failure. RMAN can write a transcript
of its operations to a log file (parameter
LOG
, previously
MSGLOG
).
The trouble begins when more advanced features are required. For example, when a
recovery catalog is used and RMAN is started with the command line option
CATALOG
, or there
is a
CONNECT
CATALOG
statement in a script, RMAN exits with an error, if the catalog is unavail-
able. Thus, no backup is taken, even though it would have been perfectly feasible to back up
the database in
NOCATALOG
mode and then resynchronize the control file with the catalog, once
the catalog instance becomes available again. Resynchronization happens automatically, the
next time RMAN executes a backup, restore, or list command while connected to the catalog.
Manual resynchronization is accomplished with the command
RESYNC
CATALOG
. This command
may also be used to synchronize a control file with multiple RMAN catalogs on independent
systems for increased catalog availability, dispelling the need to protect the catalog with Data
Guard or clustering.
465
