Completes a database reconstruction by processing past
transactions from the after-image journal (.aij) file or
optimized after-image journal (.oaij) file against a database
restored from a backup file.
1 – Description
You can use the RMU Recover command to apply the contents of an
.aij file to a restored copy of your database. Oracle RMU rolls
forward the transactions in the .aij file into the restored copy
of the database.
The RMU Recover command accepts a list of .aij or .oaij file
names. Unless you specify the Noautomatic qualifier, the RMU
Recover command attempts to automatically complete the recovery
operation by applying the journals currently associated with
the database in the current journal configuration if they are in
the recovery sequence. For example, if you specify the following
RMU Recover command, Oracle RMU not only recovers AIJ1, but also
AIJ2, AIJ3, and so on, for all journals in the recovery sequence:
$ RMU/RECOVER AIJ1
However, note that this automatic recovery feature means that
if you want to specify a termination condition, you must specify
the Until qualifier. Example 1 demonstrates how to specify a
termination condition with the Until qualifier.
If you are using extensible journals, you can also use the RMU
Backup After_Journal command to copy your database's .aij file to
tape, and truncate the original .aij file without shutting down
your database.
If you have backed up your .aij files (using the RMU Backup
After_Journal command), these .aij files are no longer part of
the current journal configuration and automatic recovery does
not take place because Oracle RMU does not know where to find
the .aij files. (There is one exception to this rule: if the only
.aij file that has been backed up is the first .aij file in the
recovery sequence, then automatic recovery occurs. You specify
the backed up .aij file on the Oracle RMU command line and Oracle
RMU can determine where the remaining on-disk .aij files reside.)
When automatic recover does not, or cannot occur, you must
specify the complete list of .aij files on the RMU Recover
command line to return your database to the desired state.
If your backup files were created using the Noquiet_Point
qualifier, you must provide the names of all the .aij files
in just one command. In addition, you must be careful to apply
these .aij files to the database in the order in which they
were created. Oracle RMU checks the validity of the journal
file entries against your database and applies only appropriate
transactions. If none of the transactions apply, you will receive
a warning message.
You can access your database for retrieval of data between
recovery steps, but you must not perform additional updates if
you want to perform more recovery steps.
If a system failure causes a recovery step to abort, you can
simply issue the RMU Recover command again. Oracle RMU scans
the .aij file until it finds the first transaction that has not
yet been applied to your restored database. Oracle RMU begins
recovery at that point.
2 – Format
(B)0[mRMU/Recover aij-file-name-list
[4mCommand[m [4mQualifiers[m x [4mDefaults[m
x
/Active_IO=max-reads x /Active_IO=3
/Aij_Buffers=integer x /Aij_Buffers=20
/Areas [= storage-area[,...] ] x All storage areas
/[No]Automatic x /Automatic
/[No]Confirm[=options] x See description
/Encrypt=({Value=|Name=}[,Algorithm=]) x See description
/Format={Old_File|New_Tape} x /Format=Old_File
/Just_Corrupt x See description
/Label=(label-name-list) x See description
/Librarian[=options] x None
/[No]Log x Current DCL verify value
/[No]Media_Loader x See description
/[No]Online x /Noonline
/Order_Aij_Files x See description
/Output=file-name x See description
/Prompt={Automatic|Operator|Client} x See description
(B)0[m/Resolve x See description
/[No]Rewind x /Norewind
/Root=root-file-name x See description
/[No]Trace x See Description
/Until=date-time x Current time
3 – Parameters
3.1 – aij-file-name-list
A list of after-image journal (.aij) files to be applied to the
database. You can supply this list using one of the following
methods:
o List the .aij files on the command line in the order in which
they were created. In other words, the oldest .aij file must
be the first in the list.
o Use an asterisk (*) or percent sign (%) to represent the .aij
files. The .aij files are processed in the order that they are
presented by OpenVMS.
o Append all your .aij files into one file and supply a single
.aij file name. You must be certain when you append the files
that you append them in the order in which they were created.
o Use an indirect command file. Include an .aij file name on
each line of the command file. If the number of .aij files
needed for recovery is large, listing each one on the command
line can exceed the maximum allowed command-line length. You
can avoid this problem by using an indirect command file. See
the Indirect-Command-Files help entry for more information on
indirect command files.
4 – Command Qualifiers
4.1 – Active IO
Active_IO=max-reads
Specifies the maximum number of read operations from a backup
device that the RMU Recover command attempts simultaneously. This
is not the maximum number of read operations in progress; that
value is a function of active system I/O operations.
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.2 – Aij Buffers
Aij_Buffers=integer
Specifies the
number of buffers to be used by the recovery process. The default
is 20 buffers. The valid range is 2 to 1,048,576 buffers. If the
database root file is available, you can use the RMU Dump After_
Journal command with the Option=Statistics qualifier to find a
recommended value for this qualifier. See Dump After_journal for
details.
4.3 – Areas
Areas[=storage-area[,...]]
Specifies the areas you want to recover. You can specify each
storage area by name or by the area's ID number.
You should use the Areas qualifier only if you have inconsistent
storage areas to recover. The default for the Areas qualifier
is all storage areas that must be recovered to make the database
consistent.
If the Areas qualifier is specified, a recovery operation by area
recovers until the storage areas being rolled forward are current
with the other storage areas, then recovery stops, regardless of
the time specified by the Until qualifier.
When the Areas qualifier is not specified or the Areas=*
qualifier is specified, Oracle RMU recovers all the storage areas
in the database to the time specified by the Until qualifier
or to the time of the last committed transaction in the .aij
file that can be applied. When the Areas qualifier is specified
without a value, Oracle RMU recovers to the earliest consistent
state only those storage areas that are not current with the
database root (.rdb) file of the database.
The Areas qualifier works in the following manner:
o If the Areas qualifier is specified without a value, Oracle
RMU automatically determines what areas are inconsistent
and recovers those areas. If an inconsistent area cannot
be recovered because it is at a higher transaction sequence
number (TSN) value than the database root file, the entire
database is recovered even if the Areas qualifier was
specified.
See the Oracle Rdb Guide to Database Maintenance for
information on TSNs.
o If the Areas qualifier is omitted or the Areas qualifier is
specified as Areas=*, the entire database (all storage areas)
is recovered.
o If the Areas qualifier is specified as Areas=(A1,A2,A3), only
areas A1, A2, and A3 are recovered until they are consistent.
If one of these areas is already consistent, or if an area is
at a higher TSN value than the database root file, the entire
database is recovered.
o If the Online qualifier is specified with the Areas qualifier
(as in the first three list items) and the end result is that
the entire database must be recovered, an error message is
generated because you can recover only individual areas by
using the Online qualifier, not the entire database.
You cannot use the Areas qualifier with the Just_Corrupt
qualifier because the Areas qualifier implies recovery for all
named areas and pages in those areas. (That is, use of the Just_
Corrupt qualifier with the Areas qualifier is redundant.)
The Areas qualifier can be used with indirect file references.
See the Indirect-Command-Files help entry for more information.
4.4 – Automatic
Automatic
Noautomatic
Specifies whether or not Oracle RMU should attempt automatic
recovery of .aij files. If you specify the Noautomatic qualifier,
only the .aij file or files you list on the Oracle RMU command
line are applied. If you specify the Automatic qualifier, Oracle
RMU attempts to recover all the .aij files currently associated
with the database.
The Automatic qualifier is the default; Oracle RMU attempts to
recover all the .aij files currently associated with the database
unless the .aij files have been backed up.
See the description section for more information on how automatic
recovery works.
4.5 – Confirm
Confirm[=options]
Noconfirm
Specifies whether or not the RMU /RECOVER command causes the
operator to be queried when an incorrect sequence of AIJ files is
detected.
The default for interactive recoveries is /CONFIRM, which
prompts the user to see if he wants to continue. The default
for RMU/RECOVER/NOCONFIRM and RMU/RECOVER executed in batch
jobs is to terminate the RMU/RECOVER at the point where
the out of sequence AIJ file is detected (equivalent to
RMU/RECOVER/CONFIRM=ABORT).
To override the default behavior, the user can continue to roll
forward and ignore the missing AIJ file either by specifying the
command syntax RMU/RECOVER/CONFIRM to get a prompt on whether to
continue rolling forward if there is an AIJ sequence gap, or by
specifying the syntax RMU/CONFIRM=CONTINUE if he does not want
the prompt or is executing the RMU/RECOVER in a batch job.
NOTE
Oracle recommends that, in general, an incorrect journal
sequence not be applied as a corrupt database may result.
The /Order_Aij_Files qualifier can be used to help ensure that
the specified journals are applied in the correct order.
The Confirm qualifier accepts the following options:
o CONFIRM=CONTINUE
Do not prompt the user if a sequence gap is detected on the
next AIJ file to be rolled forward but ignore the missing AIJ
file and continue rolling forward.
o CONFIRM=ABORT
Do not prompt the user if a sequence gap is detected on
the next AIJ roll forward but end the database recover at
this point. This is the same as the default behavior for
RMU/RECOVER/NOCONFIRM and RMU/RECOVER in batch.
4.6 – Encrypt
Encrypt=({Value=|Name=}[,Algorithm=])
The Encrypt qualifier is used to recover the database from an
encrypted after image journal backup file.
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 the Format=New_Tape qualifier. Therefore you
have to specify the Format=New_Tape qualifier with this command
if you also use the Encrypt qualifier.
Synonymous with the Format=Old_File and Format=New_Tape
qualifiers. See the description of those qualifiers.
4.7 – Format
Format=Old_File
Format=New_Tape
Specifies whether the backed up or optimized .aij file was
written in the old (disk-optimized) or the new (tape-optimized)
format. The Format=Old_File qualifier is the default. You must
specify the same Format qualifier that was used with the RMU
Backup After_Journal command or the RMU Optimize After_Journal
command. If your .aij file resides on disk, you should use the
Format=Old_File qualifier.
If you specified the Format=Old_File qualifier when you optimized
or backed up the .aij file to tape, you must mount the backup
media by using the DCL MOUNT command before you issue the RMU
Recover command. Because the RMU Recover command will use RMS
to read the tape, 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, you must mount the
backup media by using the DCL MOUNT /FOREIGN command before you
issue the RMU Recover command.
Similarly, if you specify OpenVMS access (you do not specify the
/FOREIGN qualifier on the DCL MOUNT command) although your .aij
backup was created using the Format=New_Tape qualifier, you will
receive an RMU-F-MOUNTFOR error.
The following tape qualifiers have meaning only when used in
conjunction with the Format=New_Tape qualifier:
Active_IO
Label
Rewind
4.8 – Just Corrupt
Just_Corrupt
Specifies that only inconsistent pages in the corrupt page table
(CPT) and areas marked as inconsistent should be recovered. You
can use this qualifier while users are attached to the database.
You can use the Just_Corrupt qualifier with the Until qualifier
to limit the recovery period to a particular point in time.
You cannot use the Areas qualifier with the Just_Corrupt
qualifier because the Areas qualifier implies recovery for all
named areas and pages in those areas. (That is, use of the Just_
Corrupt qualifier with the Areas qualifier is redundant.)
If you do not specify the Just_Corrupt qualifier, all pages are
recovered.
4.9 – Just Pages
Just_Pages
This qualifier is replaced with the Just_Corrupt qualifier
beginning in Oracle Rdb V7.0. See the description of the Just_
Corrupt qualifier.
Specifies the 1- to 6-character string with which the volumes of
the backup
4.10 – Label
Label=(label-name-list)
Specifies the 1- to 6-character string with which the volumes
of the backup file have been 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.
In a normal recovery operation, the Label qualifier you specify
with the RMU Recover command should be the same Label qualifier
you specified with the RMU Backup After_Journal command to back
up your .aij files.
The Label qualifier can be used with indirect file references.
See the Indirect-Command-Files help entry for more information.
4.11 – Librarian
Librarian=options
Use the Librarian qualifier to restore files from data archiving
software applications that support the Oracle Media Management
interface. The file name specified on the command line identifies
the stream of data to be retrieved from the Librarian utility. If
you supply a device specification or a version number it will be
ignored.
Oracle RMU supports retrieval using the Librarian qualifier only
for data that has been previously stored by Oracle RMU using the
Librarian qualifer.
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 application.
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.12 – Log
Log
Nolog
Specifies that the recovery activity be logged. The default is
the setting of the DCL VERIFY flag, which is controlled by the
DCL SET VERIFY command. When recovery activity is logged, the
output from the Log qualifier provides the number of transactions
committed, rolled back, and ignored during the recovery process.
You can specify the Trace qualifier with the Log qualifier.
4.13 – Media Loader
Media_Loader
Nomedia_Loader
Use the Media_Loader qualifier to specify that the tape device
from which the .aij file is being read 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 tape has been read, 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.
4.14 – Online
Online
Noonline
Specifies that the recover operation be performed while other
users are attached to the database. The Online qualifier can only
be used with the Area or Just_Corrupt qualifier. The areas or
pages to be recovered are locked for exclusive access, so the
operation is not compatible with other uses of the data in the
areas or on the pages specified.
The default is the Noonline qualifier.
4.15 – Order Aij Files
Specifies that the input after-image journal files are to
be processed in ascending order by sequence number. The .aij
files are each opened, the first block is read to determine the
sequence number, and the files are closed prior to the sequence
number sorting operation. The Order_Aij_Files can be especially
useful if you use wildcards to specify .aij files.
The Order_Aij_Files qualifier can also eliminate some .aij files
from processing if they are known to be prior to the database
recovery sequence starting point.
Note that due to the fact that the .aij backup files might have
more than one journal sequence in them, it is not always possible
for RMU to eliminate every journal file that might otherwise
appear to be unneeded. But for those journals where RMU is able
to know for certain that the journal will not be needed based
on the database recovery restart information, journals can be
avoided from having to be processed.
4.16 – Output
Output=file-name
Redirects the log and trace output (selected with the Log and
Trace qualifiers) to the named file. If this qualifier is not
specified, the output generated by the Log and Trace qualifiers,
which can be voluminous, is displayed on your terminal.
4.17 – 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.18 – Resolve
Resolve
Recovers a corrupted database and resolves an unresolved
transaction by completing the transaction.
See the help entry for the RMU Recover Resolve command for a
description of the options available with the Resolve qualifier.
4.19 – Rewind
Rewind
Norewind
Specifies that the tape that contains the backup file be rewound
before processing begins. The tape is searched for the backup
file starting at the beginning-of-tape (BOT). The Norewind
qualifier is the default and causes the backup file to be
searched starting at the current tape position.
The Rewind and Norewind qualifiers are applicable only to tape
devices. Oracle RMU returns an error message if these qualifiers
are used and the target device is not a tape device.
4.20 – Root
Root=root-file-name
Specifies the name of the database to which the journal should
be applied. The Root qualifier allows you to specify a copy of a
database instead of the original whose file specification is in
the .aij file. Use the Root qualifier to specify the new location
of your restored database root (.rdb) file.
Specifying this qualifier lets you roll forward a database copy
(possibly residing on a different disk) by following these steps:
1. Use the RMU Backup command to make a backup copy of the
database:
$ RMU/BACKUP MF_PERSONNEL.RDB MF_PERS_FULL_BU.RBF
This command writes a backup file of the database mf_personnel
to the file mf_pers_full_bu.rbf.
2. Use the RMU Restore command with the Root and Directory
qualifiers, stating the file specifications of the database
root and storage area files in the database copy.
$ RMU/RESTORE/ROOT=DB3:[USER]MF_PERSONNEL/DIRECTORY=DB3:[USER] -
_$ MF_PERS_FULL_BU
This command restores the database on disk DB3: in the
directory [USER]. Default file names and file extensions are
used.
3. If the database uses after-image journaling, you can use the
RMU Recover command to roll forward the copy.
$ RMU/RECOVER DBJNL.AIJ/ROOT=DB3:[USER]MF_PERSONNEL.RDB
Thus, transactions processed and journaled since the backup
operation are recovered on the copy on the DB3: disk.
Correct operation of this procedure requires that there are no
write transactions for the restored copy between the restore and
recover steps.
If you do not specify the Root qualifier, Oracle RMU examines
the .aij file to determine the exact name of the database root
(.rdb) file to which the journaled transactions will be applied.
This name, which was stored in the .aij file, is the full file
specification that your .rdb file had when after-image journaling
was enabled.
The journal file for a single-file database does not include the
file name for the database; to recover a single-file database,
you must specify the location of the database to be recovered by
using the Root qualifier.
4.21 – Trace
Trace
Notrace
Specifies that the recovery activity be logged. The default is
the setting of the DCL VERIFY flag, which is controlled by the
DCL SET VERIFY command. When recovery activity is logged, the
output from the Trace qualifier identifies transactions in the
.aij file by TSN and describes what Oracle RMU did with each
transaction during the recovery process. You can specify the Log
qualifier with the Trace qualifier.
4.22 – Until
Until=date-time
Use the Until qualifier to limit the recovery to those
transactions in the journal file bearing a starting timestamp no
later than the specified time. For example, suppose your database
fails today, but you have reason to believe that something
started to go wrong at noon yesterday. You might decide that you
only want to restore the database to the state it was in as of
noon yesterday. You could use the Until qualifier to specify that
you only want to recover those transactions that have a timestamp
of noon yesterday or earlier.
If you do not specify the Until qualifier, all committed
transactions in the .aij file will be applied to your database.
If you specify the Until qualifier, but do not specify a date-
time, the current time is the default.
If the Until qualifier is specified with a recover-by-area
operation, the operation terminates when either the specified
time is reached in the transaction sequence or the specified
storage areas become consistent with the other storage areas;
whichever condition occurs first.
5 – Usage Notes
o To use the RMU Recover command for a database, you must have
the RMU$RESTORE privilege in the root file access control
list (ACL) for the database or the OpenVMS SYSPRV or BYPASS
privilege.
o You can use the RMU Backup After_Journal command to copy an
extensible .aij file to tape and truncate the original .aij
file without shutting down your database.
o Transactions are applied to the restored copy of your database
in the order indicated by their commit sequence number and the
commit record in the .aij file; timestamps are not used for
this purpose. Therefore, you need not be concerned over time
changes made to the system (for example, resetting the time
for United States daylight saving time) or inconsistencies
in the system time on different nodes in a cluster. The only
occasion when timestamps are considered in the application of
.aij files is when you specify the Until qualifier. In this
case, the timestamp is used only as the point at which to stop
the recovery, not as a means to serialize the order in which
transactions are applied. See the description of the Until
qualifier for more information.
o You can redirect the AIJ rollforward temporary work files
and the database recovery (DBR) redo temporary work files
to a different disk and directory location than the default
(SYS$DISK) by assigning a different directory to the RDM$BIND_
AIJ_WORK_FILE logical in the LNM$FILE_DEV name table and a
different directory to the RDM$BIND_DBR_WORK_FILE logical in
the LNM$SYSTEM_TABLE, respectively.
This can be helpful in alleviating I/O bottlenecks that might
be occurring in the default location.
o In a normal recovery operation, the Format and Label
qualifiers you specify with the RMU Recover command should
be the same Format and Label qualifiers you specified with the
RMU Backup After_Journal command to back up your .aij files or
with the RMU Optimize After_Journal command to optimize your
.aij files.
For more information on the type of access to specify when
mounting tapes, see the description of the Format=Old_File and
Format=New_Tape qualifiers in the Format section.
o The following restrictions apply to using optimized .aij files
with recovery operations:
- Optimized .aij files cannot be used as part of by-area
recovery operations (recovery operations that use the RMU
Recover command with the Area qualifier).
- Optimized .aij files cannot be used as part of by-page
recovery operations (recovery operations that use the RMU
Recover command with the Just_Corrupt qualifier).
- Optimized .aij files cannot be specified for an RMU Recover
command that includes the Until qualifier. The optimized
.aij file does not retain enough of the information from
the original .aij file for such an operation.
- Optimized .aij files cannot be used with a recovery
operation if the database has been modified since the .aij
file was optimized.
The workaround for these restrictions against using optimized
.aij files in recovery operations is to use the original,
unoptimized .aij file in the recovery operation instead.
o You can read your database between recovery steps, but you
must not perform additional updates if you want to perform
more recovery steps.
o If a system failure causes a recovery step to abort, you can
simply issue the RMU Recover command again. Oracle RMU scans
the .aij file until it finds the first transaction that has
not yet been applied to your restored database. Oracle RMU
begins recovery at that point.
o You can use the RMU Recover command to apply the contents of
an .aij file to a restored copy of your database. Oracle RMU
will roll forward the transactions in the .aij file into the
restored copy of the database. You can use this feature to
maintain an up-to-date copy of your database for fast recovery
after a failure. To do this, use the RMU Recover command to
periodically apply your .aij files to a separate copy of the
database.
When you employ this procedure for fast recovery, you must
be absolutely certain that no one will execute an update
transaction on the database copy. Should someone execute an
update transaction, it might result in the inability to apply
the .aij files correctly.
o See the Oracle Rdb Guide to Database Maintenance for
information on the steps Oracle RMU follows in tape label
checking.
o When you use an optimized after-image journal for recovery,
the optimal number of buffers specified with the Aij_Buffers
qualifier depends on the number of active storage areas
being recovered. For those journals optimized with Recover_
Method=Sequential, a buffer count of 250 to 500 is usually
sufficient.
When you use journals optimized with Recover_Method=Scatter,
reasonable performance can usually be attained with a buffer
count of about five times the number of active storage areas
being recovered (with a minimum of about 250 to 500 buffers).
o The number of asynchronous prefetch (APF) buffers is also a
performance factor during recovery. For recovery operations
of optimized after-image journals, the RMU Recover command
sets the number of APF buffers (also known as the APF depth)
based on the values of the process quotas ASTLM, BYTLM, and
the specified AIJ_Buffers value. The APF depth is set to the
maximum of:
- 50% of the ASTLM process quota
- 50% of the DIOLM process quota
- 25% of the specified AIJ_Buffers value
The accounts and processes that perform RMU Recover operations
should be reviewed to ensure that various quotas are set to
ensure high levels of I/O performance. The following table
lists suggested quota values for recovery performance.
Quota Setting
DIOLM Equal to or greater than half of the count of
database buffers specified by the AIJ_Buffers
qualifier. Miminum of 250.
BIOLM Equal to or greater than the setting of DIOLM.
ASTLM Equal to or greater than 50 more than the setting of
DIOLM.
BYTLM Equal to or greater than 512 times the database
buffer size times one half the value of database
buffers specified by the AIJ_Buffers qualifier.
Based on a 12-block buffer size and the desire
to have 100 asynchronous I/O requests outstanding
(either reading or writing), the minimum suggested
value is 614,400 for a buffer count of 200.
WSQUOTA Large enough to avoid excessive page faulting.
WSEXTENT
FILLM 50 more than the count of database storage areas and
snapshot storage areas.
6 – Examples
Example 1
In the following example, the RMU Recover command requests
recovery from the .aij file personnel.aij located on PR$DISK in
the SMITH directory. It specifies that recovery should continue
until 1:30 P.M. on May 7, 1996. Because the Trace qualifier is
specified, the RMU Recover command displays detailed information
about the recovery operation to SYS$OUTPUT.
$ RMU/RECOVER/UNTIL="07-MAY-1996 13:30"/TRACE PR$DISK:[SMITH]PERSONNEL
%RMU-I-LOGRECDB, recovering database file DISK1:[DB.70]MF_PERSONNEL.RDB;1
%RMU-I-LOGRECSTAT, transaction with TSN 0:256 committed
%RMU-I-AIJONEDONE, AIJ file sequence 0 roll-forward operations completed
%RMU-I-AIJAUTOREC, starting automatic after-image journal recovery
%RMU-I-AIJONEDONE, AIJ file sequence 1 roll-forward operations completed
%RMU-W-NOTRANAPP, no transactions in this journal were applied
%RMU-I-AIJALLDONE, after-image journal roll-forward operations completed
%RMU-I-AIJSUCCES, database recovery completed successfully
%RMU-I-AIJFNLSEQ, to start another AIJ file recovery, the sequence number
needed will be 1
Example 2
The following example shows how to use .aij files to recover a
database:
SQL> CREATE DATABASE FILENAME DISK1:[SAMPLE]TEST_DB
cont> RESERVE 5 JOURNALS;
SQL> --
SQL> -- Use the DISCONNECT ALL statement to detach from the database,
SQL> -- then issue the ALTER DATABASE statement that automatically
SQL> -- invokes the specified database.
SQL> --
SQL> DISCONNECT ALL;
SQL> --
SQL> -- Create after-image journaling. The .aij files are given the
SQL> -- names aij_one.aij and aij_two.aij (and are placed on a disk
SQL> -- other than the disk holding the .rdb and .snp files):
SQL> --
SQL> ALTER DATABASE FILENAME DISK1:[SAMPLE]TEST_DB
cont> JOURNAL IS ENABLED
cont> ADD JOURNAL AIJ_ONE
cont> FILENAME 'USER$DISK:[CORP]AIJ_ONE'
cont> BACKUP FILENAME 'USER$DISK2:[CORP]AIJ_ONE'
cont> ADD JOURNAL AIJ_TWO
cont> FILENAME 'USER$DISK3:[CORP]AIJ_TWO'
cont> BACKUP FILENAME 'USER$DISK4:[CORP]AIJ_TWO';
SQL> EXIT
$ !
$ ! Using the RMU Backup command, make a backup copy of the database.
$ ! This command ensures that you have a copy of the
$ ! database at a known time, in a known state.
$ !
$ RMU/BACKUP DISK1:[SAMPLE]TEST_DB USER2:[BACKUPS]TEST_BACKUP.RBF
$ !
$ ! Now you can use SQL with after-image journaling enabled.
$ !
$ SQL
SQL> --
SQL> -- Attach to the database and perform some data definition
SQL> -- and storage.
SQL> --
SQL> ATTACH 'FILENAME DISK1:[SAMPLE]TEST_DB';
SQL> CREATE TABLE TABLE1 (NEW_COLUMN CHAR(10));
SQL> INSERT INTO TABLE1 (NEW_COLUMN) VALUES ('data');
SQL> COMMIT;
SQL> EXIT
$ !
$ ! Imagine that a disk failure occurred here. In such a situation,
$ ! the current database is inaccessible. You need a prior copy
$ ! of the database to roll forward all the transactions in the
$ ! .aij file.
$ !
$ !
$ ! You know that the backup file of the database is
$ ! uncorrupted. Use the RMU Restore command to restore and recover
$ ! the database. You do not have to issue the RMU Recover command
$ ! because the RMU Restore command will automatically recover the
$ ! database.
$ !
$ RMU/RESTORE/NOCDD_INTEGRATE/DIR=DDV21:[TEST] -
_$ USER2:[BACKUPS]TEST_BACKUP.RBF
%RMU-I-AIJRSTAVL, 2 after-image journals available for use
%RMU-I-AIJRSTMOD, 1 after-image journal marked as "modified"
%RMU-I-AIJISON, after-image journaling has been enabled
%RMU-W-DOFULLBCK, full database backup should be done to ensure
future recovery
%RMU-I-LOGRECDB, recovering database file DDV21:[TEST]TEST_DB.RDB;1
%RMU-I-AIJAUTOREC, starting automatic after-image journal recovery
%RMU-I-AIJONEDONE, AIJ file sequence 0 roll-forward operations completed
%RMU-I-AIJONEDONE, AIJ file sequence 1 roll-forward operations completed
%RMU-W-NOTRANAPP, no transactions in this journal were applied
%RMU-I-AIJALLDONE, after-image journal roll-forward operations completed
%RMU-I-AIJSUCCES, database recovery completed successfully
%RMU-I-AIJFNLSEQ, to start another AIJ file recovery, the sequence
number needed will be 1
Example 3
The following example demonstrates how the recovery operation
works when there are .aij backup files to be applied. First you
must restore the database by using the RMU Restore command with
the Norecovery qualifier, then apply the backed up .aij file
by using the RMU Recover command. Oracle RMU will complete the
recovery with the .aij files that were current when the restore
operation was invoked. This example assumes that three .aij files
have been added to the mf_personnel database prior to the first
shown backup operation and that journaling is enabled.
$ ! Create a backup file of the complete and full database.
$ !
$ RMU/BACKUP MF_PERSONNEL DISK1:[BACKUPS]MF_PERSONNEL_BCK.RBF
$ !
$ ! Updates are made to the SALARY_HISTORY and DEPARTMENTS tables.
$ !
$ SQL
SQL> ATTACH 'FILENAME MF_PERSONNEL';
SQL> UPDATE SALARY_HISTORY
cont> SET SALARY_END='20-JUL-1993 00:00:00.00'
cont> WHERE SALARY_START='14-JAN-1983 00:00:00'
cont> AND EMPLOYEE_ID='00164';
SQL> INSERT INTO DEPARTMENTS
cont> (DEPARTMENT_CODE, DEPARTMENT_NAME,
cont> MANAGER_ID,BUDGET_PROJECTED, BUDGET_ACTUAL)
cont> VALUES ('WLNS', 'WELLNESS CENTER', '00188',0,0);
SQL> COMMIT;
SQL> DISCONNECT DEFAULT;
SQL> EXIT
$ !
$ ! Create a backup file of the .aij files.
$ !
$ RMU/BACKUP/AFTER_JOURNAL MF_PERSONNEL DISK2:[BACKUP]MF_PERS_AIJBCK
$ !
$ ! An additional update is made to the DEPARTMENTS table.
$ !
$ SQL
SQL> ATTACH 'FILENAME MF_PERSONNEL';
SQL> INSERT INTO DEPARTMENTS
cont> (DEPARTMENT_CODE, DEPARTMENT_NAME, MANAGER_ID,BUDGET_PROJECTED,
cont> BUDGET_ACTUAL)
cont> VALUES ('facl', 'FACILITIES', '00190',0,0);
SQL> COMMIT;
SQL> DISCONNECT DEFAULT;
SQL> EXIT;
$
$ ! Assume the disk holding the SALARY_HISTORY and DEPARTMENTS
$ ! storage areas is lost. Restore only those areas. Specify
$ ! the Norecovery qualifier since you will need to apply the
$ ! .aij backup file.
$
$ RMU/RESTORE/AREA DISK1:[BACKUPS]MF_PERSONNEL_BCK.RBF -
_$ SALARY_HISTORY, DEPARTMENTS/NORECOVER
$ !
$ ! Now recover the database. Although you only specify the .aij
$ ! backup file, Oracle RMU will automatically continue the
$ ! recovery with the current journals in the recovery sequence after
$ ! the backed up .aij files have been applied.
$ !
$ RMU/RECOVER/LOG DISK2:[BACKUP]MF_PERS_AIJBCK
%RMU-I-AIJBADAREA, inconsistent storage area DISK3:[STO_AREA]
DEPARTMENTS.RDA;1 needs AIJ sequence number 0
%RMU-I-AIJBADAREA, inconsistent storage area
DISK3:[STO_AREA]SALARY_HISTORY.RDA;1 needs AIJ sequence number 0
%RMU-I-LOGRECDB, recovering database file
DISK3:[DATABASE]MF_PERSONNEL.RDB;1
%RMU-I-LOGOPNAIJ, opened journal file
DISK2:[BACKUP]MF_PERS_AIJBCK.AIJ;1
%RMU-I-AIJONEDONE, AIJ file sequence 0 roll-forward operations
completed
%RMU-I-LOGRECOVR, 3 transactions committed
%RMU-I-LOGRECOVR, 0 transactions rolled back
%RMU-I-LOGRECOVR, 0 transactions ignored
%RMU-I-AIJNOACTIVE, there are no active transactions
%RMU-I-AIJSUCCES, database recovery completed successfully
%RMU-I-AIJNXTSEQ, to continue this AIJ file recovery, the sequence
number needed will be 1
%RMU-I-AIJAUTOREC, starting automatic after-image journal recovery
%RMU-I-LOGOPNAIJ, opened journal file DISK4:[CORP]AIJ_TWO.AIJ;1
%RMU-I-AIJONEDONE, AIJ file sequence 1 roll-forward operations
completed
%RMU-I-LOGRECOVR, 2 transactions committed
%RMU-I-LOGRECOVR, 0 transactions rolled back
%RMU-I-LOGRECOVR, 0 transactions ignored
%RMU-I-AIJNOACTIVE, there are no active transactions
%RMU-I-AIJSUCCES, database recovery completed successfully
%RMU-I-AIJNXTSEQ, to continue this AIJ file recovery, the sequence
number needed will be 2
%RMU-I-AIJALLDONE, after-image journal roll-forward operations
completed
%RMU-I-LOGSUMMARY, total 5 transactions committed
%RMU-I-LOGSUMMARY, total 0 transactions rolled back
%RMU-I-LOGSUMMARY, total 0 transactions ignored
%RMU-I-AIJSUCCES, database recovery completed successfully
%RMU-I-AIJGOODAREA, storage area DISK3:[STO_AREA]DEPARTMENTS.RDA;1
is now consistent
%RMU-I-AIJGOODAREA, storage area DISK3:[STO_AREA]SALARY_HISTORY.RDA;1
is now consistent
%RMU-I-AIJFNLSEQ, to start another AIJ file recovery, the sequence
number needed will be 2
$ !
$ ! Database is restored and recovered and ready to use.
$ !
Example 4
The following example demonstrates how to recover all the known
inconsistent pages in a database. Assume the RMU Show Corrupt_
Pages command reveals that page 60 in the EMPIDS_LOW storage
area is inconsistent and pages 11 and 123 in the EMPIDS_MID
storage area is inconsistent. The RMU Recover command is issued
to recover on line all pages logged inconsistent in the corrupt
page table (CPT). After the recovery operation, the CPT will be
empty.
$ RMU/RECOVER/JUST_CORRUPT/ONLINE/LOG MF_PERSONNEL.AIJ
%RMU-I-AIJBADPAGE, inconsistent page 11 from storage area
DISK1:[TEST5]EMPIDS_OVER.RDA;1 needs AIJ sequence number 0
%RMU-I-AIJBADPAGE, inconsistent page 60 from storage area
DISK1:[TEST5]EMPIDS_LOW.RDA;1 needs AIJ sequence number 0
%RMU-I-AIJBADPAGE, inconsistent page 123 from storage area
DISK1:[TEST5]EMPIDS_OVER.RDA;1 needs AIJ sequence number 0
%RMU-I-LOGRECDB, recovering database file
DISK2:[TEST5]MF_PERSONNEL.RDB;1
%RMU-I-LOGOPNAIJ, opened journal file DISK3:[TEST5]MF_PERSONNEL.AIJ;1
%RMU-I-AIJONEDONE, AIJ file sequence 0 roll-forward operations
completed
%RMU-I-LOGRECOVR, 1 transaction committed
%RMU-I-LOGRECOVR, 0 transactions rolled back
%RMU-I-LOGRECOVR, 0 transactions ignored
%RMU-I-AIJNOACTIVE, there are no active transactions
%RMU-I-AIJSUCCES, database recovery completed successfully
%RMU-I-AIJALLDONE, after-image journal roll-forward operations
completed
%RMU-I-LOGSUMMARY, total 1 transaction committed
%RMU-I-LOGSUMMARY, total 0 transactions rolled back
%RMU-I-LOGSUMMARY, total 0 transactions ignored
%RMU-I-AIJSUCCES, database recovery completed successfully
%RMU-I-AIJGOODPAGE, page 11 from storage area
DISK1:[TEST5]EMPIDS_OVER.RDA;1 is now consistent
%RMU-I-AIJGOODPAGE, page 60 from storage area
DISK1:[TEST5]EMPIDS_LOW.RDA;1 is now consistent
%RMU-I-AIJGOODPAGE, page 123 from storage area
DISK1:[TEST5]EMPIDS_OVER.RDA;1 is now consistent
%RMU-I-AIJFNLSEQ, to start another AIJ file recovery, the sequence
number needed will be 0
Example 5
In the following example, note that the backed up AIJ files are
specified in the order B1, B3, B2, B4 representing sequence
numbers 1, 3, 2, 4. The /ORDER_AIJ_FILES sorts the journals to
be applied into ascending sequence order and then is able to
remove B1 from processing because the database recovery starts
with AIJ file sequence 2 as shown in the RMU/RESTORE output.
$ RMU/RESTORE/NEW/NOCDD/NOAFTER FOO
%RMU-I-RESTXT_00, Restored root file DUA0:[DB]FOO.RDB;16
.
.
.
%RMU-I-AIJRECFUL, Recovery of the entire database starts with
AIJ file sequence 2
%RMU-I-COMPLETED, RESTORE operation completed at 24-MAY-2007 12:23:32.99
$!
$ RMU/RECOVER/LOG/ORDER_AIJ_FILES B1,B3,B2,B4
.
.
.
%RMU-I-LOGOPNAIJ, opened journal file DUA0:[DB]B2.AIJ;24
%RMU-I-LOGRECSTAT, transaction with TSN 0:256 ignored
%RMU-I-LOGRECSTAT, transaction with TSN 0:257 ignored
%RMU-I-RESTART, restarted recovery after ignoring 2 committed transactions
%RMU-I-AIJONEDONE, AIJ file sequence 2 roll-forward operations completed
%RMU-I-LOGRECOVR, 0 transactions committed
%RMU-I-LOGRECOVR, 0 transactions rolled back
%RMU-I-LOGRECOVR, 2 transactions ignored
%RMU-I-AIJNOACTIVE, there are no active transactions
%RMU-I-AIJSUCCES, database recovery completed successfully
%RMU-I-AIJNXTSEQ, to continue this AIJ file recovery, the
sequence number needed will be 3
.
.
.
Example 6
The following example shows the "/CONFIRM=ABORT" syntax used so
that RMU/RECOVER will not continue rolling forward if a sequence
gap is detected. This is the default behavior if /NOCONFIRM is
specified or for batch jobs. Note that the exit status of RMU
will be "%RMU-E-AIJRECESQ" if the recovery is aborted due to a
sequence gap. It is always a good policy to check the exit status
of RMU, especially when executing RMU in batch jobs.
RMU/RECOVER/CONFIRM=ABORT/LOG/ROOT=user$test:foo faijbck1,faijbck2,faijbck4
%RMU-I-LOGRECDB, recovering database file DEVICE:[DIRECTORY]FOO.RDB;1
%RMU-I-LOGOPNAIJ, opened journal file DEVICE:[DIRECTORY]FAIJBCK4.AIJ;1
at 25-FEB-2009 17:27:42.29
%RMU-W-AIJSEQAFT, incorrect AIJ file sequence 8 when 7 was expected
%RMU-E-AIJRECESQ, AIJ roll-forward operations terminated due to sequence error
%RMU-I-AIJALLDONE, after-image journal roll-forward operations completed
%RMU-I-LOGSUMMARY, total 2 transactions committed
%RMU-I-LOGSUMMARY, total 0 transactions rolled back
%RMU-I-LOGSUMMARY, total 0 transactions ignored
%RMU-I-AIJFNLSEQ, to start another AIJ file recovery, the sequence number
needed will be 7
%RMU-I-AIJNOENABLED, after-image journaling has not yet been enabled
Example 7
The following example shows the "/CONFIRM=CONTINUE" syntax used
so that RMU/RECOVER will continue rolling forward if a sequence
gap is detected.
RMU/RECOVER/CONFIRM=CONTINUE/LOG/ROOT=user$test:foo faijbck1,faijbck2,faijbck4
%RMU-I-LOGRECDB, recovering database file DEVICE:[DIRECTORY]FOO.RDB;1
%RMU-I-LOGOPNAIJ, opened journal file DEVICE:[DIRECTORY]FAIJBCK4.AIJ;1
at 25-FEB-2009 17:26:04.00
%RMU-W-AIJSEQAFT, incorrect AIJ file sequence 8 when 7 was expected
%RMU-I-AIJONEDONE, AIJ file sequence 8 roll-forward operations completed
%RMU-I-LOGRECOVR, 1 transaction committed
%RMU-I-LOGRECOVR, 0 transactions rolled back
%RMU-I-LOGRECOVR, 0 transactions ignored
%RMU-I-AIJNOACTIVE, there are no active transactions
%RMU-I-AIJSUCCES, database recovery completed successfully
%RMU-I-AIJNXTSEQ, to continue this AIJ file recovery, the sequence number
needed will be 9
%RMU-I-AIJALLDONE, after-image journal roll-forward operations completed
%RMU-I-LOGSUMMARY, total 3 transactions committed
%RMU-I-LOGSUMMARY, total 0 transactions rolled back
%RMU-I-LOGSUMMARY, total 0 transactions ignored
%RMU-I-AIJSUCCES, database recovery completed successfully
%RMU-I-AIJFNLSEQ, to start another AIJ file recovery, the sequence number
needed will be 9
%RMU-I-AIJNOENABLED, after-image journaling has not yet been enabled
7 – Resolve
Recovers a corrupted database and resolves an unresolved
distributed transaction by completing the transaction.
See the Oracle Rdb7 Guide to Distributed Transactions for
complete information on unresolved transactions and for
information on the transactions managers (DECdtm and Encina)
supported by Oracle Rdb.
7.1 – Description
Use the RMU Recover Resolve command to commit or abort any
unresolved distributed transactions in the after-image journal
(.aij) file. You must complete the unresolved transactions to the
same state (COMMIT or ABORT) in every .aij file affected by the
unresolved transactions.
The RMU Recover Resolve command performs the following tasks:
o Displays identification information for an unresolved
transaction.
o Prompts you for the state to which you want the unresolved
transaction resolved (if you did not specify the State
qualifier on the command line). If you are using DECdtm to
manage the transaction, you can specify COMMIT, ABORT, or
IGNORE. If you are using an XA transaction, you can specify
COMMIT or ABORT.
o Prompts for confirmation of the state you specified
o Commits, aborts, or ignores the unresolved transaction
o Continues until it displays information for all unresolved
transactions
7.2 – Format
(B)0[mRMU/Recover/Resolve aij-file-name
[4mCommand[m [4mQualifiers[m x [4mDefaults[m
x
/Active_IO=max-reads x See the RMU/Recover command
/Aij_Buffers=integer x See the RMU/Recover command
/Areas[=storage-area[,...]] x See the RMU/Recover command
/[No]Confirm x See description
/Format={Old_File|New_Tape} x See the RMU/Recover command
/Label=(label-name-list) x See the RMU/Recover command
/[No]Log x See the RMU/Recover command
/[No]Media_Loader x See the RMU/Recover command
/[No]Online x See the RMU/Recover command
/[No]Rewind x See the RMU/Recover command
/Root=root-file-name x See the RMU/Recover command
/State=option x See description
/[No]Trace x See the RMU/Recover command
/Until=date-time x See the RMU/Recover command
7.3 – Parameters
7.3.1 – aij-file-name
The name of the file containing the after-image journal. This
cannot be an optimized after-image journal (.oaij) file. The
default file extension is .aij.
7.4 – Command Qualifiers
7.4.1 – Confirm
Confirm
Noconfirm
Prompts you for confirmation of each transaction state you alter.
The default for interactive processing is Confirm.
Specify the Noconfirm qualifier to suppress this prompt. The
default for batch processing is Noconfirm.
7.4.2 – State
State=option
Specifies the state to which all unresolved transactions will be
resolved.
If you are using DECdtm to manage your distributed transaction,
options for the State qualifier are:
o Commit-Commits all unresolved transactions.
o Abort- Aborts all unresolved transactions.
o Ignore-Does not resolve any transactions.
If you are using Encina to manage your distributed transaction,
options for the State qualifier are:
o Commit-Commits all unresolved transactions.
o Abort- Aborts all unresolved transactions.
If you do not specify the State qualifier, Oracle RMU prompts
you to enter an action, for each unresolved transaction in
that .aij file. If DECdtm is managing your transaction and you
enter Ignore, Oracle RMU-instead of resolving the transaction-
attempts to contact the coordinator to resolve the transaction.
The transaction remains unresolved until the coordinator becomes
available again and instructs the transaction to complete or
until you manually complete the transaction by using the RMU
Recover Resolve command again. For more information about the
activities of the coordinator, see the Oracle Rdb7 Guide to
Distributed Transactions.
Because a coordinator is not involved with transactions managed
by Encina, the Ignore option is not valid for XA transactions.
7.5 – Usage Notes
o To use the RMU Recover Resolve command for a database, you
must have the RMU$RESTORE privilege in the root file for the
database or the OpenVMS SYSPRV or BYPASS privilege.
o If you have restored the database by using the New qualifier
and have not deleted the corrupted database, use the Root
qualifier to override the original file specification for the
database root file.
o After it rolls forward from the .aij file specified on the
command line, Oracle RMU prompts you for the name of the next
.aij file. If there are more .aij files to roll forward, enter
the file name, including the version number for that .aij
file. If there are no other .aij files, press the Return key.
For more information about rolling forward and determining
transaction sequence numbers for .aij files, see the Oracle
Rdb Guide to Database Maintenance.
o Note the following points regarding using Oracle Rdb with the
Encina transaction manager:
- Only databases that were created under Oracle Rdb V7.0 or
higher, or converted to V70 or higher, can participate in
XA transactions.
- To start a distributed transaction, you must have the
DISTRIBTRAN database privilege for all databases involved
in the transaction.
- Oracle Rdb supports only explicit distributed transactions
with Encina. This means that your application must
explicitly call the Encina routines to start and end the
transactions.
7.6 – Examples
Example 1
The following command recovers the mf_personnel database and
rolls the database forward from the old .aij file to resolve the
unresolved distributed transactions. Because the State qualifier
is not specified, Oracle RMU will prompt the user for a state for
each unresolved transaction.
$ RMU RECOVER/RESOLVE MF_PERSONNEL.AIJ;1
Example 2
This example specifies that all unresolved transactions in the
mf_personnel.aij file be committed.
$ RMU/RECOVER/RESOLVE/STATE=COMMIT MF_PERSONNEL.AIJ
For more examples of the RMU Recover Resolve command, see the
Oracle Rdb7 Guide to Distributed Transactions.