Creates a backup copy of the database and places it in a file. If
necessary, you can later use the RMU Restore command to restore
the database to the condition it was in at the time of the backup
operation.
1 – Description
The RMU Backup command copies information contained in a database
to a file. It provides a number of options that allow you to
determine the following:
o Whether to perform a parallel backup operation.
When you specify a parallel backup operation, you must back up
to tape or multiple disks. The Parallel Backup Monitor allows
you to monitor the progress of a parallel backup operation.
o Whether to back up the database to disk or tape.
o The extent (how much of the database) to back up.
The backup operation uses a multithreaded process to optimize
the performance of the backup operation. See the Oracle Rdb
Guide to Database Maintenance for a complete description of how
multithreading works.
A parallel backup operation, in addition to using multithreaded
processes, uses a coordinator executor and multiple worker
executors (subprocesses) to enhance the speed of the backup
operation. You can also direct each worker executor to run on
a different node within a cluster to further enhance the speed
of the operation. You must have Oracle SQL/Services installed and
running to perform a parallel backup operation.
See the Oracle Rdb Guide to Database Maintenance for information
on when a parallel backup operation is most useful.
Use the Parallel qualifier to indicate to Oracle RMU that you
want to perform a parallel backup operation. Use the Noexecute
and List_Plan qualifiers to generate a Backup plan file. A Backup
plan file records the backup options and specifications you enter
on the command line in a text file. You can edit this text file
to fine-tune your parallel backup operation and execute it, as
needed, with the RMU Backup Plan command. Use the Statistics
option to the Parallel qualifier if you want to monitor the
progress of the parallel backup operation with the Parallel
Backup Monitor. See the description of the Parallel, List_Plan,
and Noexecute qualifiers, and the RMU Backup Plan command for
details.
You cannot use the Parallel Backup Monitor to monitor the
progress of a non-parallel backup operation. However, you can
achieve a close approximation of this by specifying the Executor_
Count=1 and the Statistics options with the Parallel qualifier.
This results in a parallel backup operation with one executor
and one controller that you can monitor with the Parallel Backup
Monitor.
Both parallel and non-parallel backup operations allow you to
perform different types of backup operations with respect to the
portions of the database to be backed up, as described in RMU
Backup Options.
Table 4 RMU Backup Options
Storage Area Selection
Database
Page Complete By-Area
Selection (All Areas) (Selected Areas)
Full Copies the database root Copies the database
(.rdb) file and all the root (.rdb) file and
database pages in all backs up only the
the storage areas in the database pages in the
database. This is the storage areas that you
default backup operation. specify on the backup
Note that you must use command line. All the
this type of backup prior storage areas in the
to upgrading to a newer database are backed
version of Oracle Rdb. up only if you specify
Because this is the them all (or perform
default operation, no a full and complete
qualifiers are needed to backup operation). Use
specify a full backup. the Include or Exclude
qualifiers to specify
the storage areas for
a full by-area backup
operation.
Incremental Copies all database pages Copies the database
that have been updated root (.rdb) file and
since the latest full only the database
backup operation and pages for the
the database root file. specified storage
Use the Incremental (or areas that have
Incremental=Complete) changed since the
qualifier to specify an latest full backup
incremental and complete operation. Use the
backup operation. Include or Exclude
qualifier along with
the Incremental=By_
Area qualifier
to specify an
incremental, by-area,
backup operation.
Oracle Corporation recommends that you use a full backup
operation to back up a database if you have made changes in the
physical or logical design. Performing an incremental backup
operation under these circumstances can lead to the inability to
recover the database properly.
If you choose to perform a by-area backup operation, your
database can be fully recovered after a system failure only
if after-image journaling is enabled on the database. If your
database has both read/write and read-only storage areas but does
not have after-image journaling enabled, you should do complete
backup operations (backup operations on all the storage areas
in the database) at all times. Doing complete backup operations
when after-image journaling is not enabled ensures that you can
recover the entire database to its condition at the time of the
previous backup operation.
When a full backup file is created for one or more storage
areas, the date and time of the last full backup file created
for those storage areas (as recorded in the backup (.rbf) file)
is updated. You can display the date and time of the last full
backup operation on each of the storage areas in a database by
executing an RMU Dump command with the Header qualifier on the
latest backup (.rbf) file for the database. The date and time
displayed by this command is the date and time of the last full
backup operation performed for the area.
Note that an incremental backup operation on a storage area does
not update the date and time for the last full backup operation
performed on the storage area that is recorded in the backup
file.
In the event of subsequent damage to the database, you can
specify backup files in an RMU Restore command to restore the
database to the condition it was in when you backed it up.
The RMU Backup command writes backup files in compressed format
to save space. Available or free space in the database root
(.rdb) file and on each database page in a storage area (.rda)
file is not written to the backup file.
NOTE
Use only the RMU Backup command to back up all Oracle Rdb
databases. Do not back up a database by using any other
method (such as the DCL BACKUP command). The database root
of a database is updated only when the RMU Backup command is
used.
For detailed information on backing up a database to tape, see
the Oracle Rdb Guide to Database Maintenance.
2 – Format
(B)0[mRMU/Backup root-file-spec backup-file-spec
[4mCommand[m [4mQualifiers[m x [4mDefaults[m
/[No]Accept_Label x /Noaccept_Label
/[No]Acl x /Acl
/Active_IO=max-writes x /Active_IO=3
/Allocation=blocks x None
/Block_Size=integer x See description
/[No]Checksum_Verification x /Checksum_Verification
/[No]Compression[=options] x /Nocompression
/Crc[=Autodin_II] x See description
/Crc=Checksum x See description
/Nocrc x See description
/[No]Database_Verification x /Database_Verification
/Density=(density-value,[No]Compaction) x See description
/Disk_File[=options] x None
/Encrypt=({Value=|Name=}[,Algorithm=]) x See description
/Exclude[=storage-area[,...] ] x See description
/[No]Execute x See description
/Extend_Quantity=number-blocks x /Extend_Quantity=2048
/[No]Group_Size=interval x See description
/Include[=storage-area[,...] ] x See description
(B)0[m/[No]Incremental x /Noincremental
/Incremental={By_area|Complete} x None
/Journal=file-name x See description
/Label=(label-name-list) x See description
/Librarian[=options] x None
/List_Plan=output-file x See description
/Loader_Synchronization[=Fixed] x See description
/Lock_Timeout=seconds x See description
/[No]Log[=Brief|Full] x Current DCL verify switch
/Master x See description
/[No]Media_Loader x See description
/No_Read_Only x See description
/[No]Record x Record
/[No]Online x /Noonline
/Owner=user-id x See description
/Page_Buffers=number-buffers x /Page_Buffers=2
/Parallel=(Executor_Count=n[,options]) x See description
/Prompt={Automatic|Operator|Client} x See description
/Protection[=file-protection] x See description
/[No]Quiet_Point x /Quiet_Point
(B)0[m/Reader_Thread_Ratio=integer x See description
/Restore_Options=file-name x None
/[No]Rewind x /Norewind
/[No]Scan_Optimization x See description
/Tape_Expiration=date-time x The current time
/Threads=n x See description
3 – Parameters
3.1 – root-file-spec
The name of the database root file. The root file name is also
the name of the database. The default file extension is .rdb.
3.2 – backup-file-spec
The file specification for the backup file. The default file
extension is .rbf. Depending on whether you are performing a
backup operation to magnetic tape, disk, or multiple disks, the
backup file specification should be specified as follows:
o If you are backing up to magnetic tape
- Oracle Corporation recommends that you supply a backup
file name that is 17 or fewer characters in length. File
names longer than 17 characters might be truncated. See
the Usage_Notes help entry under this command for more
information about backup file names that are longer than 17
characters.
- If you use multiple tape drives, the backup-file-spec
parameter must be provided with (and only with) the first
tape drive name. Additional tape drive names must be
separated from the first and subsequent tape drive names
with commas.
See the Oracle Rdb Guide to Database Maintenance for more
information about using multiple tape drives.
o If you are backing up to multiple or single disk files
- It is good practice to write backup files to a device other
than the devices where the database root, storage area, and
snapshot files of the database are located. This way, if
there is a problem with the database disks, you can still
restore the database from a backup file.
- If you use multiple disk files, the backup-file-spec
parameter must be provided with (and only with) the first
disk device name. Additional disk device names must be
separated from the first and subsequent disk device names
with commas. You must include the Disk_File qualifier. For
example:
$ RMU/BACKUP/DISK_FILE MF_PERSONNEL.RDB -
_$ DEVICE1:[DIRECTORY1]MFP.RBF,DEVICE2:[DIRECTORY2]
As an alternative to listing the disk device names on
the command line (which, if you use several devices, can
exceed the line-limit length for a command line), you can
specify an options file in place of the backup-file-spec.
For example:
$ RMU/BACKUP/DISK_FILE LARGE_DB "@DEVICES.OPT"
The contents of devices.opt might appear as follows:
DEVICE1:[DIRECTORY1]LARGE_DB.RBF
DEVICE2:[DIRECTORY2]
The resulting backup files created from such an options
file would be:
DISK1:[DIRECTORY1]LARGE_DB.RBF
DISK2:[DIRECTORY2]LARGE_DB01.RBF
Note that the same directory must exist on each device
before you issue the command. Also, if you forget to
specify the Disk_File qualifier, you receive an error
message similar to the following:
$ RMU/BACKUP MF_PERSONNEL DEVICE1:[DIRECTORY1]MFP.RBF, -
_$ DEVICE2:[DIRECTORY2]
%RMU-F-NOTBACFIL, DEVICE1:[DIRECTORY1]MFP.RBF; is not a valid
backup file
%RMU-F-FTL_BCK,Fatal error for BACKUP operation at 2-MAY-2001
09:44:57.04
4 – Command Qualifiers
4.1 – Accept Label
Accept_Label
Specifies that RMU Backup should keep the current tape label it
finds on a tape during a backup operation even if that label
does not match the default label or that specified with the
Label qualifier. Operator notification does not occur unless
the tape's protection, owner, or expiration date prohibit writing
to the tape. However, a message is logged (assuming logging is
enabled) and written to the backup journal file (assuming you
have specified the Journal qualifier) to indicate that a label is
being preserved and which drive currently holds that tape.
This qualifier is particularly useful when your backup operation
employs numerous previously used (and thus labeled) tapes and
you want to preserve the labels currently on the tapes. However,
you are responsible for remembering the order in which tapes were
written. For this reason, it is a good idea to use the Journal
qualifier when you use the Accept_Label qualifier.
If you do not specify this qualifier, the default behavior of RMU
Backup is to notify the operator each time it finds a mismatch
between the current label on the tape and the default label (or
the label you specify with the Label qualifier).
See the description of the Labels qualifier under this command
for information on default labels. See How Tapes are Relabeled
During a Backup Operation in the Usage_Notes help entry under
this command for a summary of which labels are applied under a
variety of circumstances.
4.2 – Acl
Acl
Noacl
Specifies whether to back up the root file access control list
(ACL) for a database when you back up the database. The root file
ACL controls users privileges to issue Oracle RMU commands.
If you specify the Acl qualifier, the root file ACL will be
backed up with the database.
If you specify the Noacl qualifier, the root file ACL will not
be backed up with the database. The Noacl qualifier can be
useful if you plan to restore the database on a system where
the identifiers in the current root file ACL will not be valid.
The default is the Acl qualifier.
4.3 – Active IO
Active_IO=max-writes
Specifies the maximum number of write operations to a backup
device that the RMU Backup command will attempt simultaneously.
This is not the maximum number of write operations in progress;
that value is the product of active system I/O operations and the
number of devices being written to simultaneously.
The value of the
Active_IO qualifier can range from 1 to 5. The default value
is 3. Values larger than 3 can improve performance with some tape
drives.
4.4 – Allocation
Allocation=blocks
Specifies the size, in blocks, which the backup file is initially
allocated. The minimum value for the number-blocks parameter is
1; the maximum value allowed is 2147483647. If you do not specify
the Allocation_Quantity qualifier, the Extend_Quantity value
effectively controls the file's initial allocation.
This qualifier cannot be used with backup operations to tape.
4.5 – Block Size
Block_Size=integer
Specifies the maximum record size for the backup file. The size
can vary between 2048 and 65,024 bytes. The default value is
device dependent. The appropriate block size is a compromise
between tape capacity and error rate. The block size you specify
must be larger than the largest page length in the database.
4.6 – Checksum Verification
Checksum_Verification
Nochecksum_Verification
The Checksum_Verification qualifier requests that the RMU Backup
command verify the checksum stored on each database page before
the backup operation is applied, thereby providing end-to-end
error detection on the database I/O. The default value is
Checksum_Verification.
Oracle Corporation recommends that you accept this default
behavior for your applications. The default behavior prevents
you from including corrupt database pages in backup files
and optimized .aij files. Without the checksum verifications,
corrupt data pages in these files are not detected when the files
are restored. The corruptions on the restored page may not be
detected until weeks or months after the backup file is created,
or it is possible the corruption may not be detected at all.
The Checksum_Verification qualifier uses additional CPU resources
but provides an extra measure of confidence in the quality of the
data that is backed up.
Note that if you specify the Nochecksum qualifier, and undetected
corruptions exist in your database, the corruptions are included
in your backup file and are restored when you restore the backup
file. Such a corruption might be difficult to recover from,
especially if it is not detected until long after the restore
operation is performed.
4.7 – Compression
Compression=LZSS
Compression=Huffman
Compression=ZLIB=level
Nocompression
Allows you to specify the compression method to use before
writing data to the backup file. This reduces performance, but
may be justified when the backup file is a disk file, or is being
backed up over a busy network, or is being backed up to a tape
drive that does not do its own compression. You probably do not
want to specify the Compression qualifier when you are backing up
a database to a tape drive that does its own compression; in some
cases doing so can actually result in a larger file.
If you specify the Compression qualifier without a value, the
default is COMPRESSION=ZLIB=6.
The level value (ZLIB=level) is an integer between 1 and 9
specifying the relative compression level with one being the
least amount of compression and nine being the greatest amount
of compression. Higher levels of the compression use increased
CPU time while generally providing better compression. The
default compression level of 6 is a balance between compression
effectiveness and CPU consumption.
OLDER ORACLE RDB 7.2 RELEASES AND COMPRESSED RBF FILES
Prior releases of Oracle Rdb are unable to read RBF files
compressed with the ZLIB algorithm. In order to read
compressed backups with Oracle Rdb 7.2 Releases prior
to V7.2.1, they must be made with /COMPRESSION=LZSS or
/COMPRESSION=HUFFMAN explicitly specified (because the
default compression algorithm has been changed from LZSS to
ZLIB). Oracle Rdb Version 7.2.1 is able to read compressed
backups using the LZSS or HUFFMAN algorithms made with prior
releases.
4.8 – Crc[=Autodin II]
CRC[=AUTODIN_II]
Uses the AUTODIN-II polynomial for the 32-bit cyclic redundancy
check (CRC) calculation and provides the most reliable
end-to-end error detection. This is the default for NRZ/PE
(800/1600 bits/inch) tape drives.
If you enter only Crc as the qualifier, RMU Backup assumes you
are specifying Crc=Autodin_II.
4.9 – Crc=Checksum
Crc=Checksum
Uses one's complement addition, which is the same computation
used to do a checksum of the database pages on disk. This is the
default for GCR (6250 bits/inch) tape drives and for TA78, TA79,
and TA81 tape drives.
The Crc=Checksum qualifier allows detection of data errors.
4.10 – Nocrc
Nocrc
Disables end-to-end error detection. This is the default for TA90
(IBM 3480 class) drives.
NOTE
The overall effect of the Crc=Autodin_II, Crc=Checksum, and
Nocrc qualifier defaults is to make tape reliability equal
to that of a disk. If you retain your tapes longer than 1
year, the Nocrc default might not be adequate. For tapes
retained longer than 1 year, use the Crc=Checksum qualifier.
If you retain your tapes longer than 3 years, you should
always use the Crc=Autodin_II qualifier.
Tapes retained longer than 5 years could be deteriorating
and should be copied to fresh media.
See the Oracle Rdb Guide to Database Maintenance for details
on using the Crc qualifiers to avoid underrun errors.
4.11 – Database Verification
Database_Verification
Nodatabase_Verification
The RMU /BACKUP command performs a limited database root
file verification at the start of the backup operation. This
verification is intended to help prevent backing up a database
with various detectable corruptions or inconsistancies of the
root file or associated database structures. However, in some
limited cases, it can be desirable to avoid these checks.
The qualifier /NODATABASE_VERIFICATION may be specified to avoid
the database root file verification at the start of the backup.
The default behavior is /DATABASE_VERIFICATION. Oracle strongly
recommends accepting the default of /DATABASE_VERIFICATION.
4.12 – Density
Density=(density-value,[No]Compaction)
Specifies the density at which the output volume is to be
written. The default value is the format of the first volume (the
first tape you mount). You do not need to specify this qualifier
unless your tape drives support data compression or more than one
recording density.
The Density qualifier is applicable only to tape drives. RMU
Backup returns an error message if this qualifier is used and the
target device is not a tape drive.
If you specify a density value, RMU Backup assumes that all tape
drives can accept that value.
If your systems are running OpenVMS versions prior to 7.2-1,
specify the Density qualifier as follows:
o For TA90E, TA91, and TA92 tape drives, specify the number in
bits per inch as follows:
- Density = 70000 to initialize and write tapes in the
compacted format.
- Density = 39872 or Density = 40000 for the noncompacted
format.
o For SCSI (Small Computer System Interface) tape drives,
specify Density = 1 to initialize and write tapes by using
the drive's hardware data compression scheme.
o For other types of tape drives you can specify a supported
density value between 800 and 160000 bits per inch.
o For all tape drives, specify Density = 0 to initialize and
write tapes at the drive's standard density.
Do not use the Compaction or NoCompaction keyword for systems
running OpenVMS versions prior to 7.2-1. On these systems,
compression is determined by the density value and cannot be
specified.
Oracle RMU supports the OpenVMS tape density and compression
values introduced in OpenVMS Version 7.2-1. The following table
lists the added density values supported by Oracle RMU.
DEFAULT 800 833 1600
6250 3480 3490E TK50
TK70 TK85 TK86 TK87
TK88 TK89 QIC 8200
8500 8900 DLT8000
SDLT SDLT320 SDLT600
DDS1 DDS2 DDS3 DDS4
AIT1 AIT2 AIT3 AIT4
LTO2 LTO3 COMPACTION NOCOMPACTION
If the OpenVMS Version 7.2-1 density values and the previous
density values are the same (for example, 800, 833, 1600, 6250),
the specified value is interpreted as an OpenVMS Version 7.2-1
value if the tape device driver accepts them, and as a previous
value if the tape device driver accepts previous values only.
For the OpenVMS Version 7.2-1 values that accept tape compression
you can use the following syntax:
/DENSITY = (new_density_value,[No]Compaction)
In order to use the Compaction or NoCompaction keyword, you must
use one of the following density values that accepts compression:
DEFAULT 3480 3490E 8200
8500 8900 TK87 TK88
TK89 DLT8000 SDLT SDLT320
AIT1 AIT2 AIT3 AIT4
DDS1 DDS2 DDS3 DDS4
SDLT600 LTO2 LTO3
Refer to the OpenVMS documentation for more information about
density values.
4.13 – Disk File
Disk_File[=(options)]
Specifies that you want to perform a multithreaded backup
operation to disk files, floppy disks, or other disks external
to the PC. You can use the following keywords with the Disk_File
qualifier:
o Writer_Threads
Specifies the number of threads that Oracle RMU should use
when performing a multithreaded backup operation to disk
files. You can specify no more than one writer thread per
device specified on the command line (or in the command
parameter options file). By default, one writer thread is
used.
This qualifier and all qualifiers that control tape operations
(Accept_Label, Density, Label, Loader_Synchronization, Master,
Media_Loader, Rewind, and Tape_Expiration) are mutually
exclusive.
4.14 – Encrypt
Encrypt=({Value=|Name=}[,Algorithm=])
The Encrypt qualifier encrypts the save set file of a database
backup.
Specify a key value as a string or, the name of a predefined
key. If no algorithm name is specified the default is DESCBC.
For details on the Value, Name and Algorithm parameters see HELP
ENCRYPT.
This feature requires the OpenVMS Encrypt product to be installed
and licensed on this system.
4.15 – Exclude
Exclude[=storage-area[,...]]
Specifies the storage areas that you want to exclude from the
backup file. If you specify neither the Exclude nor the Include
qualifier with the RMU Backup command, or if you specify the
Exclude qualifier but do not specify a list of storage area
names, a full and complete backup operation is performed on the
database. This is the default behavior.
If you specify a list of storage area names with the Exclude
qualifier, RMU Backup excludes those storage areas from the
backup file and includes all of the other storage areas. If
you specify more than one database storage area in the Exclude
qualifier, place a comma between each storage area name and
enclose the list of names within parentheses.
Use the Exclude=* qualifier to indicate that you want only the
database root file to be backed up. Note that a backup file
created with the Exclude=* qualifier can be restored only with
the RMU Restore Only_Root command.
You can use an indirect command file as shown in the following
example:
$ RMU/BACKUP/EXCLUDE="@EXCLUDE_AREAS.OPT" -
_$ MF_PERSONNEL.RDB PARTIAL_MF_PERS.RBF
%RMU-I-NOTALLARE, Not all areas will be included in this backup file
See the Indirect-Command-Files help entry for more information on
indirect command files.
If you use the Exclude qualifier with a list of storage area
names, your backup file will be a by-area backup file because
the Exclude qualifier causes database storage areas to be
excluded from the backup file. The following example shows the
informational message you receive if you do not back up all of
the areas in the database:
%RMU-I-NOTALLARE, Not all areas will be included in this backup file
By using the RMU Backup and RMU Restore commands, you can back up
and restore selected storage areas of your database. This Oracle
RMU backup and restore by-area feature is designed to:
o Speed recovery when corruption occurs in some (not all) of the
storage areas of your database
o Reduce the time needed to perform backup operations because
some data (data in read-only storage areas, for example) does
not need to be backed up with every backup operation performed
on the database
If you plan to use the RMU Backup and RMU Restore commands to
back up and restore only selected storage areas for a database,
you should perform full and complete backup operations on the
database at regular intervals.
If you plan to back up and restore only selected storage areas of
a database, Oracle Corporation also strongly recommends that you
enable after-image journaling for the database. This ensures that
you can recover all of the storage areas in your database if a
system failure occurs.
If you do not have after-image journaling enabled and one or
more of the areas restored with the RMU Restore command are not
consistent with the unrestored storage areas, Oracle Rdb does
not allow any transaction to use the storage areas that are not
consistent in the restored database. In this situation, you can
return to a working database by restoring the database, using
the backup file from the last full and complete backup operation
of the database storage areas. However, any changes made to the
database since the last full and complete backup operation are
not recoverable.
If you do have after-image journaling enabled, use the
RMU Recover command (or the Restore command with the Recover
qualifier) to apply transactions from the .aij file to storage
areas that are not consistent after the RMU Restore command
completes; that is, storage areas that are not in the same state
as the rest of the restored database. You cannot use these areas
until you recover the database. When the RMU Recover command
completes, your database will be consistent and usable.
Using the Exclude or Include qualifier gives you greater
flexibility for your backup operations, along with increased
file management and recovery complexity. Users of large databases
might find the greater flexibility of the backup operation to
be worth the cost of increased file management and recovery
complexity.
You cannot specify the Exclude=area-list and Include=area-list
qualifiers in the same RMU Backup command.
4.16 – Execute
Execute
Noexecute
Use the Execute and Noexecute qualifiers with the Parallel and
List_Plan qualifiers to specify whether or not the backup plan
file is to be executed.
The following list describes the effects of using the Execute and
Noexecute qualifier:
o Execute
Creates, verifies, and executes a backup list plan
o Noexecute
Creates and verifies, but does not execute a backup list plan.
The verification determines such things as whether the storage
areas listed in the plan file exist in the database.
The Execute and Noexecute qualifiers are only valid when the
Parallel and List_Plan qualifiers are also specified.
If you specify the Execute or Noexecute qualifier without the
List_Plan and Parallel qualifiers, RMU Backup generates and
verifies a temporary backup list plan, but then deletes the
backup list plan and returns a fatal error message.
By default, the backup plan file is executed when you issue an
RMU Backup command with the Parallel and List_Plan qualifiers.
4.17 – Extend Quantity
Extend_Quantity=number-blocks
Sets the size, in blocks, by which the backup file can be
extended. The minimum value for the number-blocks parameter is
1; the maximum value is 65535. If you do not specify the Extend_
Quantity qualifier, the default number of blocks by which an
on-disk backup file can be extended is 2048 blocks.
This qualifier cannot be used with backup operations to tape.
4.18 – Group Size
Group_Size=interval
Nogroup_Size
Specifies the frequency at which XOR recovery blocks are written
to tape. The group size can vary from 0 to 100. Specifying a
group size of zero or specifying the Nogroup_Size qualifier
results in no XOR recovery blocks being written. The Group_Size
qualifier is only applicable to tape, and its default value is
10. RMU Backup returns an error message if this qualifier is used
and the target device is not a tape device.
4.19 – Include
Include[=storage-area[,...]]
Specifies storage areas that you want to include in the backup
file. If you specify neither the Include nor the Exclude
qualifier with the RMU Backup command, a full and complete
backup operation is performed on the database by default. You
can specify the Include=* qualifier to indicate that you want
all storage areas included in the backup file, but this is
unnecessary because this is the default behavior. The default
behavior is performed also when you specify the Include qualifier
without specifying a list of storage area names.
If you specify a list of storage area names with the Include
qualifier, Oracle RMU includes those storage areas in the backup
operation and excludes all of the other storage areas. If you
specify more than one database storage area in the Include
qualifier, place a comma between each storage area name and
enclose the list of names within parentheses.
You cannot specify the Exclude=area-list and Include=area-list
qualifiers in the same RMU Backup command.
If you use the Include qualifier, your backup operation will be
a by-area backup operation because the areas not specified with
the Include qualifier are excluded from the backup file. If you
do not back up all of the areas in the database, you receive the
following informational message:
%RMU-I-NOTALLARE, Not all areas will be included in this backup file
By using the RMU Backup and RMU Restore commands, you can back up
and restore selected storage areas of your database. This Oracle
RMU backup and restore by area feature is designed to:
o Speed recovery when corruption occurs in some (not all) of the
storage areas of your database
o Reduce the time needed to perform backup operations because
some data (data in read-only storage areas, for example) does
not need to be backed up with every backup operation performed
on the database
See the description of the Exclude qualifier for information on
the implications of using these commands to back up and restore
selected areas of your database.
The Include qualifier can be used with indirect file references.
See the Indirect-Command-Files help entry for more information.
4.20 – Incremental
Incremental[=By_Area or Complete]
Noincremental
Determines the extent of the backup operation to be performed.
The four possible options are:
o Noincremental
If you do not specify any of the possible Incremental
qualifier options, the default is the Noincremental qualifier.
With the Noincremental qualifier, a full backup operation is
performed on the database.
o Incremental
If you specify the Incremental qualifier, an incremental
backup of all the storage areas that have changed since the
last full and complete backup operation on the database is
performed.
o Incremental=By_Area
If you specify the Incremental=By_Area qualifier, an
incremental backup operation is performed. The Incremental=By_
Area qualifier backs up those database pages that have
changed in each selected storage area since the last full
backup operation was performed on the area. The last full
backup operation performed on the area is the later of the
following:
- The last full and complete backup operation performed on
the database
- The last full by-area backup operation performed on the
area
With an incremental by-area backup operation, each storage
area backed up might contain changes for a different time
interval, which can make restoring multiple storage areas more
complex.
o Incremental=Complete
If you specify the Incremental=Complete qualifier, an
incremental backup operation on all of the storage areas
that have changed since the last full and complete backup
operation on the database is performed. Selecting the
Incremental=Complete qualifier is the same as selecting the
Incremental qualifier.
Following a full database backup operation, each subsequent
incremental backup operation replaces all previous incremental
backup operations.
The following two messages are meant to provide an aid for
designing more effective backup strategies. They are printed
as part of the per-area summary statistics, and they provide a
guide to the incremental benefit of the incremental operation:
o "Est. cost to backup relative to a full backup is x.yy"
o "Est. cost to restore relative to a full restore is x.yy"
These estimates are only approximate and reflect the disk
input/output (I/O) cost for the backup or restore operations
of that area. Tape I/O, CPU, and all other costs are ignored.
The disk I/O costs take into account the number of I/O operations
needed and the requirement for a disk head seek to perform the
I/O. Each disk type has its own relative costs-transfer rate,
latency, seek time-and the cost of a given sequence of I/Os is
also affected by competition for the disk by other processes.
Consequently, the estimates do not translate directly into "clock
time." But they should nevertheless be useful for determining
the point at which the incremental operation is becoming less
productive.
The relative costs can vary widely, and can be much higher than
1.00. The actual cost depends on the number and location of the
pages backed up. An incremental restore operation must always
follow a full restore operation, so the actual estimate of
restoring the area is actually 1.00 higher than reported when
that full restore operation is accounted for. The guideline that
Oracle Corporation recommends is, "Perform full backup operations
when the estimated cost of a restore operation approaches 2.00."
4.21 – Journal
Journal=file-name
Allows you to specify a journal file to be used to improve
tape performance during a restore operation. (This is not to
be confused with an after-image journal file.)
As the backup operation progresses, RMU Backup creates the
journal file and writes to it a description of the backup
operation containing identification of the tape drive names and
the tape volumes and their contents. The default file extension
is .jnl.
The journal file must be written to disk; it cannot be written to
tape along with the backup file. (Although you can copy the disk
file to tape after it is written, if desired.)
This journal file is used with the RMU Restore and the RMU Dump
Backup commands to optimize their tape utilization.
4.22 – Label
Label=(label-name-list)
Specifies the 1- to 6-character string with which the volumes
of the backup file are to be labeled. The Label qualifier is
applicable only to tape volumes. You must specify one or more
label names when you use the Label qualifier.
If you do not specify the Label (or Accept_Label) qualifier,
RMU Backup labels the first tape used for a backup operation
with the first 6 characters of the backup file name. Subsequent
default labels are the first 4 characters of the backup file name
appended with a sequential number. For example, if your backup
file is my_backup.rbf, the default tape labels are my_bac, my_
b01, my_b02, and so on.
When you reuse tapes, RMU Backup compares the label currently
on the tape to the label or labels you specify with the Label
qualifier. If there is a mismatch between the existing label and
a label you specify, RMU Backup sends a message to the operator
asking if the mismatch is acceptable (unless you also specify the
Accept_Labels qualifier).
If desired, you can explicitly specify the list of tape labels
for multiple tapes. If you list multiple tape label names,
separate the names with commas and enclose the list of names
within parentheses. If you are reusing tapes be certain that
you load the tapes so that the label RMU Backup expects and the
label on each tape will match, or be prepared for a high level
of operator intervention. Alternatively, you can specify the
Accept_Label qualifier. In this case, the labels you specify with
the Label qualifier are ignored if they do not match the labels
currently on the tapes and no operator intervention occurs.
If you specify fewer labels than are needed, RMU Backup generates
labels based on the format you have specified. For example, if
you specify Label=TAPE01, RMU Backup labels subsequent tapes as
TAPE02, TAPE03, and so on up to TAPE99. Thus, many volumes can
be preloaded in the cartridge stacker of a tape drive. The order
is not important because RMU Backup relabels the volumes. An
unattended backup operation is more likely to be successful if
all the tapes used do not have to be mounted in a specific order.
Once the backup operation is complete, externally mark the tapes
with the appropriate label so that the order can be maintained
for the restore operation. Be particularly careful if you are
allowing RMU Backup to implicitly label second and subsequent
tapes and you are performing an unattended backup operation.
Remove the tapes from the drives in the order in which they
were written. Apply labels to the volumes following the logic
of implicit labeling (for example, TAPE02, TAPE03, and so on).
Oracle recommends you use the Journal qualifier when you employ
implicit labeling in a multidrive, unattended backup operation.
The journal file records the volume labels that were written
to each tape drive. The order in which the labels were written
is preserved in the journal. Use the RMU Dump Backup command to
display a listing of the volumes written by each tape drive.
You can use an indirect file reference with the Label qualifier.
See the Indirect-command-files help entry for more information.
See How Tapes are Relabeled During a Backup Operation in the
Usage_Notes help entry under this command for a summary of which
labels are applied under a variety of circumstances.
4.23 – Librarian
Librarian=options
Use the Librarian qualifier to back up files to data archiving
software applications that support the Oracle Media Management
interface. The backup file name specified on the command line
identifies the stream of data to be stored in the Librarian
utility. If you supply a device specification or a version number
it will be ignored.
You can use the Librarian qualifier for parallel backup
operations. The Librarian utility should be installed and
available on all nodes on which the parallel backup operation
executes.
The Librarian qualifier accepts the following options:
o Writer_Threads=n
Use the Writer_Threads option to specify the number of backup
data streams to write to the Librarian utility. The value of n
can be from 1 to 99. The default is one writer thread.
Each writer thread for a backup operation manages its own
stream of data. Therefore, each thread uses a unique backup
file name. The unique names are generated by incrementing the
number added to the end of the backup file name. For example,
if you specify the following Oracle RMU Backup command:
$RMU/ BACKUP /LIBRARIAN=(WRITER_THREADS=3) /LOG DB FILENAM.RBF
The following backup file data stream names are generated:
FILENAME.RBF
FILENAME.RBF02
FILENAME.RBF03
Because each data stream must contain at least one database
storage area, and a single storage area must be completely
contained in one data stream, if the number of writer threads
specified is greater than the number of storage areas, it is
set equal to the number of storage areas.
o Trace_file=file-specification
The Librarian utility writes trace data to the specified file.
o Level_Trace=n
Use this option as a debugging tool to specify the level of
trace data written by the Librarian utility. You can use a
pre-determined value of 0, 1, or 2, or a higher value defined
by the Librarian utility. The pre-determined values are :
- Level 0 traces all error conditions. This is the default.
- Level 1 traces the entry and exit from each Librarian
function.
- Level 2 traces the entry and exit from each Librarian
function, the value of all function parameters, and the
first 32 bytes of each read/write buffer, in hexadecimal.
o Logical_Names=(logical_name=equivalence-value,...)
You can use this option to specify a list of process logical
names that the Librarian utility can use to specify catalogs
or archives where Oracle Rdb backup files are stored,
Librarian debug logical names, and so on. See the specific
Librarian documentation for the definition of logical names.
The list of process logical names is defined by Oracle RMU
prior to the start of any Oracle RMU command that accesses the
Librarian utility.
The following OpenVMS logical names must be defined for use with
a Librarian utility before you execute an Oracle RMU backup or
restore operation. Do not use the Logical_Names option provided
with the Librarian qualifier to define these logical names.
o RMU$LIBRARIAN_PATH
This logical name must be defined so that the shareable
Librarian image can be loaded and called by Oracle RMU backup
and restore operations. The translation must include the file
type (for example, .exe), and must not include a version
number. The shareable Librarian image must be an installed
(known) image. See the Librarian utility documentation for
the name and location of this image and how it should be
installed. For a parallel RMU backup, define RMU$LIBRARIAN_
PATH as a system-wide logical name so that the multiple
processes created by a parallel backup can all translate the
logical.
$ DEFINE /SYSTEM /EXECUTIVE_MODE -
_$ RMU$LIBRARIAN_PATH librarian_shareable_image.exe
o RMU$DEBUG_SBT
This logical name is not required. If it is defined, Oracle
RMU will display debug tracing information messages from
modules that make calls to the Librarian shareable image.
For a parallel RMU backup, the RMU$DEBUG_SBT logical should
be defined as a system logical so that the multiple processes
created by a parallel backup can all translate the logical.
The following lines are from a backup plan file created by the
RMU Backup/Parallel/Librarian command:
Backup File = MF_PERSONNEL.RBF
Style = Librarian
Librarian_trace_level = #
Librarian_logical_names = (-
logical_name_1=equivalence_value_1, -
logical_name_2=equivalence_value_2)
Writer_threads = #
The "Style = Librarian" entry specifies that the backup is going
to a Librarian utility. The "Librarian_logical_names" entry is
a list of logical names and their equivalence values. This is an
optional parameter provided so that any logical names used by a
particular Librarian utility can be defined as process logical
names before the backup or restore operation begins. For example,
some Librarian utilities provide support for logical names for
specifying catalogs or debugging.
You cannot use device specific qualifiers such as Rewind,
Density, or Label with the Librarian qualifier because the
Librarian utility handles the storage meda, not Oracle RMU.
4.24 – List Plan
List_Plan=output-file
Specifies that RMU Backup should generate a backup plan file for
a parallel backup operation and write it to the specified output
file. A backup plan file is a text file that contains qualifiers
that can be specified on the RMU Backup command line. Qualifiers
that you do not specify on the command line appear as comments
in the backup list plan file. In addition, the backup plan file
specifies the worker executor names along with the system node,
storage areas, and tape drives assigned to each worker executor.
You can use the generated backup plan file as a starting point
for building a parallel backup operation to tape that is tuned
for your particular configuration. The output file can be
customized and then used with the RMU Backup Plan command. See
Backup Plan for details.
If you specify the Execute qualifier with the List_Plan
qualifier, the backup plan file is generated, verified, and
executed. If you specify the Noexecute qualifier with the List_
Plan qualifier, the backup plan file is generated and verified,
but not executed.
By default, the backup plan file is executed.
The List_Plan qualifier is only valid when the Parallel qualifier
is also specified.
4.25 – Loader Synchronization
Loader_Synchronization[=Fixed]
Allows you to preload tapes and preserve tape order to minimize
the need for operator support. When you specify the Loader_
Synchronization qualifier and specify multiple tape drives,
the backup operation writes to the first set of tape volumes
concurrently then waits until each tape in the set is finished
before assigning the next set of tape volumes. This ensures
that the tape order can be preserved in the event that a restore
operation from these tapes becomes necessary.
One disadvantage with using the Loader_Synchronization qualifier
with the Label qualifier is that because not all tape threads
back up equal volumes of data, some threads may not need a
subsequent tape to back up the assigned volume of data. In order
to preserve the tape order, operator intervention may be needed
to load the tapes in stages as backup threads become inactive.
Use the keyword Fixed to force the assignment of tape labels to
the drives regardless of how many tapes each drive actually uses.
The Loader_Synchronization qualifier does result in reduced
performance. For maximum performance, no drive should remain
idle, and the next identified volume should be placed on the
first drive that becomes idle. However, because the order in
which the drives become idle depends on many uncontrollable
factors and cannot be predetermined, without the Loader_
Synchronization qualifier, the drives cannot be preloaded with
tapes. (If you do not want to relabel tapes, you might find that
the Accept_Label qualifier is a good alternative to using the
Loader_Synchronization qualifier. See the description of the
Accept_Label qualifier for details.)
Because the cost of using the Loader_Synchronization qualifier is
dependent on the hardware configuration and the system load, the
cost is unpredictable. A 5% to 20% additional elapsed time for
the operation is typical. You must determine whether the benefit
of a lower level of operator support compensates for the loss of
performance. The Loader_Synchronization qualifier is most useful
for large backup operations.
See the Oracle Rdb Guide to Database Maintenance for more
information on using the Loader_Synchronization qualifier,
including information on when this qualifier might lead to
unexpected results, and details on how this qualifier interacts
with other RMU Backup command qualifiers.
For very large backup operations requiring many tape volumes,
managing the physical marking of tape volumes can be difficult.
In such a case, you might consider using a library or archiving
to automatically manage tape labeling for you.
4.26 – Lock Timeout
Lock_Timeout=seconds
Determines the maximum time the backup operation will wait for
the quiet-point lock and any other locks needed during online
backup operations. When you specify the Lock_Timeout=seconds
qualifier, you must specify the number of seconds to wait for the
quiet-point lock. If the time limit expires, an error is signaled
and the backup operation fails.
When the Lock_Timeout=seconds qualifier is not specified, the
backup operation will wait indefinitely for the quiet-point lock
and any other locks needed during an online backup operation.
The Lock_Timeout=seconds qualifier is ignored for offline backup
operations.
4.27 – Log
Log
Log=Brief
Log=Full
Nolog
Specifies whether the processing of the command is reported
to SYS$OUTPUT. Specify the Log qualifier to request that the
progress of the restore operation be written to SYS$OUTPUT,
or the Nolog qualifier to suppress this report. If you specify
the Log=Brief option, which is the default if you use the Log
option without a qualifier, the log contains the start and
completion time of each storage area. If you specify the Log=Full
option, the log also contains thread assignment and storage area
statistics messages.
If you do not specify the Log or the Nolog qualifier, the default
is the current setting of the DCL verify switch. (The DCL SET
VERIFY command controls the DCL verify switch.)
4.28 – Master
Master
Controls the assignment of tape drives to output threads by
allowing you to specify a tape drive as a master tape drive. This
is a positional qualifier specified with a tape drive. When the
Master qualifier is used, it must be used on the first tape drive
specified. When the Master qualifier is specified, all additional
tape drives become slaves for that tape drive until the end of
the command line, or until the next Master qualifier, whichever
comes first.
If you specify the Master qualifier (without also specifying the
Loader_Synchronization qualifier) on sets of tape drives, each
master/slave set of tape drives will operate independently of
other master/slave sets. If the Master qualifier is used on a
tape drive that is not physically a master tape drive, the output
performance of the backup operation will decrease.
See the Oracle Rdb Guide to Database Maintenance for complete
details on the behavior of the master qualifier.
4.29 – Media Loader
Media_Loader
Nomedia_Loader
Use the Media_Loader qualifier to specify that the tape device
receiving the backup file has a loader or stacker. Use the
Nomedia_Loader qualifier to specify that the tape device does
not have a loader or stacker.
By default, if a tape device has a loader or stacker, RMU Backup
should recognize this fact. However, occasionally RMU Backup
does not recognize that a tape device has a loader or stacker.
Therefore, when the first backup tape fills, RMU Backup issues a
request to the operator for the next tape, instead of requesting
the next tape from the loader or stacker. Similarly, sometimes
RMU Backup behaves as though a tape device has a loader or
stacker when actually it does not.
If you find that RMU Backup is not recognizing that your tape
device has a loader or stacker, specify the Media_Loader
qualifier. If you find that RMU Backup expects a loader or
stacker when it should not, specify the Nomedia_Loader qualifier.
4.30 – No Read Only
No_Read_Only
Allows you to specify that you do not want any of the read-only
storage areas in your database to be backed up when you back up
the database.
If you do not specify the No_Read_Only qualifier, any read-only
storage area not specified with the Exclude qualifier will be
included in the backup file. The No_Read_Only qualifier allows
you to back up a database with many read-only storage areas
without having to type a long list of read-only storage area
names with the Exclude qualifier.
If you specify the No_Read_Only qualifier, read-only storage
areas are not backed up even if they are explicitly listed by the
Include qualifier.
There is no Read_Only qualifier.
4.31 – Record
Record
Norecord
The Record qualifier is set by default. Using the Norecord
qualifier allows you to avoid the modification of the database
with recent backup information. Hence the database appears as if
it had not been backed up at this time.
The main purpose of this qualifier is to allow a backup of a Hot
Standby database without modifying the database files.
The Norecord qualifier can be negated with the Record qualifier.
4.32 – Online
Online
Noonline
Specifying the Online qualifier permits users running active
transactions at the time the command is entered to continue
without interruption (unless the Noquiet_Point qualifier is also
specified).
Any subsequent transactions that start during the online backup
operation are permitted as long as the transactions do not
require exclusive access to the database, a table, or any index
structure currently being backed up.
To perform an online database backup operation, snapshots (either
immediate or deferred) must be enabled. You can use the Online
qualifier with the Incremental or Noincremental qualifiers.
If you use the default, the Noonline qualifier, users cannot be
attached to the database. If a user has invoked the database and
the RMU Backup command is entered with the Noonline qualifier (or
without the Online qualifier), an Oracle RMU error results. For
example:
%RMU-I-FILACCERR, error opening database root file DB_DISK:MF_PERSONNEL.RDB;1
-SYSTEM-W-ACCONFLICT, file access conflict
The offline backup process (specified with the Noonline
qualifier) has exclusive access to the database and does not
require snapshot (.snp) files in order to work. The snapshot
files can be disabled when the Noonline qualifier is used.
Oracle Corporation recommends that you close the database (with
the RMU Close command) when you perform the offline backup
operation on a large database. If the database was opened with
the SQL OPEN IS MANUAL statement, the RMU Backup command will
fail unless the RMU Close command is used. If the database was
opened with the SQL OPEN IS AUTOMATIC statement, the RMU Backup
command might fail if the activity level is high (that is, users
might access the database before the database is taken off line).
Issuing the RMU Close command can force the users out of the
database and give the RMU Backup command a chance to start;
however, although recommended, issuing the RMU Close command
is not required in this case.
Synonymous with the Owner qualifier. See the description of the
Owner qualifier.
4.33 – Owner
Owner=user-id
Specifies the owner of the tape volume set. The owner is the
user who will be permitted to restore the database. The user-id
parameter must be one of the following types of identifier:
o A user identification code (UIC) in [group-name,member-name]
alphanumeric format
o A user identification code (UIC) in [group-number,member-
number] numeric format
o A general identifier, such as SECRETARIES
o A system-defined identifier, such as DIALUP
The Owner qualifier cannot be used with a backup operation to
disk. When used with tapes, the Owner qualifier applies to all
continuation volumes. The Owner qualifier applies to the first
volume only if the Rewind qualifier is also specified.
If the Rewind qualifier is not specified, the backup operation
appends the file to a previously labeled tape, so the first
volume can have a protection different from the continuation
volumes.
See the Oracle Rdb Guide to Database Maintenance for information
on tape label processing.
4.34 – Page Buffers
Page_Buffers=number-buffers
Specifies the number of disk buffers assigned to each storage
area thread.
The range is 2 to 5 with a default of 2.
The higher values speed up scans for changed pages during an
incremental backup operation, but they exact a cost in memory
usage and larger working set requirements.
4.35 – Parallel
Parallel=(Executor_Count=n[,options])
Specifies that you want to perform a parallel backup operation.
When you issue an RMU Backup command with the parallel qualifier,
RMU Backup generates a plan file. This plan file describes how
the parallel backup operation should be executed. If you specify
the Noexecute qualifier, the plan file is generated, but not
executed. If you specify the Execute qualifier (or accept the
default), the plan file is executed immediately after RMU Backup
creates it.
The Executor_Count specifies the number of worker executors you
want to use for the parallel backup operation. The number of
worker executors must be equal to or less than the number of tape
drives you intend to use. If you specify Executor_Count=1, the
result is a non-parallel backup operation that is executed using
the parallel backup procedure, including creation of the plan
file and a dbserver process.
You can specify one, both, or none of the following options:
o Node=(node-list)
The Node=(node-list) option specifies the names of the nodes
in the cluster where the worker executors are to run. If more
than one node is specified, all nodes must be in the same
cluster and the database must be accessible from all nodes in
the cluster.
In addition, for a backup operation across nodes in a cluster
to be successful, whoever starts SQL/Services must have
proxy access among all nodes involved in the backup operation
(assuming you are using DECnet). For example, if you specify
the Nodes=(NODE1, NODE2, NODE3) as an option to the Parallel
qualifier, whomever started SQL/Services must have access
from NODE1 to NODE2, NODE1 to NODE3, NODE2 to NODE1, NODE2 to
NODE3, NODE3 to NODE1, and NODE3 to NODE2.
Separate node names in the node-list with commas. If you do
not specify the Nodes option, all worker executors run on the
node from which the parallel backup plan file is executed.
o Server_Transport=(DECnet|TCP)
To execute a parallel backup operation, SQL/Services must
be installed on your system. By default, the RMU Backup
command uses DECnet to access SQL/Services; if DECnet is
not available, RMU Backup tries to use TCP/IP. Use the
Server_Transport option to set the default behavior such
that RMU Backup tries TCP/IP first. You can also use the
SQL_NETWORK_TRANSPORT_TYPE configuration parameter to modify
the default behavior. See the Oracle Rdb Installation and
Configuration Guide for details on setting the SQL_NETWORK_
TRANSPORT_TYPE configuration parameter.
o Statistics
Specifies that you want RMU Backup to gather statistics
on the parallel backup operation for use with the Parallel
Backup Monitor. You must invoke the Parallel Backup Monitor, a
Windowing interface, to view these statistics.
To execute a parallel backup operation, SQL/Services must be
installed on your system. By default, the RMU Backup command
uses DECnet to access SQL/Services; if DECnet is not available,
RMU Backup tries to use TCP/IP. You can use the SQL_NETWORK_
TRANSPORT_TYPE configuration parameter to set the default
behavior such that RMU Backup tries TCP/IP first. See the Oracle
Rdb Installation and Configuration Guide for details on setting
the SQL_NETWORK_TRANSPORT_TYPE configuration parameter.
Note that during a parallel backup operation, all tape requests
are sent to the Operator; the parallel backup operation does not
send tape requests to the user who issues the Backup command.
Therefore, you should issue the DCL REPLY/ENABLE=TAPES command
from the terminal that serves the operator before issuing the RMU
Backup command.
4.36 – Prompt
Prompt=Automatic
Prompt=Operator
Prompt=Client
Specifies where server prompts are to be sent. When you specify
Prompt=Automatic, prompts are sent to the standard input device,
and when you specify Prompt=Operator, prompts are sent to the
server console. When you specify Prompt=Client, prompts are sent
to the client system.
4.37 – Protection
Protection[=file-protection]
Specifies the system file protection for the backup file produced
by the RMU Backup command.
The default file protection varies, depending on whether you
backup the file to disk or tape. This is because tapes do not
allow delete or execute access and the SYSTEM account always
has both read and write access to tapes. In addition, a more
restrictive class accumulates the access rights of the less
restrictive classes.
If you do not specify the Protection qualifier, the default
protection is as follows:
o S:RWED,O:RE,G,W if the backup is to disk
o S:RW,O:R,G,W if the backup is to tape
If you specify the Protection qualifier explicitly, the
differences in protection applied for backups to tape or disk
as noted in the preceding paragraph are applied. Thus, if you
specify Protection=(S,O,G:W,W:R), that protection on tape becomes
(S:RW,O:RW,G:RW,W:R).
4.38 – Quiet Point
Quiet_Point
Noquiet_Point
Allows you to specify that the database backup operation is to
occur either immediately or when a quiet point for database
activity occurs. A quiet point is defined as a point where no
active update transactions are in progress in the database.
Therefore, this qualifier is used with the Online qualifier.
When you specify the Noquiet_Point qualifier, RMU Backup proceeds
with the backup operation as soon as the RMU Backup command is
issued, regardless of any update transaction activity in progress
in the database. Because RMU Backup must acquire concurrent-
read locks on all physical and logical areas, the backup
operation will fail if there are any active transactions with
exclusive locks on a storage area. However, once RMU Backup has
successfully acquired all concurrent-read storage area locks it
should not encounter any further lock conflicts. If a transaction
that causes Oracle Rdb to request exclusive locks is started
while the backup operation is proceeding, that transaction will
either wait or receive a lock conflict error, but the RMU Backup
command will continue unaffected.
See the Usage_Notes help entry under this command for
recommendations on using the Quiet_Point and Noquiet_Point
qualifiers.
The default is the Quiet_Point qualifier.
4.39 – Reader Thread Ratio
Reader_Thread_Ratio=integer
This qualifier has been deprecated. Use the /Threads qualifier
instead.
4.40 – Restore Options
Restore_Options=file-name
Generates an options file designed to be used with the Options
qualifier of the RMU Restore command. If you specify a full
backup operation, all the storage areas will be represented in
the options file. If you specify a by-area backup operation, only
those areas included in the backup will be represented in the
options file.
The Restore_Options file is created at the end of the backup
operation.
By default, a Restore_Options file is not created. If you
specify the Restore_Options qualifier and a file, but not a file
extension, RMU Backup uses an extension of .opt by default.
4.41 – Rewind
Rewind
Norewind
Specifies that the magnetic tape that contains the backup file
will be rewound before processing begins. The tape will be
initialized according to the Label and Density qualifiers. The
Norewind qualifier is the default and causes the backup file to
be created starting at the current logical end-of-tape (EOT).
The Rewind and Norewind qualifiers are applicable only to tape
devices. RMU Backup returns an error message if these qualifiers
are used and the target device is not a tape device.
4.42 – Scan Optimization
Scan_Optimization
Noscan_Optimization
Specifies whether or not RMU Backup should employ scan
optimizations during incremental backup operations.
By default, RMU Backup optimizes incremental backup operations
by scanning regions of the database that have been updated since
the last full backup operation. The identity of these regions
is stored in the database. Only these regions need to be scanned
for updates during an incremental backup operation. This provides
a substantial performance improvement when database activity is
sufficiently low.
However, there is a cost in recording this information in the
database. In some circumstances the cost might be too high,
particularly if you do not intend to use incremental backup
operations.
The Scan_Optimization qualifier has different effects, depending
on the type of backup operation you perform. In brief, you can
enable or disable the scan optimization setting only when you
issue a full offline backup command, and you can specify whether
to use the data produced by a scan optimization only when you
issue an incremental backup command. The following list describes
this behavior in more detail:
o During an offline full backup operation, you can enable or
disable the scan optimization setting.
Specify the Scan_Optimization qualifier to enable recording
of the identities of areas that change after this backup
operation completes.
Specify the Noscan_Optimization qualifier to disable recording
of the identities of areas that change after this backup
operation completes.
By default, the recording state remains unchanged (from the
state it was in prior to execution of the Backup command)
during a full backup operation.
Note that specifying the Scan_Optimization or Noscan_
Optimization qualifier with an offline full backup operation
has no effect on the backup operation itself, it merely allows
you to change the recording state for scan optimization.
o During an online full backup operation, the qualifier is
ignored.
The recording state for scan optimization remains unchanged
(from the state it was in prior to execution of the Backup
command). If you execute an online full backup operation
and specify the Scan_Optimization or Noscan_Optimization
qualifier, RMU Backup returns an informational message to
indicate that the qualifier is being ignored.
o During an incremental backup operation, the qualifier directs
whether the scan optimization data (if recorded previously)
will be used during the operation.
If you specify the Scan_Optimization qualifier, RMU Backup
uses the optimization if Oracle Rdb has been recording the
regions updated since the last full backup operation.
If you specify the Noscan_Optimization qualifier, RMU Backup
does not use the optimization, regardless of whether Oracle
Rdb has been recording the identity of the regions updated
since the last full backup operation.
You cannot enable or disable the setting for scan
optimizations during an incremental backup operation.
By default, the Scan_Optimization qualifier is used during
incremental backup operations.
4.43 – Tape Expiration
Tape_Expiration=date-time
Specifies the expiration date of the backup (.rbf) file. Note
that when RMU Backup reads a tape, it looks at the expiration
date in the file header of the first file on the tape and assumes
the date it finds in that file header is the expiration date for
the entire tape. Therefore, if you are backing up an .rbf file to
tape, specifying the Tape_Expiration qualifier only has meaning
if the .rbf is the first file on the tape. You can guarantee that
the .rbf file will be the first file on the tape by specifying
the Rewind qualifier and overwriting any existing files on the
tape.
When the first file on the tape contains an expiration date
in the file header, you cannot overwrite the tape before the
expiration date unless you have the OpenVMS SYSPRV or BYPASS
privilege.
Similarly, when you attempt to restore a .rbf file from tape,
you cannot perform the restore operation after the expiration
date recorded in the first file on the tape unless you have the
OpenVMS SYSPRV or BYPASS privilege
By default, no expiration date is written to the .rbf file
header. In this case, if the .rbf file is the first file on the
tape, the tape can be overwritten immediately. If the .rbf file
is not the first file on the tape, the ability to overwrite the
tape is determined by the expiration date in the file header of
the first file on the tape.
You cannot explicitly set a tape expiration date for an entire
volume. The volume expiration date is always determined by the
expiration date of the first file on the tape.
The Tape_Expiration qualifier cannot be used with a backup file
written to disk.
See the Oracle Rdb Guide to Database Maintenance for information
on tape label processing.
4.44 – Threads=number
Threads=number
Specifies the number of reader threads to be used by the backup
process.
RMU creates so called internal 'threads' of execution to read
data from one specific storage area. Threads run quasi-parallel
within the process executing the RMU image. Each thread generates
its own I/O load and consumes resources like virtual address
space and process quotas (e.g. FILLM, BYTLM). The more threads,
the more I/Os can be generated at one point in time and the more
resources are needed to accomplish the same task.
Performance increases with more threads due to parallel
activities which keeps disk drives busier. However, at a certain
number of threads, performance suffers because the disk I/O
subsystem is saturated and I/O queues build up for the disk
drives. Also the extra CPU time for additional thread scheduling
overhead reduces the overall performance. Typically 2-5 threads
per input disk drive are sufficient to drive the disk I/O
susbsystem at its optimum. However, some controllers may be
able to handle the I/O load of more threads, for example disk
controllers with RAID sets and extra cache memory.
In a backup operation, one writer thread is created per output
stream. An output stream can be either a tape drive, a disk file
or, a media library manager stream. In addition, RMU creates
a number of reader threads and their number can be specified.
RMU assigns a subset of reader threads to writer threads. RMU
calculates the assignment so that roughly the same amount of
data is assigned to each output stream. By default, five reader
threads are created for each writer thread. If the user has
specified the number of threads, then this number is used to
create the reader thread pool. RMU always limits the number of
reader threads to the number of storage areas. A threads number
of 0 causes RMU to create one thread per storage area which start
to run all in parallel immediately. Even though this may sound
like a good idea to improve performance, this approach suffers
performance for databases with a larger number (>10) of storage
areas. For a very large number of storage areas (>800), this
fails due to hard limitations in system resources like virtual
address space.
For a backup operation, the smallest threads number you can
specify is the number of output streams. This guarantees that
each writer thread has at least one reader thread assigned to it
and does not produce an empty save set. Using a threads number
equal to the number of output streams generates the smallest
system load in terms of working set usage and disk I/O load.
Disk I/O subsystems most likely can handle higher I/O loads.
Using a slightly larger value than the number of output streams
(for example, assigning more reader threads to a writer thread)
typically results in faster execution time.
5 – Usage Notes
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.
6 – Examples
Example 1
The following command performs a full backup operation on the mf_
personnel database and displays a log of the session:
$ RMU/BACKUP MF_PERSONNEL -
_$ DISK2[USER1]MF_PERS_FULL_BU.RBF /LOG
Example 2
To perform an incremental backup operation, include the
Incremental qualifier. Assume a full backup operation was done
late Monday night. The following command performs an incremental
backup operation on the database updates only for the following
day:
$ RMU/BACKUP/INCREMENTAL MF_PERSONNEL.RDB -
_$ $222$DUA20:[BCK]TUESDAY_PERS_BKUP/LOG
Example 3
To back up the database while there are active users, specify the
Online qualifier:
$ RMU/BACKUP/ONLINE MF_PERSONNEL.RDB -
_$ $222$DUA20:[BACKUPS]PERS_BU.RBF /LOG
Example 4
The following RMU Backup command includes only the EMPIDS_
LOW and EMPIDS_MID storage areas in the backup file of the
mf_personnel database. All the other storage areas in the mf_
personnel database are excluded from the backup file:
$ RMU/BACKUP/INCLUDE=(EMPIDS_LOW,EMPIDS_MID) -
_$ MF_PERSONNEL.RDB $222$DUA20:[BACKUPS]MF_PERS_BU.RBF
Example 5
The following command backs up the mf_personnel database but not
the root file ACL for the database:
$ RMU/BACKUP/NOACL MF_PERSONNEL MF_PERS_NOACL
Example 6
The following command backs up the mf_personnel database without
waiting for a quiet point in the database:
$ RMU/BACKUP/NOQUIET_POINT MF_PERSONNEL MF_PERS_NQP
Example 7
The following command creates a journal file, pers_journal.jnl,
and a backup file, pers_backup.rbf.
$ RMU/BACKUP/JOURNAL=PERS_JOURNAL MF_PERSONNEL PERS_BACKUP
Example 8
The following example backs up all the storage areas in the mf_
personnel database except for the read-only storage areas.
$ RMU/BACKUP/NO_READ_ONLY MF_PERSONNEL MF_PERSONNEL_BU
Example 9
The following example assumes that you are using multiple tape
drives to do a large backup operation. By specifying the Loader_
Synchronization qualifier, this command does not require you to
load tapes as each becomes full. Instead, you can load tapes on a
loader or stacker and RMU Backup will wait until all concurrent
tape operations have concluded for one set of tape volumes before
assigning the next set of tape volumes.
Using this example, you:
1. Verify the database.
2. Allocate each tape drive.
3. Manually place tapes BACK01 and BACK05 on the $111$MUA0:
drive.
4. Manually place tapes BACK02 and BACK06 on the $222$MUA1:
drive.
5. Manually place tapes BACK03 and BACK07 on the $333$MUA2:
drive.
6. Manually place tapes BACK04 and BACK08 on the $444$MUA3:
drive.
7. Mount the first volume.
8. Perform the backup operation.
9. Dismount the last tape mounted. (This example assumes it is on
the $444$MUA3: drive.)
10. Deallocate each tape drive.
$ RMU/VERIFY DB_DISK:[DATABASE]MF_PERSONNEL.RDB
$
$ ALLOCATE $111$MUA0:
$ ALLOCATE $222$MUA1:
$ ALLOCATE $333$MUA2:
$ ALLOCATE $444$MUA3:
$
$ MOUNT/FOREIGN $111$MUA0:
$
$ RMU/BACKUP /LOG/REWIND/LOADER_SYNCHRONIZATION -
_$ /LABEL=(BACK01, BACK02, BACK03, BACK04, BACK05, -
_$ BACK06, BACK07, BACK08) -
_$ DB_DISK:[MFPERS]MF_PERSONNEL.RDB -
_$ $111$MUA0:PERS_FULL_MAR30.RBF/Master, $222$MUA1: -
_$ $333$MUA1:/MASTER, $444$MUA3
$
$ DISMOUNT $444$MUA3:
$
$ DEALLOCATE $111$MUA0:
$ DEALLOCATE $222$MUA1:
$ DEALLOCATE $333$MUA2:
$ DEALLOCATE $444$MUA4:
Example 10
The following example generates a parallel backup plan file, but
does not execute it. The result is a backup plan file. See the
next example for a description of the plan file.
$ RMU/BACKUP/PARALLEL=(EXEC=4, NODE=(NODE1, NODE2)) -
_$ /LIST_PLAN=(PARTIAL.PLAN)/NOEXECUTE/INCLUDE=(RDB$SYSTEM, EMPIDS_LOW, -
_$ EMPIDS_MID, EMPIDS_OVER, SALARY_HISTORY, EMP_INFO) -
_$ /LABEL=(001, 002, 003, 004, 005, 006, 007, 008, 009) -
_$ /CHECKSUM_VERIFICATION -
_$ MF_PERSONNEL TAPE1:MF_PARTIAL.RBF, TAPE2:, TAPE3:, TAPE4:
Example 11
The following display shows the contents of the plan file,
PARTIAL.PLAN created in the preceding example. The following
callouts are keyed to this display:
1 The Plan Parameters include all the parameters specified
on the RMU BACKUP command line and all possible command
qualifiers.
2 Command qualifiers that are not specified on the command line
are represented as comments in the plan file. This allows you
to edit and adjust the plan file for future use.
3 Command qualifiers that are explicitly specified on the
command line are represented in the plan file as specified.
4 Executor parameters are listed for each executor involved in
the backup operation.
! Plan created on 28-JUN-1996 by RMU/BACKUP.
Plan Name = PARTIAL
Plan Type = BACKUP
Plan Parameters: 1
Database Root File = DISK1:[DB]MF_PERSONNEL;1
Backup File = PARTIAL.RBF
! Journal = specification for journal file 2
! Tape_Expiration = dd-mmm-yyyy
! Active_IO = number of buffers for each tape
! Protection = file system protection for backup file
! Block_Size = bytes per tape block
! Density = tape density
![No]Group_Size = number of blocks between XOR blocks
! Lock_Timeout = number of second to wait for locks
! Owner = identifier of owner of the backup file
!Page_Buffers = number of buffers to use for each storage area
Checksum_Verification 3
CRC = AUTODIN_II
NoIncremental
! Accept_labels preserves all tape labels
Log
! Loader_synchronization labels tapes in order across drives
! Media_loader forces support of a tape media loader
NoOnline
Quiet_Point
NoRewind
Statistics
ACL
![No]Scan_Optimization
Labels = (-
001 -
002 -
003 -
004 -
005 -
006 -
007 -
008 -
009 )
End Plan Parameters
Executor Parameters :
Executor Name = COORDINATOR
Executor Type = Coordinator
End Executor Parameters
Executor Parameters : 4
Executor Name = WORKER_001
Executor Type = Worker
Executor Node = NODE1
Start Storage Area List
EMPIDS_LOW,
SALARY_HISTORY
End Storage Area List
Tape Drive List
Tape Drive = TAPE1:
MASTER
End Tape Drive List
End Executor Parameters
Executor Parameters :
Executor Name = WORKER_002
Executor Type = Worker
Executor Node = NODE2
Start Storage Area List
EMPIDS_MID,
RDB$SYSTEM
End Storage Area List
Tape Drive List
Tape Drive = TAPE2:
MASTER
End Tape Drive List
End Executor Parameters
Executor Parameters :
Executor Name = WORKER_003
Executor Type = Worker
Executor Node = NODE1
Start Storage Area List
EMPIDS_OVER
End Storage Area List
Tape Drive List
Tape Drive = TAPE3
MASTER
End Tape Drive List
End Executor Parameters
Executor Parameters :
Executor Name = WORKER_004
Executor Type = Worker
Executor Node = NODE2
Start Storage Area List
EMP_INFO
End Storage Area List
Tape Drive List
Tape Drive = TAPE4
MASTER
End Tape Drive List
End Executor Parameters
Example 12
The following example demonstrates the use of the Restore_Options
qualifier. The first command backs up selected areas of the
mf_personnel database and creates an options file. The second
command shows the contents of the options file. The last command
demonstrates the use of the options file with the RMU Restore
command.
$ RMU/BACKUP MF_PERSONNEL.RDB MF_EMPIDS.RBF/INCLUDE=(EMPIDS_LOW, -
_$ EMPIDS_MID, EMPIDS_OVER) /RESTORE_OPTIONS=MF_EMPIDS.OPT
%RMU-I-NOTALLARE, Not all areas will be included in this backup file
$ !
$ !
$ TYPE MF_EMPIDS.OPT
! Options file for database USER1:[MFDB]MF_PERSONNEL.RDB;1
! Created 18-JUL-1995 10:31:08.82
! Created by BACKUP command
EMPIDS_LOW -
/file=USER2:[STOA]EMPIDS_LOW.RDA;1 -
/blocks_per_page=2 -
/extension=ENABLED -
/read_write -
/spams -
/thresholds=(70,85,95) -
/snapshot=(allocation=100, -
file=USER2:[SNP]EMPIDS_LOW.SNP;1)
EMPIDS_MID -
/file=USER3:[STOA]EMPIDS_MID.RDA;1 -
/blocks_per_page=2 -
/extension=ENABLED -
/read_write -
/spams -
/thresholds=(70,85,95) -
/snapshot=(allocation=100, -
file=USER3:[SNP]EMPIDS_MID.SNP;1)
EMPIDS_OVER -
/file=USER4:[STOA]EMPIDS_OVER.RDA;1 -
/blocks_per_page=2 -
/extension=ENABLED -
/read_write -
/spams -
/thresholds=(70,85,95) -
/snapshot=(allocation=100, -
file=USER4:[SNP]EMPIDS_OVER.SNP;1)
$ !
$ !
$ !
$ RMU/RESTORE MF_EMPIDS.RBF /AREA/OPTIONS=MF_EMPIDS.OPT
Example 13
The following example uses a density value with compression:
$RMU/BACKUP/DENSITY=(TK89,COMPACTION)/REWIND/LABEL=(LABEL1,LABEL2) -
_$ MF_PERSONNEL TAPE1:MFP.BCK, TAPE2:
Example 14
The following example shows how to perform a multidisk backup
operation.
$ RMU/BACKUP/DISK MF_PERSONNEL DEVICE1:[DIRECTORY1]MFP.RBF, -
_$ DEVICE2:[DIRECTORY2]
.
.
.
%RMU-I-COMPLETED, BACKUP operation completed at 1-MAY-2001 17:40:53.81
Example 15
The following example shows the use of the Librarian qualifier
with a plan file.
$RMU/BACKUP/PARALLEL=EXECUTOR=3/LIBRARIAN=WRITER_THREADS=3 -
_$ /LIST_PLAN=FILENAME.PLAN/NOEXECUTE/LOG DATABASE FILENAM.RBF
$RMU/BACKUP/PLAN FILENAME.PLAN
$RMU/RESTORE/LIBRARIAN=(READER_THREADS=9)/LOG FILENAME.RBF
The first backup command creates the plan file for a parallel
backup, but does not execute it. The second backup command
executes the parallel backup using the plan file. Three worker
processes are used; each process uses the three writer threads
specified with the Librarian qualifier. Each writer thread in
each process writes one stream of backup data to the Librarian
utility; a total of nine streams is written.
Example 16
This example shows the use of the Compression qualifier ZLIB.
$ RMU /BACKUP /COMPRESS=ZLIB:9 /LOG=FULL FOO BCK
.
.
.
BACKUP summary statistics:
Data compressed by 53% (9791 KB in/4650 KB out)
Example 17
The following example shows the use of the Norecord qualifier.
This would be used to backup a Hot Standby database without
modifying the database files.
$ RMU /BACKUP /NORECORD FOO BCK