There are three RMU Backup commands, as follows:
o An RMU Backup command without the After_Journal qualifier
creates a database backup file.
o An RMU Backup command with the After_Journal qualifier creates
a backup of the after-image journal (.aij) file. The .aij
can reside on disk or on tape. The RMU Backup command with
the After_Journal qualifier supports a two-stage journaling
technique that saves disk space and creates a backup journal
on tape.
o An RMU Backup command with the Plan qualifier allows you to
execute a List_Plan previously created with a parallel backup
operation. This form of the Backup command does not accept a
database name as a parameter. Instead, it requires the name of
a list plan.
1 – Database
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.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.
1.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
1.3 – Parameters
1.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.
1.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
1.4 – Command Qualifiers
1.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.
1.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.
1.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.
1.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.
1.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.
1.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.
1.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.
1.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.
1.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.
1.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.
1.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.
1.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.
1.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.
1.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.
1.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.
1.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.
1.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.
1.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.
1.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.
1.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."
1.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.
1.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.
1.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.
1.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.
1.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.
1.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.
1.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.)
1.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.
1.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.
1.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.
1.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.
1.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.
1.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.
1.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.
1.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.
1.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.
1.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).
1.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.
1.4.39 – Reader Thread Ratio
Reader_Thread_Ratio=integer
This qualifier has been deprecated. Use the /Threads qualifier
instead.
1.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.
1.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.
1.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.
1.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.
1.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.
1.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.
1.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
2 – After Journal
Creates a backup file of the database after-image journal (.aij)
file or files.
Oracle Rdb supports two types of after-image journaling
mechanisms: one that employs a single, extensible .aij file and
another that employs multiple, fixed-size .aij files. The type of
journaling mechanism being used at the time the backup operation
starts can affect how you should specify the backup command.
Further information on how these two journaling mechanisms affect
the backup operation appears in the Description help entry under
this command.
The backup .aij file is an actual, usable .aij file that can
be applied to the appropriate Oracle Rdb database in a recovery
operation.
The RMU Backup After_Journal command can be used while users are
attached to the database.
2.1 – Description
The backup .aij file you create can be used with the RMU Recover
command to recover (roll forward) journaled transactions. In some
cases, you might have to issue additional Recover commands: one
for the backup .aij file and a second for the more recent .aij
files.
Oracle Rdb supports the following two types of .aij file
configurations:
o A configuration that uses a single, extensible .aij file
This is the method always used prior to Version 6.0 and is
also the default (for compatibility with versions of Oracle
Rdb prior to Version 6.0).
When an extensible .aij file is used, one .aij file is written
to and extended, as needed, by the number of blocks specified
when the .aij file was created. The .aij file continues to
be extended until it is backed up (or the device on which it
resides is full).
The RMU Backup After_Journal command copies transactions
recorded in the current .aij file (always on a disk device)
to the backup .aij file (which might be on a tape or disk
device). On completion, the current .aij file is truncated
and used again. During periods of high update activity, the
truncation of the active .aij file might not be performed
because of conflicting access to the .aij file by other users,
but the storage allocated to the active .aij file is still
used again when the backup operation completes.
o A configuration that uses two or more fixed-size .aij files
When fixed-size .aij files are used, the database maintains
multiple .aij files; however, only one .aij file is written to
at a time. This .aij file is considered the current journal.
When this .aij file is filled, a switchover occurs to allow
journaling to continue in another available .aij file.
The RMU Backup After_Journal command works as follows with
fixed-size .aij files:
- Backs up any full .aij files
The backup operation first backs up the .aij file with the
lowest AIJ sequence number (that needs backing up), the
operation continues to back up .aij files in ascending AIJ
sequence number. If a lot of .aij files need to be backed
up when the RMU Backup After_Journal command is issued,
one backup file might contain the contents of all the .aij
files being backed up.
- Backs up the current .aij file
Even if there are active transactions at the time of the
backup operation, the RMU Backup After_Journal command
will start to backup the current active .aij file. If
you have specified the Quiet_Point qualifier, the backup
operation stalls at some point waiting for all the current
transactions to complete.
- Switches to the next available .aij file
An available .aij file is one for which both of the
following are true:
* It is not currently being used to record transactions.
* It is not needed for a redo operation.
Such an .aij file might be one that has never been used, or
one that has already been backed up.
Once a specified .aij file has been completely backed up, it
is initialized and marked as available for reuse.
NOTE
The method employed, fixed-size .aij files or an extensible
.aij file, cannot be set explicitly by the user. Any event
that reduces the number of .aij files to one results in an
extensible .aij file being used. Any event that increases
the number .aij files to two or more results in fixed-size
.aij files being used. An inaccessible .aij file is counted
in these equations. Therefore, if you have one accessible
.aij file and one inaccessible .aij file (perhaps because
it has been suppressed), fixed-size .aij journaling is still
used.
Because some of the RMU Backup After_Journal qualifiers are
valid only when one or the other journaling mechanism is
employed, you might need to issue an RMU Dump command to
determine which journaling mechanism is currently being
employed before you issue an RMU Backup After_Journal
command.
Also note that once a backup operation begins, .aij file
modification is not allowed until the backup operation is
complete. However, if the type of journaling changes between
the time you issue an RMU Dump command and the time you
issue the RMU Backup After_Journal command, you receive an
error message if you have specified qualifiers that are only
valid with a particular type of journaling mechanism. (The
Threshold qualifier, for example, is valid only when the
extensible journaling mechanism is being used.)
If you back up the .aij file or files to tape, you must mount
the backup media by using the DCL MOUNT command before you issue
the RMU Backup After_Journal command. If you specify the default,
Format=Old_File, the RMU Backup After_Journal command uses RMS
to write to the tape and the tape must be mounted as an OpenVMS
volume. (That is, do not specify the FOREIGN qualifier with the
MOUNT command.) If you specify the Format=New_Tape qualifier,
the RMU Backup After_Journal command writes backup files in a
format similar to that used by the RMU Backup command, and you
must mount the tape as a FOREIGN volume.
If you back up an .aij file to disk, you can then use the OpenVMS
Backup utility (BACKUP) to archive the .aij backup file.
The RMU Backup After_Journal command can be used in a batch job
to avoid occupying an interactive terminal for long periods of
time. The Continuous, Interval, Threshold, and Until qualifiers
control the duration and frequency of the backup process. When
you use the Continuous qualifier, the command can occupy a
terminal indefinitely. Therefore, it is good practice to issue
the command through a batch process when executing a continuous
.aij file backup operation. However, remember that the portion of
the command procedure that follows the RMU Backup After_Journal
command is not executed until after the time specified by the
Until qualifier.
When the RMU Backup After_Journal command completes, it records
information about the state of the backup files in the global
process symbols presented in the following list. You can use
these symbols in DCL command procedures to help automate the
backup operation.
These symbols are not set, however, if you have issued a DCL SET
SYMBOL/SCOPE=(NOLOCAL, NOGLOBAL) command.
o RDM$AIJ_SEQNO
Contains the sequence number of the last .aij backup file
written to tape. This symbol has a value identical to RDM$AIJ_
BACKUP_SEQNO. RDM$AIJ_SEQNO was created prior to Oracle Rdb
Version 6.0 and is maintained for compatibility with earlier
versions of Oracle Rdb.
o RDM$AIJ_CURRENT_SEQNO
Contains the sequence number of the currently active .aij
file. A value of -1 indicates that after-image journaling is
disabled.
o RDM$AIJ_NEXT_SEQNO
Contains the sequence number of the next .aij file that
needs to be backed up. This symbol always contains a positive
integer value (which can be 0).
o RDM$AIJ_LAST_SEQNO
Contains the sequence number of the last .aij file ready for a
backup operation, which is different from the current sequence
number if fixed-size journaling is being used. A value of -1
indicates that no journal has ever been backed up.
If the value of the RDM$AIJ_NEXT_SEQNO symbol is greater than
the value of the RDM$AIJ_LAST_SEQNO symbol, no more .aij files
are currently available for the backup operation.
o RDM$AIJ_BACKUP_SEQNO
Contains the sequence number of the last .aij file backed up
by the backup operation. This symbol is set at the completion
of an .aij backup operation. A value of -1 indicates that this
process has not yet backed up an .aij file.
The RMU Backup After_Journal command provides an informational
message that describes the exact sequence number for each .aij
backup file operation.
o RDM$AIJ_COUNT
Contains the number of available .aij files.
o RDM$AIJ_ENDOFFILE
Contains the end of file block number for the current AIJ
journal.
o RDM$AIJ_FULLNESS
Contains the percent fullness of the current AIJ journal.
Note that these are string symbols, not integer symbols, even
though their equivalence values are numbers. Therefore performing
arithmetic operations with them produces unexpected results.
If you need to perform arithmetic operations with these symbols,
first convert the string symbol values to numeric symbol values
using the OpenVMS F$INTEGER lexical function. For example:
$ SEQNO_RANGE = F$INTEGER(RDB$AIJ_LAST_SEQNO)
- F$INTEGER(RDB$AIJ_NEXT_SEQNO)
2.2 – Format
(B)0[m RMU/Backup/After_Journal root-file-spec {backup-file-spec | ""}
[4mCommand[m [4mQualifiers[m x [4mDefaults[m
/[No]Accept_Label x /Accept_Label
/Active_IO=max-writes x /Active_IO=3
/Block_Size=integer x See description
/[No]Compression[=options] x /Nocompression
/[No]Continuous=(n) x /Nocontinuous
/[No]Crc x See description
/Crc[=Autodin_II] x See description
/Crc=Checksum x See description
/Density=(density-value, [No]Compaction) x See description
/[No]Edit_Filename=(options) x /Noedit_Filename
/Encrypt=({Value=|Name=}[,Algorithm=]) x See description
/Format={Old_File|New_Tape} x /Format=Old_File
/[No]Group_Size[=interval] x See description
/[No]Interval=number-seconds x /Nointerval
/Label=(label-name-list) x See description
/Librarian[=options] x None
/Lock_Timeout=seconds x See description
/[No]Log x Current DCL verify value
(B)0[m /[No]Media_Loader x See description
/Owner=user-id x See description
/Prompt={Automatic|Operator|Client} x See description
/Protection=openvms-file-protection x See description
/[No]Quiet_Point x /Quiet_Point
/[No]Rename x /Norename
/[No]Rewind x /Norewind
/[No]Sequence=(n,m) x /Nosequence
/Tape_Expiration=date-time x The current time
/[No]Threshold=disk-blocks x /Nothreshold
/Until=time x See description
/[No]Wait=n x See description
2.3 – Parameters
2.3.1 – root-file-spec
The name of the database root file. The root file name is also
the name of the database. An error results if you specify a
database that does not have after-image journaling enabled. The
default file extension is .rdb.
2.3.2 – backup-file-spec
A file specification for the .aij backup file. The default
file extension is .aij unless you specify the Format=New_Tape
qualifier. In this case, the default file extension is .aij_rbf.
2.3.3 – ""
Double quotes indicate to Oracle RMU that you want the default
.aij backup file specification to be used. The default .aij
backup file specification is defined with the SQL ALTER DATABASE
statement or the RMU Set After_Journal command.
2.4 – Command Qualifiers
2.4.1 – Accept Label
Accept_Label
Specifies that Oracle RMU 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.
If you do not specify this qualifier, the default behavior
of Oracle RMU 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
the Backup Database help entry for a summary of which labels are
applied under a variety of circumstances.
2.4.2 – Active IO
Active_IO=max-writes
Specifies the maximum number of write operations to a backup
device that the RMU Backup After_Journal command attempts
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.
2.4.3 – 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.
2.4.4 – Compression
Compression=LZSS
Compression=Huffman
Compression=ZLIB=level
Nocompression
Allows you to specify the compression method to use before
writing data to the AIJ backup file. This reduces performance,
but may be justified when the AIJ 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 an aIJ file to a tape drive that does its
own compression; in some cases doing so can actually result in a
larger file.
This feature only works for the new backup file format and you
have to specify /FORMAT=NEW_TAPE if you also use /COMPRESSION.
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.
2.4.5 – Continuous
Continuous=(n)
Nocontinuous
Specifies whether the .aij backup process operates continuously.
You specify termination conditions by specifying one or both of
the following:
o The Until qualifier
Specifies the time and date to stop the continuous backup
process.
o The value for n
Specifies the number of iterations Oracle RMU should make
through the set of active .aij files before terminating the
backup operation.
When you use the Continuous qualifier, you must use either the
Until or the Interval qualifier or provide a value for n (or
both) to specify when the backup process should stop. You can
also stop the backup process by using the DCL STOP command when
backing up to disk.
If you specify the Continuous qualifier, Oracle Rdb does not
terminate the backup process after truncating the current .aij
file (when an extensible journal is used) or after switching to
a new journal (when fixed-size journals are used). Instead, the
backup process waits for the period of time that you specify in
the argument to the Interval qualifier. After that time interval,
the backup process tests to determine if the threshold has been
reached (for an extensible journal) or if the journal is full
(for fixed-size journals). It then performs backup operations
as needed and then waits again until the next interval break,
unless the number of iterations or the condition specified with
the Until qualifier has been reached.
If you specify the Continuous qualifier, the backup process
occupies the terminal (that is, no system prompt occurs) until
the process terminates. Therefore, you should usually enter the
command through a batch process.
If you specify the default, the Nocontinuous qualifier, the
backup process stops as soon as it completely backs up the .aij
file or files. The default value for the number of iterations (n)
is 1.
If you specify both the Until qualifier and the Continuous=n
qualifier, the backup operation stops after whichever completes
first. If you specify the Until=12:00 qualifier and the
Continuous=5 qualifier, the backup operation terminates at 12:00
even if only four iterations have completed. Likewise, if five
iterations are completed prior to 12:00, the backup operation
terminates after the five iterations are completed.
The Continuous qualifier is not recommended when you are backing
up to tape, particularly when the Format=New_Tape qualifier is
used. If your tape operations complete successfully, you do not
want the backup operation to continue in an infinite loop.
Using the DCL STOP command to terminate a backup operation to
tape might result in an incomplete or corrupt backup file.
However, do not delete this backup file; it is extremely
important that you preserve all .aij backup files, even
those produced by failed or terminated backup processes. If
the resultant .aij backup file is discarded, the next .aij
backup file could contain a "gap" in transactions, so that no
transactions would ever be rolled forward from that point on.
2.4.6 – Crc[=Autodin II]
Crc[=Autodin_II]
Uses the AUTODIN-II polynomial for the 32-bit 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.
Typing Crc is sufficient to select the Crc=Autodin_II qualifier.
It is not necessary to type the entire qualifier.
2.4.7 – 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 errors.
2.4.8 – 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 improve tape reliability so
that it is 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.
2.4.9 – 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. Oracle
RMU returns an error message if this qualifier is used and the
target device is not a tape drive.
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 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.
2.4.10 – Edit Filename
Edit_Filename=(Options)
Noedit_Filename
When the Edit_Filename=(options) qualifier is used, the specified
backup file name is edited by appending any or all of the values
specified by the following options to the backup file name:
o Day_Of_Week
The current day of the week expressed as a 1-digit integer (1
to 7). Sunday is expressed as 1; Saturday is expressed as 7.
o Day_Of_Year
The current day of the year expressed as a 3-digit integer
(001 to 366).
o Hour
The current hour of the day expressed as a 2-digit integer (00
to 23).
o Julian_Date
The number of days passed since 17-Nov-1858.
o Minute
The current minute of the hour expressed as a 2-digit integer
(00 to 59).
o Month
The current month expressed as a 2-digit integer (01 to 12).
o Sequence
The journal sequence number of the first journal in the backup
operation.
o Vno
Synonymous with the Sequence option. See the description of
the Sequence option.
o Year
The current year (A.D.) expressed as a 4-digit integer.
If you specify more than one option, place a comma between each
option.
The edit is performed in the order specified. For example, the
file backup.aij and the qualifier /EDIT_FILENAME=(HOUR, MINUTE,
MONTH, DAY_OF_MONTH, SEQUENCE) creates a file with the name
backup_160504233.aij when journal 3 is backed up at 4:05 P.M.
on April 23rd.
You can make the name more readable by inserting quoted strings
between each Edit_Filename option. For example, the following
qualifier adds the string "$30_0155-2" to the .aij file name
if the day of the month is the 30th, the time is 1:55 and the
version number is 2:
/EDIT_FILENAME=("$",DAY_OF_MONTH,"_",HOUR,MINUTE,"-",SEQUENCE)
This qualifier is useful for creating meaningful file names for
your backup files and makes file management easier.
The default is the Noedit_Filename qualifier.
2.4.11 – Encrypt
Encrypt=({Value=|Name=}[,Algorithm=])
The Encrypt qualifier encrypts the backup file of the after image
journal.
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.
This feature only works for a newer format backup file which
has been created using /FORMAT=NEW_TAPE. Therefore you have
to specify /FORMAT=NEW_TAPE with this command if you also use
/ENCRYPT.
Synonymous with Format=Old_File and Format=New_Tape qualifiers.
See the description of those qualifiers.
2.4.12 – Format
Format=Old_File
Format=New_Tape
Specifies the format in which the backup file is to be written.
Oracle Corporation recommends that you specify the Format=Old_
File qualifier (or accept the default) when you back up your .aij
file to disk and that you specify the Format=New_Tape qualifier
when you back up your .aij file to tape.
If you specify the default, the Format=Old_File qualifier, the
RMU Backup command writes the file in a format that is optimized
for a file structured disk. If you specify the Format=New_Tape
qualifier, the Oracle RMU command writes the file in a format
that is optimized for tape storage, including ANSI/ISO labeling
and end-to-end error detection and correction. When you specify
the Format=New_Tape qualifier and back up the .aij file to tape,
you must mount the backup media by using the DCL MOUNT command
before you issue the RMU Backup After_Journal command. The tape
must be mounted as a FOREIGN volume. If you mount the tape as an
OpenVMS volume (that is, you do not mount it as a FOREIGN volume)
and you specify the Format=New_Tape qualifier, you receive an
RMU-F-MOUNTFOR error.
When you back up your .aij file to tape and specify the
Format=New_Tape qualifier you can create a backup copy of the
database (using the RMU Backup command) and a backup of the
.aij file (using the RMU Backup After_Journal command) without
dismounting your tape.
The following tape qualifiers have meaning only when used in
conjunction with the Format=New_Tape qualifier:
Active_IO
Block_Size
Crc
Density
Group_Size
Label
Owner
Protection
Rewind
Tape_Expiration
The Format=New_Tape and the Noquiet_Point qualifiers cannot be
used on the same Oracle RMU command line. See the Usage Notes
Help entry for an explanation.
The default file specification, when you specify the Format=New_
Tape qualifier is .aij_rbf. The default file specification, when
you specify the Format=Old_File qualifier is .aij.
Although Oracle Corporation recommends that you specify the
Format=New_Tape qualifier for .aij backup operations to tape
and the Format=Old_File qualifier for .aij backup operations to
disk, Oracle RMU does not enforce this recommendation. This is to
provide compatibility with prior versions of Oracle Rdb. See the
Usage Notes Help entry for issues and problems you can encounter
when you do not follow this recommendation.
2.4.13 – 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
device dependent. Oracle RMU returns an error message if this
qualifier is used and the target device is not a tape device.
2.4.14 – Interval=n
Interval=number-seconds
Nointerval
Specifies the number of seconds for which the backup process
waits. Use this qualifier in conjunction with the Continuous
qualifier and the extensible journaling method. The interval
determines how often to test the active .aij file to determine
if it contains more blocks than the value of the Threshold
qualifier.
If you specify the Interval qualifier without specifying the
number of seconds, or if you omit this qualifier, the default
number of seconds is 60.
Oracle Corporation recommends using the default (Interval=60)
initially because the interval that you choose can affect the
performance of the database. In general, you can arrive at a
good interval time on a given database only by judgment and
experimentation.
If you specify the Nointerval qualifier, the active .aij file is
tested repeatedly with no interval between finishing one cycle
and beginning the next.
You must specify the Continuous qualifier if you specify either
the Interval or Nointerval qualifier.
If you specify both the Interval and Nocontinuous qualifiers, the
Interval qualifier is ignored.
2.4.15 – 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.
You can specify a 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 do not specify the Label (or Accept_Label) qualifier,
Oracle RMU 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_b, my_b01,
my_b02, and so on.
When you reuse tapes, Oracle RMU 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, Oracle RMU 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 Oracle RMU expects and the
label on each tape will match, or be prepared for a high level of
operator intervention.
If you specify fewer labels than are needed, Oracle RMU generates
labels based on the format you have specified. For example, if
you specify Label=TAPE01, Oracle RMU 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 Oracle RMU 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 Oracle RMU 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 Corporation 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.
2.4.16 – 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.
The Librarian qualifier accepts the following options:
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.
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.
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.
2.4.17 – Lock Timeout
Lock_Timeout=seconds
Determines the maximum time the .aij file 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, or if
the value specified is 0, the .aij file backup operation waits
indefinitely for the quiet-point lock and any other locks needed
during an online operation.
The Lock_Timeout=seconds qualifier is ignored if the Noquiet_
Point qualifier is specified.
2.4.18 – Log
Log
Nolog
Specifies whether the processing of the command is reported to
SYS$OUTPUT. Specify the Log qualifier to request log output and
the Nolog qualifier to prevent it. If you specify neither, the
default is the current setting of the DCL verify switch. (The DCL
SET VERIFY command controls the DCL verify switch.)
2.4.19 – 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, Oracle
RMU should recognize this fact. However, occasionally Oracle RMU
does not recognize that a tape device has a loader or stacker.
Therefore, when the first backup tape fills, Oracle RMU issues a
request to the operator for the next tape, instead of requesting
the next tape from the loader or stacker. Similarly, sometimes
Oracle RMU behaves as though a tape device has a loader or
stacker when actually it does not.
If you find that Oracle RMU is not recognizing that your tape
device has a loader or stacker, specify the Media_Loader
qualifier. If you find that Oracle RMU expects a loader or
stacker when it should not, specify the Nomedia_Loader qualifier.
Synonymous with Owner qualifier. See the description of the Owner
qualifier.
2.4.20 – 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 OpenVMS
identifier:
o A user identification code (UIC) in [group-name,member-name]
alphanumeric format
o A 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. Unless the Rewind qualifier is also
specified, the Owner qualifier is not applied to the first
volume. 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.
2.4.21 – 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.
2.4.22 – Protection
Protection=file-protection
Specifies the system file protection for the backup file produced
by the RMU Backup After_Journal 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).
2.4.23 – Quiet Point
Quiet_Point
Noquiet_Point
Specifies whether the quiet-point lock will be acquired when an
.aij backup operation is performed. The default is the Quiet_
Point qualifier. Use of the Quiet_Point qualifier is meaningful
only for a full backup operation; that is, a backup operation
that makes a complete pass through all .aij files ready for
backup as opposed to one which is done by-sequence (specified
with the Sequence qualifier). A full .aij backup operation can
be performed regardless of whether an extensible or a fixed-size
.aij journaling mechanism is being employed.
Each .aij backup operation is assigned an .aij sequence number.
This labeling distinguishes each .aij backup file from previous
.aij backup files. During a recovery operation, it is important
to apply the .aij backup files in the proper sequence. The RMU
Recover command checks the database root file structure and
displays a message telling you the .aij sequence number with
which to begin the recovery operation.
The quiet point is a state where all write transactions
have either been committed or rolled back and no read/write
transactions are in progress. This ensures that the recording
of transactions do not extend into a subsequent .aij backup file.
This backup file can then be used to produce a recovered database
that is in the same state as when the quiet point was reached.
When fixed-size journaling is employed, the Quiet_Point qualifier
is only relevant when the active .aij file is being backed up. In
this case, a quiet point is acquired only once, regardless of the
number of .aij files being backed up.
There is no natural quiet point if someone is writing or waiting
to write to the database at any given time. (A natural quiet
point is one that is not instigated by the use of the QP (quiet
point) Lock.) The .aij backup operation may never be able to
capture a state that does not have uncommitted data in the
database. As a result, the Noquiet_Point qualifier creates .aij
backup files that are not independent of one another. If you
apply one .aij backup file to the database without applying the
next .aij backup file in sequence, the recovery operation will
not be applied completely.
See the Usage_Notes help entry under this command for
recommendations on using the Quiet_Point and Noquiet_Point
qualifiers.
The following combination of qualifiers on the same command line
are invalid:
o Quiet_Point and Sequence
o Quiet_Point and Wait
o Noquiet_Point and Format=New
2.4.24 – Rename
Rename
Norename
The Rename qualifier creates and initializes a new .aij file and
creates the backup file by renaming the original .aij file. The
effect is that the original .aij file has a new name and the new
.aij file has the same name as the original .aij file.
The Rename qualifier sets the protection on the renamed backup
file so that you can work with it as you would any backup
file. You can specify the new name by using the Edit_Filename
qualifier.
When the Rename qualifier is used, the backup operation is faster
(than when Norename, the default, is specified) because the
duration of the backup operation is the total time required to
rename and initialize the .aij file; the data copy portion of
the backup (reading and writing) is eliminated. However, the disk
containing the .aij file must have sufficient space for both the
new and original .aij files. Note also that the .aij backup file
name must not include a device specification.
NOTE
If there is insufficient space for both the new and original
.aij files when the Rename qualifier is specified, after-
image journaling shutdown is invoked, resulting in a
complete database shutdown.
The Rename qualifier can be used with both fixed-size and
extensible journaling files.
The Norename qualifier copies the contents of the .aij file on
tape or disk and initializes the original .aij file for reuse.
The Norename qualifier results in a slower backup operation (than
when Rename is specified), but it does not require space on the
journal disk for both new and original .aij files.
The default is Norename.
2.4.25 – Rewind
Rewind
Norewind
Specifies that the magnetic tape that contains the backup file
will be rewound before processing begins. The tape is 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).
These qualifiers are applicable only to tape devices.
2.4.26 – Sequence
Sequence=(n,m)
Nosequence
Specifies that the journals with sequence numbers from n to m
inclusive are to be backed up. The values n and m are interpreted
or interpolated as follows:
o If Sequence = (33, 35) is specified, then the .aij files with
sequence numbers 33, 34, and 35 are backed up.
o If Sequence = (53, 53) is specified, then the .aij file with
sequence number 53 is backed up.
o If Sequence = (53) is specified, then the .aij files with
sequence numbers 53 and lower are backed up, if they have
not been backed up already. For example, if .aij files with
sequence numbers 51, 52, and 53 have not been backed up, then
Sequence = (53) results in these three .aij files being backed
up.
o If Sequence = (55, 53) is specified, then .aij files with
sequence numbers 53, 54, and 55 are backed up.
o If the Sequence qualifier is specified without a value list,
both n and m are set to the sequence number of the next
journal that needs to be backed up.
The default is the Nosequence qualifier. When the default is
accepted, the backup operation starts with the next journal that
needs to be backed up and stops when the termination condition
you have specified is reached.
The following qualifiers cannot be used or have no effect when
used with the Sequence qualifier:
Continuous
Format=New_Tape
Interval
Quiet_Point
Threshold
Until
Furthermore, fixed-size after-image journals must be in use when
this qualifier is specified.
2.4.27 – Tape Expiration
Tape_Expiration=date-time
Specifies the expiration date of the .aij backup file. Note that
when Oracle RMU 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 .aij
file to tape, specifying the Tape_Expiration qualifier only has
meaning if the .aij file is the first file on the tape. You can
guarantee that the .aij 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 perform a recover operation with
an .aij file on tape, you cannot perform the recover 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 .aij file
header. In this case, if the .aij file is the first file on the
tape, the tape can be overwritten immediately. If the .aij 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 operation to
disk.
See the Oracle Rdb Guide to Database Maintenance for information
on tape label processing.
2.4.28 – Threshold
Threshold=disk-blocks
Nothreshold
This qualifier can be used only when extensible journaling is
enabled. It cannot be used with fixed-size journaling.
The Threshold qualifier sets an approximate limit on the size
of the active .aij file. When the size of the active .aij file
exceeds the threshold, you cannot initiate new transactions
until the backup process finishes backing up and truncating
(resetting) the active .aij file. During the backup operation,
existing transactions can continue to write to the .aij file.
Before new transactions can start, all activity issuing from
existing transactions (including activity occurring after the
threshold is exceeded) must be moved from the active .aij disk
file to the .aij backup file. At that time, the active .aij file
will be completely truncated.
If you use the default, the Nothreshold qualifier, each backup
cycle will completely back up the active .aij file. Oracle
Corporation recommends using the Nothreshold qualifier.
An appropriate value for the Threshold qualifier depends on the
activity of your database, how much disk space you want to use,
whether backup operations will be continuous, and how long you
are willing to wait for a backup operation to complete.
See the Oracle Rdb7 Guide to Database Performance and Tuning for
more information on setting SPAM thresholds.
2.4.29 – Until
Until=time
Specifies the approximate future time and date to stop the
continuous backup process. There is no default.
2.4.30 – Wait
Wait=n
Nowait
Specifies whether the backup operation should wait (the Wait
qualifier) or terminate (the Nowait qualifier) when it encounters
a journal that is not ready to be backed up. The value specified
for the Wait qualifier is the time interval in seconds between
attempts to back up the journal that was not ready.
The Wait or Nowait qualifier can only be specified if the
Sequence qualifier is also specified. When the Wait qualifier is
specified, the default value for the time interval is 60 seconds.
The default is the Nowait qualifier.
2.5 – Usage Notes
o To use the RMU Backup After_Journal 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 See the Oracle Rdb7 Guide to Database Performance and Tuning
for information on how to enhance the performance of the RMU
Backup After_Journal command.
NOTE
When fast commit is enabled and an extensible .aij file
configuration is used, the after-image journal backup
process compresses and retains some fraction of the
original .aij file (in a new version of the current .aij
file). This fraction can approach 100% of the original
size. Therefore, be sure to reserve enough space to
duplicate the maximum size .aij file before backing it
up.
Oracle Corporation recommends that you schedule .aij
backup operations with sufficient frequency and check the
free space and journal file size periodically; you need
to know when you are approaching a critical situation in
terms of free space. (This is good practice whether or
not you have fast commit enabled.)
However, if you issue the RMU Backup After_Journal
command with fast commit enabled and find that you
have insufficient space for the .aij file, you have the
following options:
o Delete unneeded files to create sufficient space on
the disk where the .aij file is located.
o Temporarily disable fast commit and back up the .aij
file.
o Close the database, disable after-image journaling,
enable a new after-image journal file, and perform a
backup operation. (The database can be opened either
before or after the backup operation.)
o Close the database. Create a bound volume set or
stripe set that is large enough for the .aij file
and copy the .aij file there. Use the RMU Set After_
Journal command to change the .aij file name (or
redefine the logical name if one was used to locate
the journal), and then open the database again.
o Note the following issues and problems you can encounter when
you specify the Format=Old_File qualifier for an .aij backup
operation to tape or the Format=New_Tape qualifier for an .aij
backup operation to disk:
- If you use the Format=Old_File qualifier for an .aij
backup operation to tape and the tape is mounted as a
FOREIGN volume, the result is an unlabeled tape that can
be difficult to use for recovery operations.
Therefore, if you use the Format=Old_File qualifier with
an .aij backup operation to tape, you must mount the tape
as an OpenVMS volume (that is, do not specify the /FOREIGN
qualifier with the DCL MOUNT command).
- You must remember (or record) the format you use when you
back up your .aij file and specify that same format when
you issue an RMU Dump After_Journal, RMU Optimize After_
Journal, or RMU Recover command for the .aij backup file.
If you always follow the guidelines of specifying
Format=New_Tape for tape backups and Format=Old_File for
disk backups, you do not need to track the format you
specified for the .aij backup operation for future use
with the other Oracle RMU .aij commands.
- If you specify Format=Old_File for a backup operation
to tape and the .aij spans tape volumes, you might have
problems recovering the .aij file.
o You can use the RMU Backup After_Journal command to save disk
space by spooling the .aij file to tape.
o When you use extensible .aij files, note that although a new
version of the .aij file might be created when the after-image
backup operation begins, the old .aij file continues to be
active and growing. Until the switch occurs (which could be
several hours after the creation of the new version of the
.aij file), the old .aij file is still being accessed. For
this and other reasons, you should never use the DCL DELETE or
DCL PURGE on .aij files (or any database files).
o The following list provides usage information for the Quiet_
Point and Noquiet_Point qualifiers:
- If the backup 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. However, 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 his or her 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" to
allow such a process to hold the quiet-point lock until
they detach from the database. Set the value of the logical
name to "0", to ensure that the process releases the quiet-
point lock prior to starting a read-only transaction.
- 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.
- You cannot specify the Noquiet_Point qualifier with the
Format=New_Tape qualifier because an .aij file created with
the Noquiet_Point qualifier does not end on a quiet point.
Some transactions can bridge several backup files. When
you recover from these backup files you frequently must
apply several backup files in the same RMU Recover command.
However, the RMU Recover command with the Format=New_Tape
qualifier can only process one backup file at a time, so it
cannot support backup files created with the Noquiet_Point
qualifier.
o Oracle RMU tape operations do not automatically allocate the
tape drives used. In an environment where many users compete
for a few tape drives, it is possible for another user to
seize a drive while Oracle RMU is waiting for you to load the
next tape volume.
To prevent this, issue a DCL ALLOCATE command for the drives
you will be using before you issue the Oracle RMU command,
and then issue a DCL DEALLOCATE command after you complete the
Oracle RMU command.
o The Label qualifier can be used with indirect file
reference. See the Indirect-Command-Files help entry for more
information.
o If an .aij backup process fails or is terminated prematurely,
the user might discard the resultant .aij backup file because
the backup operation was not completed. However, all .aij
backup files, including those produced by a failed backup
process, are necessary to recover a database. If an .aij
backup file of a failed backup process is discarded, the
database is not recoverable from that point forward. This
is especially important if you use magnetic tapes as the .aij
backup media; in this case, preserve this magnetic tape and do
not reuse it.
o When an .aij backup process, especially one running in
continuous (Continuous) mode, writes to the .aij backup file,
it is possible for the transferred data to be deleted from the
database .aij file. If the backup process subsequently fails
or is prematurely terminated (for example with Ctrl/Y or the
DCL STOP command), it might not be possible to retransfer the
data to the subsequent .aij backup file because the data was
deleted from the active database .aij file.
Therefore, it is extremely important that you preserve all
.aij backup files, even those produced by failed or terminated
backup processes. If the resultant .aij backup file is
discarded, the next .aij backup file could contain a "gap"
in transactions, so that no transactions would ever be rolled
forward from that point on.
This problem is more severe when backing up directly to tape.
Therefore, when backing up to tape, you should back up one
journal at a time, rather than using an open-ended or long-
duration backup operation.
NOTE
If this problem occurs, the database is not inconsistent
or corrupt. Rather, the database cannot be rolled forward
past the discarded .aij backup file.
The solution to this problem is to preserve all .aij backup
files to ensure that a database can be completely recovered.
If you have discarded an .aij backup file, perform a full and
complete database backup operation immediately to ensure that
the database can be restored up to the current transaction.
o When an AIJ backup operation completes, the after-image
journal files are initialized with a pattern of -1 (hex
FF) bytes. This initialization is designed to be as fast as
possible. It fully utilizes the I/O subsystem by performing
many large asynchronous I/O operations at once. However, this
speed can come at the cost of a high load on I/O components
during the initialization. This load could slow down other I/O
operations on the system.
You can use two logical names to control the relative I/O load
that the AIJ initialization operation places on the system.
If you define these logical names in the system logical
name table, they are translated each time an AIJ file is
initialized.
The RDM$BIND_AIJ_INITIALIZE_IO_COUNT logical name specifies
the number of asynchronous I/O operations that are queued at
once to the AIJ file. If the logical name is not defined, the
default value is 15, the minimum value is 1, and the maximum
value is 32.
The RDM$BIND_AIJ_INITIALIZE_IO_SIZE logical name controls
the number of 512-byte disk blocks to be written per I/O
operation. If the logical name is not defined, the default
value is 127, the minimum value is 4, and the maximum value is
127.
Reducing the value of either logical will probably increase
the amount of time needed to initialize the AIJ file after a
backup. However, it may also reduce load on the I/O subsystem.
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:
%DBO-E-DENSITY, TAPE_DEVICE:[000000]DATABASE.BCK; does not support
specified density
%DBO-E-POSITERR, error positioning TAPE_DEVICE:
%DBO-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 When you use the RMU Backup After_Journal command with the
Log qualifier, the DCL global symbol RDM$AIJ_LAST_OUTPUT_FILE
is automatically created. The value of the symbol is the full
output backup AIJ file specification.
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 The system logical RDM$BIND_AIJBCK_CHECKPOINT_TIMEOUT can
be configured to control the checkpoint stall duration
independent of the AIJ shutdown parameter. This logical works
for both the AIJ backup and Automatic Backup Server (ABS)
utilities.
2.6 – Examples
Example 1
Assuming that you have enabled after-image journaling for the MF_
PERSONNEL database, the following command causes extensible .aij
entries to be backed up continuously until the time specified.
$ RMU/BACKUP/AFTER_JOURNAL/CONTINUOUS/THRESHOLD=500 -
_$ /INTERVAL=300/UNTIL="01-JUL-1996 16:15:00.00" -
_$ MF_PERSONNEL.RDB DISK12:[PERS_AIJ]BU_PERSONNEL.AIJ
Every 300 seconds, the backup process tests to determine if the
active .aij file on disk has reached the threshold size of 500
blocks. If not, transaction processing continues normally for one
or more 300-second intervals until the threshold test indicates
that the active .aij file has reached a size of at least 500
blocks. When the .aij file reaches that file size, Oracle RMU
allows existing transactions to continue to write to the active
.aij file but does not allow new transactions to start.
Assuming that the active .aij file contains 550 blocks, Oracle
Rdb moves those 550 blocks to the backup journal file and deletes
them from the active journal file. Then, the backup process
determines if the transactions already in progress have written
more journal records to the active journal file during the backup
operation. If so, Oracle RMU moves those journal records to the
backup file.
After Oracle Rdb completely moves the active journal file,
it truncates the journal file to 0 blocks. Oracle Rdb then
allows new transactions to start and the backup process resumes
threshold testing at 300-second intervals. The backup process
continues until the time and date specified by the Until
qualifier.
Example 2
The following examples show backing up .aij files in sequence.
Note that a number of transactions were committed to the database
between backup operations.
$ RMU/BACKUP/AFTER_JOURNAL/LOG MF_PERSONNEL MFPERS_BKUP_AIJ1.AIJ
%RMU-I-AIJBCKBEG, beginning after-image journal backup operation
%RMU-I-OPERNOTIFY, system operator notification:
Oracle Rdb V7.2 Database DISK1:[DB]MF_PERSONNEL.RDB;1
Event Notification AIJ backup operation started
%RMU-I-AIJBCKSEQ, backing up after-image journal
sequence number 0
%RMU-I-LOGBCKAIJ, backing up after-image journal
AIJ1 at 16:35:53.41
%RMU-I-LOGCREBCK, created backup file
DISK1:[DB]MFPERS_BKUP_AIJ1.AIJ;1
%RMU-I-AIJBCKSEQ, backing up after-image journal
sequence number 1
%RMU-I-LOGBCKAIJ, backing up after-image journal
AIJ2 at 16:35:54.58
%RMU-I-QUIETPT, waiting for database quiet point
%RMU-I-OPERNOTIFY, system operator notification:
Oracle Rdb V7.2 Database DISK1:[DB]MF_PERSONNEL.RDB;1
Event Notification AIJ backup operation completed
%RMU-I-AIJBCKEND, after-image journal backup operation
completed successfully
%RMU-I-LOGAIJJRN, backed up 2 after-image journals
at 16:35:56.40
%RMU-I-LOGAIJBLK, backed up 508 after-image journal blocks
at 16:35:56.41
.
.
.
$ More transactions committed to the database
.
.
.
$ RMU/BACKUP/AFTER_JOURNAL/LOG MF_PERSONNEL MFPERS_BKUP_AIJ2.AIJ
%RMU-I-AIJBCKBEG, beginning after-image journal backup operation
%RMU-I-OPERNOTIFY, system operator notification:
Oracle Rdb V7.2 Database
DISK1:[DB]MF_PERSONNEL.RDB;1 Event Notification
AIJ backup operation started
%RMU-I-AIJBCKSEQ, backing up after-image journal sequence number 2
%RMU-I-LOGBCKAIJ, backing up after-image journal AIJ1 at 16:47:44.66
%RMU-I-LOGCREBCK, created backup file
DISK2:[AIJ]MFPERS_BKUP_AIJ2.AIJ;1
%RMU-I-OPERNOTIFY, system operator notification:
Oracle Rdb V7.2 Database
DISK1:[DB]MF_PERSONNEL.RDB;1 Event Notification
AIJ backup operation completed
%RMU-I-AIJBCKEND, after-image journal backup operation completed
successfully
%RMU-I-LOGAIJJRN, backed up 1 after-image journal at 16:47:46.57
%RMU-I-LOGAIJBLK, backed up 254 after-image journal blocks at
16:47:46.57
Example 3
The following example uses the Edit_Filename qualifier to give
the .aij backup file a meaningful file name. The Rename qualifier
specifies that Oracle RMU should create the backup file by
renaming the current .aij file and by creating a new .aij file
with the same name as the original .aij file.
$ RMU/BACKUP/AFTER_JOURNAL MF_PERSONNEL -
_$ /EDIT_FILENAME=(SEQUENCE,"_",HOUR,"_",MINUTE,"_",MONTH,"_", -
_$ DAY_OF_MONTH) AIJ2/RENAME
$ DIR DISK1:[DB.AIJ2]*.AIJ
Directory DISK1:[DB.AIJ_TWO]
AIJ23_15_46_07_09.AIJ;1
Example 4
The following example shows the syntax to use when you want the
.aij backup file name to default to that previously specified
with the RMU Set After_Journal command. Note that the .aij backup
file name used is that which corresponds to the first .aij file
included in the backup operation.
$ RMU/SET AFTER_JOURNAL MF_PERSONNEL /ENABLE/RESERVE=5 -
_$ /ADD=(NAME=AIJ1, FILE=DISK1:[AIJ]AIJ_ONE, -
_$ BACKUP_FILE=DISK4:[AIJBCK]AIJ1BCK) -
_$ /ADD=(NAME=AIJ2, FILE=DISK2:[AIJ]AIJ_TWO, -
_$ BACKUP_FILE=DISK4:[AIJBCK]AIJ2BCK) -
_$ /ADD=(NAME=AIJ3, FILE=DISK3:[AIJ]AIJ_THREE, -
_$ BACKUP_FILE=DISK4:[AIJBCK]AIJ3BCK)
%RMU-W-DOFULLBCK, full database backup should be done to
ensure future recovery
$ !
$ !Assume backup operation was performed and other database
activity occurs.
$ !Then back up the .aij files:
$ !
$ RMU/BACKUP/AFTER_JOURNAL MF_PERSONNEL.RDB ""
$ !
$ DIR DISK4:[AIJBCK]
Directory DISK4:[AIJBCK]
AIJ1BCK.AIJ;1
Example 5
The following example uses a density value with compression:
RMU/BACKUP/AFTER_JOURNAL /DENSITY=(TK89,COMPACTION)/REWIND -
/LABEL=(LABEL1,LABEL2) MF_PERSONNEL TAPE1:MFP.AIJ, TAPE2:
3 – Plan
Executes a backup plan file previously created with the RMU
Backup command (or created manually by the user).
3.1 – Description
A backup plan file is created when you execute an RMU Backup
command with the Parallel and List_Plan qualifiers. See Backup
Database for details on creating a plan file and the format of a
plan file.
3.2 – Format
(B)0[mRMU/Backup/Plan plan-file
[4mCommand[m [4mQualifiers[m x [4mDefaults[m
x
/[No]Execute x Execute
/List_Plan=output-file x None
3.3 – Parameters
3.3.1 – plan-file-spec
The file specification for the backup plan file. The default file
extension is .plan.
3.4 – Command Qualifiers
3.4.1 – Execute
Execute
Noexecute
The Execute qualifier specifies that Oracle RMU is to execute
the plan file. The Noexecute qualifier specifies that Oracle RMU
should not execute the plan file, but instead perform a validity
check on the contents of the plan file.
The validity check determines such things as whether the storage
areas names assigned to each worker executor exist.
By default, Oracle RMU executes the backup plan file when the RMU
Backup Plan command is issued.
3.4.2 – List Plan
List_Plan=output-file
Specifies that Oracle RMU should generate a new plan file and
write it to the specified output file. This new plan file is
identical to the plan file you specified on the command line (the
"original" plan file) with the following exceptions:
o Any user-added comments in the original plan file do not
appear in the new plan file.
o The new plan file is formatted to match the standard format
for RMU Backup plan files.
3.5 – Usage Notes
o To use the RMU Backup Plan 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 To execute the RMU Backup Plan command, Oracle SQL/Services
must be installed on your system.
3.6 – Examples
Example 1
The following example first creates a plan file by issuing an
RMU Backup command with the Parallel and List_Plan qualifiers.
Oracle RMU does not execute the plan file because the Noexecute
qualifier is specified. The second command issues the RMU Backup
Plan command to execute the plan file created with the RMU Backup
command.
$ ! Create the Backup 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
$ !
$ ! Execute the plan file created with the previous command:
$ !
$ RMU/BACKUP/PLAN partial.plan