o To use the RMU Backup command for a database, you must have
the RMU$BACKUP privilege in the root file access control
list (ACL) for the database or the OpenVMS SYSPRV or BYPASS
privilege.
o If you attempt to back up an area with detected corruptions
(or which has corrupt pages logged to the CPT), the backup
operation fails immediately. If you attempt to back up an area
that contains an undetected corruptions (a corruption that
has not been logged to the CPT), the backup operation proceeds
until a corruption is found. These undetected corruptions
are found only if you specify the Checksum qualifier with the
Backup command.
o The following list provides usage information for parallel
backup operations:
- When performing a parallel backup operation, do not
allocate or mount any tapes manually; this is done
automatically by RMU Backup.
- You can monitor the progress of a backup operation to tape
on your Windows system using the Parallel Backup Monitor.
- You can use the Parallel Backup Monitor to monitor the
progress of a parallel backup operation to tape. Specify
your backup operation using the Parallel qualifier
with the Executor_Count=1 option to approximate a non-
parallel backup operation. Non-parallel backup operations
(backup commands without the Parallel qualifier) cannot be
monitored with the Parallel Backup Monitor.
- If a parallel backup operation is issued from a server
node, then RMU Backup communicates with SQL/Services to
start the Coordinator. SQL/Services creates a Coordinator
process.
- If a parallel backup operation is issued from a client node
(for example, using RMUwin), then the same SQL/Services
process that is created to execute client/server RMU Backup
commands is used as the Coordinator process.
- You cannot use the Storage Library System (SLS) for OpenVMS
with an RMU parallel backup.
o Logical area threshold information for storage areas with
uniform page format is recorded in the backup file. See
the Oracle Rdb SQL Reference Manual for more information on
logical area threshold information.
o See the Oracle Rdb Guide to Database Maintenance for
information on determining the working set requirements for
a non-parallel backup operation.
o The following list provides usage information for the Quiet_
Point and Noquiet_Point qualifiers
- If the operation stalls when you attempt a quiet-point
Oracle RMU backup operation, it may be because another user
is holding the quiet-point lock. In some cases, there is
no way to avoid this stall. In other cases you may find
the stall is caused by a user who has previously issued
and completed a read/write transaction, and is currently
running a read-only transaction. When this user started
the read/write transaction, the process acquired the quiet-
point lock. Ordinarily, such a process retains this lock
until it detaches from the database.
You can set the RDM$BIND_SNAP_QUIET_POINT logical name to
control whether or not such a process retains the quiet-
point lock. Set the value of the logical name to "1" so
that all transactions hold the quiet point lock until a
backup process requests it. Read-only transactions will not
obtain the quiet point lock; only read/write transactions
will obtain the quiet point lock. Set the value of the
logical name to "0" so that read-only transactions always
release the quiet point lock at the beginning of the
transaction, regardless of the existence of a backup
process. All modified buffers in the buffer pool have
to be written to disk before the transaction proceeds.
Applications that utilize the fast commit feature and often
switch between read-only and read/write transactions within
a single attach may experience performance degradation if
the logical is defined to "0".
Oracle recommends that you do not define the RDB$BIND_SNAP_
QUIET_POINT logical for most applications.
- If you intend to use the Noquiet_Point qualifier with a
backup procedure that previously specified the Quiet_
Point qualifier (or did not specify either the Quiet_
Point or Noquiet_Point qualifier), you should examine any
applications that execute concurrently with the backup
operation. You might need to modify your applications or
your backup procedure to handle the lock conflicts that
might occur when you specify Noquiet_Point.
When you specify the Quiet_Point qualifier, the backup
operation begins when a quiet point is reached. Other
update transactions that are started after the database
backup operation begins are prevented from executing until
after the root file for the database has been backed up
(the backup operation on the database storage areas begins
after the root file is backed up).
- When devising your backup strategy for both the database
and the after-image journal files, keep in mind the trade-
offs between performing quiet-point backup operations and
noquiet-point backup operations. A noquiet-point backup
operation is quicker than a quiet-point backup operation,
but usually results in a longer recovery operation. Because
transactions can span .aij files when you perform noquiet-
point .aij backup operations, you might have to apply
numerous .aij files to recover the database. In a worst-
case scenario, this could extend back to your last quiet-
point .aij or database backup operation. If you rarely
perform quiet-point backup operations, recovery time could
be excessive.
One method you can use to balance these trade-offs is
to perform regularly scheduled quiet-point .aij backup
operations followed by noquiet-point database backup
operations. (You could do the converse, but a quiet-
point backup of the .aij file improves the performance
of the recovery operation should such an operation become
necessary.) Periodically performing a quiet-point .aij
backup operation helps to ensure that your recovery time
will not be excessive.
o Do not add new logical areas in the context of an exclusive
transaction during an online backup operation.
When new logical areas are added during an online backup
operation such that new records are physically placed in a
location that the backup operation has not processed yet,
Oracle Rdb returns the following error:
%RMU-F-CANTREADDBS, error reading pages !UL:!UL-!UL
Logical areas that cause this problem are created when you do
either of the following:
- Create a new table, start a transaction that reserves the
new table in exclusive mode, and load the table with rows.
- Create a new table, start a transaction that reserves the
new table in exclusive mode, and create an index for the
table.
Creating new tables and populating them, or creating new
indexes do not pose a problem if the table is not reserved
in exclusive mode.
o If you back up a database without its root file ACL (using
the Noacl qualifier of the RMU Backup command, for example), a
user who wants to restore the database must have the OpenVMS
SYSPRV or BYPASS privilege.
o You might receive the RMU-I-WAITOFF informational message
when you try to back up your database if the database was
manually opened with the RMU Open command and has not been
manually closed with the RMU Close command. You also receive
this message when you issue an RMU Close command with the
Nowait qualifier and users are still attached to the database.
To back up your database, you must have exclusive access to
the database root file. This error message usually indicates
that you do not have exclusive access to the database root
file because the operating system still has access to it. If
your database was manually opened with the RMU Open command,
you should be able to gain exclusive access to the database
root file by manually closing the database with an RMU Close
command.
You can also receive this error message when you attempt other
operations for which you must have exclusive access to the
database root file. The solution in those cases is to attempt
the operation again, later. Until you have exclusive access
to the database root file, meaning that no other user gained
access to the database between the time you issued the command
and the time the command takes effect, you cannot complete
those operations.
o Backup files are typically smaller in size than the actual
database. They exclude free space and redundant structural
information that can be reconstructed with a restore
operation. However, backup files also contain some overhead
to support the backup format. Compression factors range from
approximately 1.2 to 3 depending on the organization and
fullness of the database. The compression factor achieved
for a given database is generally quite stable and usually
only changes with structural or logical reorganization.
Do not use the size of the backup file as an indication of
the size of the database files. Use the RMU Analyze command to
determine the actual data content.
o Backup performance is strongly affected by the job priority
of the process running it. For best performance, a backup
operation should execute at interactive priority, even when it
is operating as a batch job.
o The following list contains information of interest if you are
performing a backup operation to tape:
- If you back up the database to tape, and you do not specify
the Parallel qualifier, you must mount the backup media by
using the DCL MOUNT command before you issue the RMU Backup
command. The tape must be mounted as a FOREIGN volume.
Like the OpenVMS Backup utility (BACKUP), the RMU Backup
command performs its own tape label processing. This does
not prohibit backing up an Oracle Rdb database to an RMS
file on a Files-11 disk.
When you specify the Parallel qualifier, you need not mount
the backup media because the parallel executors allocate
and mount the drive and labels for you.
- When RMU Backup creates a multivolume backup file, you can
only append data to the end of the last volume. You cannot
append data to the end of the first or any intermediate
volumes.
- The RMU Backup command uses asynchronous I/O. Tape
support provided includes support for multifile volumes,
multivolume files, and multithreaded concurrent tape
processing.
- If you allow RMU Backup to implicitly label tapes and you
are using a tape drive that has a display (for example, a
TA91 tape drive), the label displayed is the original label
on the tape, not the label generated by RMU Backup.
- Oracle Corporation recommends that you supply a name for
the backup file that is 17 or fewer characters in length.
File names longer than 17 characters can be truncated.
The system supports four file-header labels: HDR1, HDR2,
HDR3, and HDR4. In HDR1 labels, the file identifier field
contains the first 17 characters of the file name you
supply. The remainder of the file name is written into the
HDR4 label, provided that this label is allowed. If no HDR4
label is supported, a file name longer than 17 characters
will be truncated.
The following Oracle RMU commands are valid. The
terminating period for the backup file name is not counted
as a character, and the default file type of .rbf is
assumed. Therefore, the system interprets the file name
as wednesdays_backup, which is 17 characters in length:
$ RMU/BACKUP/REWIND/LABEL=TAPE MF_PERSONNEL MUA0:WEDNESDAYS_BACKUP.
$ RMU/RESTORE/REWIND/LABEL=TAPE MUA0:WEDNESDAYS_BACKUP.
The following Oracle RMU commands create a backup file
that cannot be restored. Because no terminating period is
supplied, the system supplies a period and a file type of
.rbf, and interprets the backup file name as wednesdays_
backup.rbf, which is 20 characters in length. RMU truncates
the backup file name to wednesdays_backup. When you attempt
to restore the backed up file, RMU assumes the default
extension of .rbf and returns an error when it cannot find
the file wednesdays_backup.rbf on tape.
$ RMU/BACKUP/REWIND/LABEL=TAPE MF_PERSONNEL MUA0:WEDNESDAYS_BACKUP
$ RMU/RESTORE/REWIND/LABEL=TAPE MUA0:WEDNESDAYS_BACKUP
- See the Oracle Rdb Guide to Database Maintenance for
information on the steps RMU Backup follows in tape label
checking for the RMU Backup command.
- The RMU Backup command works correctly with unlabeled or
nonstandard formatted tapes when the Rewind qualifier is
specified. However, tapes that have never been used or
initialized, and nonstandard tapes sometimes produce errors
that make OpenVMS mount attempts fail repeatedly. In this
situation, RMU Backup cannot continue until you use the DCL
INITIALIZE command to correct the error.
- How Tapes are Relabeled During a Backup Operation
summarizes the tape labeling behavior of RMU Backup under
a variety of circumstances. For example, the last row
of the table describes what labels are applied when you
specify both the Label=back qualifier and the Accept_Label
qualifier and all the tapes (except the second) are already
labeled and used in the following order: aaaa, no label,
bbbb, dddd, cccc. The table shows that these tapes will
be relabeled in the following order, with no operator
notification occurring: aaaa, back02, bbbb, dddd, eeee.
How Tapes are Relabeled During a Backup Operation assumes
the backup file name is mf_personnel.rbf:
Table 5 How Tapes are Relabeled During a Backup Operation
Qualifiers Current Resulting
Specified Labels Labels Operator Notification
Neither None
Label mf_ mf_
nor per per
Accept_ mf_ mf_
Label p05 p05
mf_ mf_
p06 p06
mf_ mf_
p02 p02
mf_ mf_
p03 p03
Neither All tapes except second tape
Label aaaa mf_
nor no per
Accept_ label mf_
Label bbbb p02
dddd mf_
cccc p03
mf_
p04
mf_
p05
Label=back All tapes except second
aaaa back
no back02
label back03
bbbb back04
dddd back05
cccc
Label=(back01, All tapes except second
back02) aaaa back01
no back02
label back03
bbbb back04
dddd back05
cccc
Accept_ None
Label aaaa aaaa
no mf_
label p02
bbbb bbbb
dddd dddd
cccc cccc
Accept_
Label, None
Label=back aaaa aaaa
no back02
label bbbb
bbbb dddd
dddd cccc
cccc
o When you use more than one tape drive for a backup operation,
ensure that all of the tape drives are the same type (for
example, all of the tape drives must be TA90s or TZ87s or
TK50s). Using different tape drive types (for example, one
TK50 and one TA90) for a single database backup operation may
make database restoration difficult or impossible.
Oracle RMU attempts to prevent you from using different tape
drive densities during a backup operation but is not able to
detect all invalid cases and expects that all tape drives for
a backup are of the same type.
As long as all of the tapes used during a backup operation
can be read by the same type of tape drive during a restore
operation, the backup is likely to be valid. This may be the
case, for example, when you use a TA90 and a TA90E.
Oracle Corporation recommends that, on a regular basis, you
test your backup and recovery procedures and environment
using a test system. You should restore the database and then
recover using after-image journals (AIJs) to simulate failure
recovery of the production system.
Consult the Oracle Rdb Guide to Database Maintenance and
the Oracle Rdb Guide to Database Design and Definition for
additional information about Oracle Rdb backup and restore
operations.
o You should use the density values added in OpenVMS Version
7.2-1 for OpenVMS tape device drivers that accept them because
previously supported values may not work as expected. If
previously supported values are specified for drivers that
support the OpenVMS Version 7.2-1 density values, the older
values are translated to the Version 7.2-1 density values if
possible. If the value cannot be translated, a warning message
is generated, and the specified value is used.
If you use density values added in OpenVMS Version 7.2-1 for
tape device drivers that do not support them, the values are
translated to acceptable values if possible. If the value
cannot be translated, a warning message is generated and the
density value is translated to the existing default internal
density value (MT$K_DEFAULT).
One of the following density-related errors is generated if
there is a mismatch between the specified density value and
the values that the tape device driver accepts:
%RMU-E-DENSITY, TAPE_DEVICE:[000000]DATABASE.BCK; does not support specified
density
%RMU-E-POSITERR, error positioning TAPE_DEVICE:
%RMU-E-BADDENSITY, The specified tape density is invalid for this device
o If you want to use an unsupported density value, use the VMS
INITIALIZE and MOUNT commands to set the tape density. Do not
use the Density qualifier.
o The density syntax used on the command can also be used in the
plan file for the Parallel RMU backup to tape process.
o Oracle Rdb cannot continue a single .rda file across multiple
disks. This means that, during a multidisk backup operation,
each device must have enough free space to hold the largest
storage area in the database. If the storage areas are on
stripe sets and are larger than any actual single disk, then
the devices specified for the backup file must be striped
also.
It is not possible to indicate which storage area should be
backed up to a given device.
o Because data stream names representing the database are
generated based on the backup file name specified for the
Oracle RMU backup command, you must either use a different
backup file name to store the next backup of the database
to the Librarian utility or first delete the existing data
streams generated from the backup file name before the same
backup file name can be reused.
To delete the existing data streams stored in the Librarian
utility, you can use a Librarian management utility or the
Oracle RMU Librarian/Remove command.
o If you are backing up to multiple disk devices using thread
pools, the following algorithm to assign threads is used by
the backup operation:
- The size of each area is calculated as the product of the
page length in bytes multiplied by the highest page number
used (maximum page number) for that area.
- The area sizes are sorted by descending size and ascending
device name. For internal processing reasons, the system
area is placed as the first area in the first thread.
- Each of the remaining areas is added to the thread that has
the lowest byte count.
The same algorithm is used for tape devices, but the areas are
partitioned among writer threads, not disk devices.
o The partitioning for backup to multiple disk devices is done
by disk device, not by output thread, because there will
typically be more disk devices than output threads, and an
area cannot span a device.