As of 11gR2, Oracle RMAN does not have “exit on error” capability. This cause some problems when you run rman tasks through scripts. Below is a real-life example of such problem.
A rman cloning shell script dynamically generates a rman script to do database restore and recovery. The generated rman script looks like this:
allocate channel c1 type disk ;
allocate channel c2 type disk ;
allocate channel c3 type disk ;
set newname for datafile 1 to “+DATA”;
set newname for datafile 2 to “+DATA”;
set newname for datafile 3 to “+DATA”;
set newname for datafile 4 to “+DATA”;
set until scn 4.5688E+10;
restore database ;
switch datafile all;
Now because the format of scn was not correct, rman threw following error:
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00558: error encountered while parsing input commands
RMAN-01009: syntax error: found “dot”: expecting one of: “newline, ;”
RMAN-01007: at line 132 column 16 file: standard input
That is, of course, understandable. The problem was rman did not exit out from this script. Instead it ignored all of “set newname for datafile …” commands above the problematic line (set until scn 4.5688E+10;) and executed the commands after that. This caused a big problem as it restored datafiles to the original source location, which happened to be on the same ASM cluster. And the source was a production database. Any DBA knows what this means…
To solve the problem we were looking for “exit on error” from rman script function. Unfortunately it does not have it. So here is a workaround for such problem, use CHECKSYNTAX. It causes rman to start in a mode in which commands entered are checked for syntax errors, but no other processing is performed. If used with @ argument, then the RMAN client starts, checks all commands in the file, then exits. To use this feature to solve above problem run following command and direct output to a log file.
% $ORACLE_HOME/bin/rman CHECKSYNTAX @<rman scripts with run block>
Then check the log file to make sure there is no any syntax error before running this dynamically generated rman script.
A good news about the cloning incident, the production database was in Data Guard configuration. So it failed over to the standby. No data loss.