Database Reference
In-Depth Information
The corrupt backup piece is also reported in the alert log of the instance.
Wed Dec 05 19:59:41 2007
Corrupt block 1 found during reading backup piece, file=A16J2S5GD.BKP, corr_type=1
Internode Parallel Backup and Restore
Backup and recovery operations by RMAN may be parallelized within a single DBMS instance
by allocating several channels. Parallelization across several RAC instances is possible by
explicitly allocating channels and supplying a connect string, which resolves to individual
instances. Yet, this kind of hard-coded internode parallel backup is not robust. The backup
would fail if one of the RAC instances were not available.
Usually, each RAC node has one or two Fibre Channel host bus adapters to connect it to a
SAN storage array, and one or more public LAN (local area network) adapters. Irrespective of
the data path used by backup or restore—LAN or LAN-free over Fibre Channel—I expect backup
operations to scale with the number of LAN or fiber channel adapters used, given that there is
no other bottleneck elsewhere in the system.
The single missing piece is a coordinator process, which can receive commands like
BACKUP
DATABASE
,
RESTORE
DATABASE
,
RESTORE
TABLESPACE
in whatever format, break down the task into
smaller units, and assign these to multiple instances of RMAN. Note that it is irrelevant where
in the cluster (or even outside of the cluster) instances of RMAN are running, as long as the
proper connect string is supplied with the command
CONNECT
TARGET
. When backing up, one
tape drive might be assigned per RAC node. Matters are more complicated during a restore,
since there is no easy way to ensure that the files needed are not accidentally located on the
same tape. When disk pools are used instead of or in addition to tape drives, the concurrency
issues arising with tape drives are mitigated.
The RMAN pipe interface offers a solid foundation for implementing a coordinator process for
internode parallel backup and restore. For example, when such a coordinator process receives
the command
BACKUP
DATABASE
, it might retrieve the list of data files from
V$DATAFILE
and assign
data files for backup to multiple RMAN instances in a round robin fashion. Whenever an instance
of RMAN finishes backing up a data file, it would send “RMAN-00572: waiting for dbms_pipe
input” via
DBMS_PIPE
to the coordinator process. The coordinator could then assign the next
data file to back up by sending another
BACKUP
DATAFILE
command to the RMAN process. This
divide and conquer
style algorithm would also provide a rudimentary form of load balancing,
since less loaded nodes would have higher I/O bandwidth and could thus handle more data
files (given a standardized sizing of data files).
The package
RMAN_PIPE_IF
presented in the previous section provides the infrastructure
for sending and receiving messages to and from RMAN instances on different RAC nodes. Since
database pipes are local to an instance, it is not possible to write to pipe P on RAC instance 1
and to read from the same pipe P on RAC instance 2. In a multi-instance RAC environment, the
package
RMAN_PIPE_IF
(and thus
DBMS_PIPE
) needs to be called via database links from a single
database session or the coordinator process needs to open several database sessions, one per
instance. The first method must be used when implementing the coordinator with PL/SQL,
whereas the latter would be preferred when using Perl DBI or another programming language
