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.
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 – 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
3 – Parameters
3.1 – root-file-spec
The name of the database root file. The root file name is also
the name of the database. An error results if you specify a
database that does not have after-image journaling enabled. The
default file extension is .rdb.
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.
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.
4 – Command Qualifiers
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.)
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.
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.
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.
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).
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
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.
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.
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.
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.
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.
4.29 – Until
Until=time
Specifies the approximate future time and date to stop the
continuous backup process. There is no default.
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.
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.
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: