Database Reference
In-Depth Information
SQL> SELECT completion_time, handle
FROM v$backup_piece
WHERE handle LIKE '%FF';
COMPLETION_TIME HANDLE
--------------- ------------------------
02.07.07 22:30 C-2848896501-20070702-
FF
The first control file autobackup one day later again uses the hexadecimal sequence
number 00.
SQL> SELECT completion_time, handle
FROM v$backup_piece
WHERE handle like '%00';
COMPLETION_TIME HANDLE
--------------- ------------------------
02.07.07 17:17 C-2848896501-20070702-00
03.07.07 22:51 C-2848896501-20070703-00
This is the only situation that I am aware of, where RMAN overwrites existing backup
pieces with new data. Under all other circumstances, RMAN refuses to overwrite existing files
and aborts the command
BACKUP
with “ORA- 19506: failed to create sequential file, name=
"
string
", parms="
string
" for device type SBT_TAPE” or “ORA-19504: failed to create file "
string
"
for device type disk” and “ORA-27038: created file already exists”.
This behavior sheds some light on the algorithm RMAN uses to generate backup piece
handles in its quest for a control file from an automatic control file backup. Among others, the
settings of the optional parameters
MAXDAYS
and
MAXSEQ
in the command
RESTORE
CONTROLFILE
FROM
AUTOBACKUP
determine the handle names RMAN generates. If
MAXSEQ
is not set, RMAN uses
the default of 256, translates it to hexadecimal FF, and builds a handle name according to the
%F
format presented earlier. If no such backup piece exists, the sequence number (
QQ
) is decre-
mented by 1 until it reaches 0. If no control file backup is found during this process, RMAN moves
on to the previous day and recommences the process with a hexadecimal sequence number of FF.
The default for
MAXDAYS
is 7 with a permissible range between 1 and 366. If, after
MAXDAYS
days
before the current day have been tried, RMAN still fails to locate a suitable backup piece, the
RESTORE
command terminates with the error “RMAN-06172: no autobackup found or specified
handle is not a valid copy or piece”. The search may be accelerated somewhat by using a lower
MAXSEQ
such as 10 in cases where it is known that no more than 10
BACKUP
commands get executed
per day due to data file and archived log backups.
The new automatic control file backup functionality—which also backs up the server
parameter file (
SPFILE
), if present—is
disabled
by default (page 2-69 of the
Oracle Database
Backup and Recovery Reference 10g Release 2
). There certainly are production systems that are
still vulnerable, since no backup—automatic or not—of the control file with the most recent
recovery-related metadata exists.
Undoubtedly, the likelihood of scenarios 1 and 2 described earlier is low. Nonetheless it is
reassuring to learn that even on systems where the quality of backup scripts is insufficient, the
road to full recovery is still open when following the advice on the undocumented package
DBMS_BACKUP_RESTORE
that I will present shortly.
