Permits you to recover more quickly from the loss of a database
root (.rdb) file by restoring only the root file. This command is
not valid for single-file databases.
1 – Description
The RMU Restore Only_Root command rebuilds only the database root
(.rdb) file from a backup file, produced earlier by an RMU Backup
command, to the condition the .rdb file was in when the backup
operation was performed. Use the command qualifiers to update
the .rdb file. The area qualifiers alter only the .rdb file, not
the storage areas themselves. Use the area qualifiers to correct
the restored backup root file so that it contains storage area
information that was updated since the last backup operation was
performed on the database. This is useful when you need to match
the root from an older backup file of your database with the area
information in the more recent backup file of your database in
order to have a usable database.
When the .rdb file is restored by itself, be sure that you
correctly set the transaction state of the database with the
Initialize_Tsns qualifier or the Set_Tsn qualifier. If the
database transaction sequence number (TSN) and commit sequence
number (CSN) are not set to the same values as those that were
in the lost .rdb file, there will be an inconsistency in the
journaling if after-image journaling is enabled. Therefore, you
cannot recover the database by using journal files created before
you used either the Initialize_Tsns qualifier or the Set_Tsn
qualifier in a restore-only-root operation.
You should set the TSN to a value equal to or greater than the
value that was in the lost .rdb file. If the TSN is set to a
lower value than the value stored in the lost database root file,
the database is corrupted, and it might return incorrect data or
result in application failures. If the number you have selected
is less than the Next CSN and Next TSN values, you will receive a
fatal error message as follows:
%RMU-F-VALLSSMIN, value (0:40) is less than minimum allowed
value (0:74) for Set_Tsn=tsn
After the set TSN and reinitialize TSN operations
complete, and after you have verified the .rdb
file, enabled after-image journaling, and the
new .aij file is created, all .aij records are based on the new
starting TSN and CSN numbers in the .rdb file.
Although Oracle Corporation recommends that your backup strategy
ensures that you maintain a current full and complete database
backup file, it is possible to restore the database from
current full by-area backup files only. This is accomplished by
restoring the root and specifying the Noupdate_Files and Noset_
Tsn qualifiers. When you specify the Noset_Tsn qualifier, the
TSN and CSN values on the restored database will be the same as
those recorded in the backup file. When you specify the Noupdate_
Files qualifier, the database root is restored but RMU Restore
Only_Root will not link that restored root to any of the area
files, nor will it create or update the snapshot (.snp) files. By
specifying the Noupdate_Files and Noset_Tsn qualifiers with the
RMU Restore Only_Root command, you can use the following strategy
to restore your database:
1. Restore the root from the most recent full by-area backup
file.
2. Restore the storage areas by applying the by-area backup files
in reverse order to their creation date.
Apply the most recent by-area backup file first and the oldest
by-area backup file last. (Be sure you do not restore any area
more than once.)
3. Recover the database by applying the after-image journal
(.aij) files.
You can recover the .aij files manually by using the RMU
Recover command. Or, if the state of your .aij files permits
it, you can allow RMU Restore Only_Root to automatically
recover the .aij files by not specifying the Norecovery
qualifier with the last RMU Restore command you issue. For
details on the automatic recovery feature of the RMU Restore
command, see the help entry for the RMU Restore command.
(The automatic recovery feature is not available for the RMU
Restore Only_Root command.)
When you use this strategy, be sure that the first RMU Restore
command after the RMU Restore Only_Root command includes the
most recent RDB$SYSTEM storage area. The RDB$SYSTEM storage area
contains the structures needed to restore the other database
storage areas. For this reason, Oracle Corporation suggests that
you back up the RDB$SYSTEM storage area in every by-area backup
operation you perform.
See Example 6 in the Examples help entry under this command for a
demonstration of this method.
Note that the database backup file must be recent-differences
between the database and backup file must be known, and the
number of storage areas must be unchanged since the backup file
was created. If you have moved a storage area, use the File
qualifier to show its new location and the Snapshot qualifier
to indicate the current version of the area's .snp file.
NOTE
You must perform a full and complete backup operation
on your database when the RMU Restore Only_Root command
completes. Oracle Corporation recommends that you define a
new after-image journal configuration with the RMU Restore
Only_Root command by using either the After_Journal or the
Aij_Options qualifier. This action ensures that the new
.aij file can be rolled forward in the event that another
database restore operation becomes necessary.
2 – Format
(B)0[mRMU/Restore/Only_Root backup-file-spec [storage-area-list]
[4mCommand[m [4mQualifiers[m x [4mDefaults[m
x
/Active_IO=max-reads x /Active IO=3
/[No]After_Journal=file-spec x See description
/[No]Aij_Options=journal-opts x See description
/Directory=directory-spec x See description
/[No]Initialize_Tsns x /Noinitialize_Tsns
/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]New_Snapshots x /Nonew_Snapshots
/Nodes_Max=number-cluster-nodes x Existing value
/Options=file-spec x None
/[No]Rewind x /Norewind
/Root=root-file-spec x Existing value
/[No]Set_Tsn=Tsn=n,Csn=m) x See description
/Transaction_Mode=(modes-list) x /Transaction_Mode=Current
/[No]Update_Files x /Update_Files
/Users_Max=number-users x Existing value
(B)0[m
[4mFile[m [4mor[m [4mArea[m [4mQualifiers[m x [4mDefaults[m
x
/[No]Blocks_Per_Page=integer x /Noblocks_Per_Page
/File=file-spec x See description
/Read_Only x Current value
/Read_Write x Current value
/Snapshot=(Allocation=n,File=file-spec)x See description
/[No]Spams x Current value
/Thresholds=(val1[,val2[,val3]]) x Existing area file value
3 – Parameters
3.1 – backup-file-spec
A file specification for the backup file produced by a previous
RMU Backup command. The default file extension is .rbf.
Note that you cannot perform a remote restore operation on an
.rbf file that has been backed up to tape and then copied to
disk. When copying .rbf files to disk from tape, be sure to copy
them onto the system on which you will be restoring them.
Depending on whether you are performing a restore operation
from magnetic tape, disk, or multiple disks, the backup file
specification should be specified as follows:
o Restoring from magnetic tape
If you used multiple tape drives to create the backup file,
the backup-file-spec parameter must be provided with (and only
with) the first tape drive name. Additional tape drive names
must be separated from the first and subsequent tape drive
names with commas, as shown in the following example:
$ RMU/RESTORE /REWIND $111$MUA0:PERS_FULL_NOV30.RBF,$112$MUA1:
o Restoring from multiple or single disk files
If you used multiple disk files to create the backup file,
the backup-file-spec parameter must be provided with (and only
with) the first disk device name. Additional disk device names
must be separated from the first and subsequent disk device
names with commas. You must include the Disk_file qualifier.
For example:
RMU/RESTORE/ONLY_ROOT/DISK_FILE DISK1:[DIR1]MFP.RBF,DISK2:[DIR2],
DISK3:[DIR3]
As an alternative to listing the disk device names on the
command line (which can exceed the line-limit lenght for a
command line if you use several devices), you can specify an
options file in place of the backup-file-spec. For example:
$ RMU/RESTORE/ONLY-ROOT/DISK_FILE" @DEVICES.OPT"
The contents of devices.opt might appear as follows:
DISK1:[DIR1]MFP.RBF
DISK2:[DIR2]
DIS3:[DIR3]
The backup files referenced from sjuch an options file are:
DISK1:[DIR1]MFP.RBF
DISK2:[DIR2]MFP01.RBF
DISK3:[DIR3]MFP02.RBF
3.2 – storage-area-list
This option is a list of storage area names from the database.
Use it in the following situations:
o When you need to change the values for thresholds with the
Thresholds qualifier or blocks per page with the Blocks_Per_
Page qualifier
o When you need to change the names or version numbers specified
with the Snapshot or the File qualifier for the restored
database
To use the storage-area-list option, specify the storage area
name, not the system file name for the storage area. By restoring
the database root only, you save the additional time normally
needed to restore all the storage areas. Place commas between
each storage area name in the list.
If the storage area parameters have changed since the file was
last backed up, the storage-area-list option updates the .rdb
file parameters so they agree with the current storage area
parameters in terms of location and file version.
4 – Command Qualifiers
4.1 – Active IO
Active_IO=max-reads
Specifies the maximum number of read operations to the backup
file that the RMU Restore Only_Root command will attempt
simultaneously. The value of the Active_IO qualifier can range
from 1 to 5. The default value is 3.
4.2 – After Journal
After_Journal=file-spec
Noafter_Journal
NOTE
This qualifier is maintained for compatibility with versions
of Oracle Rdb prior to Version 6.0. You might find it more
useful to specify the Aij_Options qualifier, unless you are
only interested in creating extensible .aij files.
Specifies how RMU Restore Only_Root is to handle after-image
journaling and .aij file creation, using the following rules:
o If you specify the After_Journal qualifier and provide a file
specification, RMU Restore Only_Root creates a new extensible
.aij file and enables journaling.
o If you specify the After_Journal qualifier but you do not
provide a file specification, RMU Restore Only_Root creates
a new extensible .aij file with the same name as the journal
that was active at the time of the backup operation.
o If you specify the Noafter_Journal qualifier, RMU Restore
Only_Root disables after-image journaling and does not create
a new .aij file. Note that if you specify the Noafter_Journal
qualifier, there will be a gap in the sequence of .aij files.
For example, suppose your database has .aij file sequence
number 1 when you back it up. If you issue an RMU Restore
Only_Root command with the Noafter qualifier, the .aij file
sequence number will be changed to 2. This means that you
cannot (and do not want to) apply the original .aij file to
the restored database (doing so would result in a sequence
mismatch).
o If you do not specify an After_Journal, Noafter_Journal, Aij_
Options, or Noaij_Options qualifier, RMU Restore Only_Root
recovers the journal state (enabled or disabled) and tries to
reuse the .aij file or files.
If you choose this option, take great care to either set the
database root TSN and CSN correctly, or create a full and
complete backup file of the database. Failure to do so might
make it impossible for you to recover your database from the
.aij file should it become necessary.
However, if the .aij file or files are not available (for
example, they have been backed up), after-image journaling is
disabled.
You cannot use the After_Journal qualifier to create fixed-size
.aij files; use the Aij_Options qualifier.
4.3 – Aij Options
Aij_Options=journal-opts
Noaij_Options
Specifies how RMU Restore Only_Root is to handle after-image
journaling and .aij file creation, using the following rules:
o If you specify the Aij_Options qualifier and provide a
journal-opts file, RMU Restore Only_Root enables journaling
and creates the .aij file or files you specify for the
restored database. If only one .aij file is created for the
restored database, it will be an extensible .aij file. If two
or more .aij files are created for the database copy, they
will be fixed-size .aij files (as long as at least two .aij
files are always available).
o If you specify the Aij_Options qualifier, but do not provide a
journal-opts file, RMU Restore Only_Root disables journaling
and does not create any new .aij files.
o If you specify the Noaij_Options qualifier, RMU Restore Only_
Root disables journaling and does not create any new .aij
files.
o If you do not specify an After_Journal, Noafter_Journal, Aij_
Options, or Noaij_Options qualifier, RMU Restore Only_Root
recovers the journaling state (enabled or disabled) and tries
to reuse the .aij file or files.
If you choose this option, take great care to either set the
database root TSN and CSN correctly, or create a full and
complete backup file of the database. Failure to do so might
make it impossible for you to recover your database from the
.aij file should it become necessary.
However, if the .aij file or files are not available (for
example, they have been backed up), after-image journaling is
disabled.
See Show After_Journal for information on the format of a
journal-opts-file.
4.4 – Directory
Directory=directory-spec
Specifies the default directory for the database root and the
default directory for where the root can expect to find the
database storage areas and snapshot files.
See the Usage Notes for information on how this qualifier
interacts with the Root, File, and Snapshot qualifiers and for
warnings regarding restoring database files into a directory
owned by a resource identifier.
4.5 – Initialize Tsns
Initialize_Tsns
Noinitialize_Tsns
Initializes all transaction sequence number (TSN) values for
the entire database by setting the values to zero. Each time a
transaction is initiated against a database, a TSN is issued.
The numbers are incremented sequentially over the life of the
database.
TSN and CSN values are each contained in a quadword with the
following decimal format:
high longword : low longword
The high longword can hold a maximum user value of 32768
(215) and the low longword can hold a maximum user value of
4,294,967,295 (232). A portion of the high longword is used by
Oracle Rdb for overhead.
When you specify a TSN or CSN, you can omit the high longword and
the colon if the TSN or CSN fits in the low longword. For example
0:444 and 444 are both valid input values.
As your next TSN value approaches the maximum value allowed,
you should initialize the TSNs. You can determine the next TSN
and next commit sequence number (CSN) values by dumping the
database root file, using the RMU Dump command with the Header
and Option=Debug qualifiers.
The Initialize_Tsns qualifier takes much more time to execute
because all TSN values in the database are set to zero, which
requires writing to every page in the database. When the database
TSNs are reset, using the Initialize_Tsns qualifier, you should
use the After_Journal qualifier or the Aij_Options qualifier and
immediately perform a full database backup operation and create
a new .aij file. This ensures continuity of journaling and the
ability to recover the database.
The default Noinitialize_Tsns qualifier does not initialize the
database TSNs.
Note that you cannot use the Initialize_Tsns with the Set_Tsn
or Noset_Tsn qualifier in the same command. This restriction is
required because Initialize_Tsns directs RMU Restore Only_Root to
reset the TSN value to zero, while Set_Tsn directs RMU Restore
Only_Root to reset the TSN to the value you have indicated,
and Noset_Tsn leaves the TSN value unchanged. Never use the
Initialize_Tsns qualifier if Replication Option for Rdb transfers
have been defined for the database. The Initialize_Tsns qualifier
does not reset the Replication Option for Rdb transfers.
4.6 – 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 restore operation, the Label qualifier you specify
with the RMU Restore Only_Root command should be the same Label
qualifier you specified with the RMU Backup command you used to
back up your database.
The Label qualifier can be used with indirect file references.
See the Indirect-Command-Files help entry for more information.
4.7 – 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 implementation 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.8 – Log
Log
Nolog
Specifies whether the processing of the command is reported
to SYS$OUTPUT. Specify the Log qualifier to request that the
progress of the restore operation be written to SYS$OUTPUT and
the Nolog qualifier to suppress this report. 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.9 – Media Loader
Media_Loader
Nomedia_Loader
Use the Media_Loader qualifier to specify that the tape device
from which the backup 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, RMU Restore
Only_Root should recognize this fact. However, occasionally RMU
Restore Only_Root does not recognize that a tape device has a
loader or stacker. Therefore, when the first tape has been read,
RMU Restore Only_Root issues a request to the operator for the
next tape, instead of requesting the next tape from the loader
or stacker. Similarly, sometimes RMU Restore Only_Root behaves
as though a tape device has a loader or stacker when actually it
does not.
If you find that RMU Restore Only_Root is not recognizing that
your tape device has a loader or stacker, specify the Media_
Loader qualifier. If you find that RMU Restore Only_Root expects
a loader or stacker when it should not, specify the Nomedia_
Loader qualifier.
4.10 – New Snapshots
New_Snapshots
Nonew_Snapshots
Allows you to specify whether to create new snapshot (.snp) files
as part of a Restore Only_Root operation.
The default is the Nonew_Snapshots qualifier, which causes the
command to initialize the existing .snp files.
If you specify the New_Snapshots qualifier, the command creates
and initializes new .snp files. When you specify the New_
Snapshots qualifier, you should either delete the existing
.snp files before the restore operation or purge the .snp files
afterwards.
4.11 – Nodes Max
Nodes_Max=number-cluster-nodes
Specifies a new upper limit on the number of VMScluster nodes
from which users can access the restored database. The Nodes_Max
qualifier will accept values between 1 and 96 VMScluster nodes.
The actual maximum is the highest number of VMScluster nodes
possible in the current version of OpenVMS. The default value is
the limit defined for the database before it was backed up.
4.12 – Options
Options=file-spec
Specifies the options file that contains storage area names,
followed by the storage area qualifiers that you want applied to
that storage area.
You can direct RMU Restore Only_Root to create an options file
for use with this qualifier by specifying the Restore_Options
qualifier with the RMU Backup, RMU Dump, and RMU Dump Backup
commands. See Backup Database, Dump Database, and Dump Backup_
File for details.
If you create your own options file, do not separate the storage
area names with commas. Instead, put each storage area name on
a separate line in the file. The storage area qualifiers that
you can include in the options file are: Blocks_Per_Page, File,
Snapshot, and Thresholds. You can use the DCL line continuation
character, a hyphen (-), or the comment character (!) in the
options file. The default file extension is .opt. See Example 5
in the Examples help entry under this command.
4.13 – Rewind
Rewind
Norewind
Specifies whether the tape that contains the backup file will
be rewound before processing begins. The Norewind qualifier, the
default, causes the search for the backup file to begin at the
current tape position.
The Rewind and Norewind qualifiers are applicable only to tape
devices. RMU Restore Only_Root returns an error message if you
use these qualifiers and the device is not a tape device.
4.14 – Root
Root=root-file-spec
Requests that the database root (.rdb) be restored to the
specified location.
See the Usage Notes for information on how this qualifier
interacts with the Directory, File, and Snapshot qualifiers and
for warnings regarding restoring database files into a directory
owned by a resource identifier.
The Root qualifier is only meaningful when used with a multifile
database.
4.15 – Set Tsn
Set_Tsn=(Tsn=n, Csn=m)
Noset_Tsn
The Set_Tsn qualifier sets the database transaction sequence
number (TSN) and commit sequence number (CSN) to the specified
values. The correct value can be extracted from the original .rdb
file if it is still accessible, or from the last .aij file if one
is available. If that fails, you can use a TSN value larger than
the maximum number of transactions applied to the database since
it was created, or since TSNs were last initialized.
The TSN and CSN values do not have to be the same value. However,
you need to choose new values that are greater than the last
values assigned to a transaction. Set_Tsn values are expected
to be multiples of eight. If you specify a value that is not a
multiple of eight, RMU Restore Only_Root assigns the next highest
value that is a multiple of eight. (For example, if you specify
Set_Tsn=(Tsn=90, Csn=90), RMU Restore Only_Root assigns the Next
TSN a value of 96.)
The default value for the Set_Tsn qualifier is the TSN and CSN
values stored in the backup file plus 1,000,000 when TSNs are not
being initialized. The new TSN and CSN values for most database
applications should be larger than the number of transactions
committed since the database was last backed up. Set the TSN
and CSN values higher than this default increment value plus
the value in the backup file when needed. You can determine
the next TSN and CSN values by dumping the .rdb file, using the
Option=Debug qualifier.
The TSN and CSN values are each contained in a quadword with the
following decimal format:
high longword : low longword
The high longword can hold a maximum user value of 32768
(215) and the low longword can hold a maximum user value of
4,294,967,295 (232). A portion of the high longword is used by
Oracle Rdb for overhead.
When you specify a TSN or CSN, you can omit the high longword and
the colon if the TSN fits in the low longword. For example 0:444
and 444 are both valid TSN input values.
The Noset_Tsn qualifier specifies that the root will be restored
with the same TSN state as was recorded in the backup file.
When you use the Noset_Tsn qualifier in conjunction with the
Noupdate_Files qualifier, you can use a backup strategy that uses
recent by-area full backup files in place of a recent full and
complete backup file of the entire database. See Example 6 in the
Examples help entry under this command.
Note that you cannot use the Initialize_Tsns with the Set_Tsn
or Noset_Tsn qualifier in the same command. This restriction is
required because Initialize_Tsns directs RMU Restore Only_Root
to reset the TSN value to zero, while Set_Tsn directs RMU Restore
Only_Root to reset the TSN to the value you have indicated, and
Noset_Tsn leaves the TSN value unchanged.
4.16 – Transaction Mode=(mode-list)
Transaction_Mode=(mode-list)
Sets the allowable transaction modes for the database root file
created by the restore operation. The mode-list can include one
or more of the following transaction modes:
o All - Enables all transaction modes
o Current - Enables all transaction modes that are set for the
source database. This is the default transaction mode.
o None - Disables all transaction modes
o [No]Batch_Update
o [No]Read_Only
o [No]Exclusive
o [No]Exclusive_Read
o [No]Exclusive_Write
o [No]Protected
o [No]Protected_Read
o [No]Protected_Write
o [No]Read_Write
o [No]Shared
o [No]Shared_Read
o [No]Shared_Write
If you specify more than one transaction mode in the mode-list,
enclose the list in parenthesis and separate the transaction
modes from one another with a comma. Note the following:
o When you specify a negated transaction mode, for example
Noexclusive_Write, it indicates that exclusive write is not
an allowable access mode for the copied database.
o If you specify the Shared, Exclusive, or Protected transaction
mode, Oracle RMU assumes you are referring to both reading and
writing in that transaction mode.
o No mode is enabled unless you add that mode to the list, or
you use the All option to enable all transaction modes.
o You can list one transaction mode that enables or disables a
particular mode followed by another that does the opposite.
For example, Transaction_Mode=(Noshared_Write, Shared) is
ambiguous because the first value disables Shared_Write access
and the second value enables Shared_Write access. Oracle
RMU resolves the ambiguity by first enabling the modes as
specified in the modes-list and then disabling the modes as
specified in the modes-list. The order of items in the list is
irrelevant. In the example presented previously, Shared_Read
is enabled and Shared_Write is disabled.
4.17 – Update Files
Update_Files
Noupdate_Files
The Update_Files qualifier specifies that the root will be
restored, and RMU Restore Only_Root will attempt to link that
restored root to the area files. In addition, the snapshot (.snp)
file will be updated or created. This is the default.
The Noupdate_Files qualifier specifies that the restore operation
will restore the root, but it will not link that restored root
to any of the area files, nor will it create or update the .snp
files.
When you use the Noupdate_Files qualifier in conjunction with
the Noset_Tsn qualifier, you can use a backup strategy that uses
recent by-area full backup files in place of a recent full and
complete backup file of the entire database. See Example 6 in the
Examples help entry under this command
4.18 – Users Max
Users_Max=number-users
Specifies a new upper limit on the number of users that can
simultaneously access the restored database. The valid range is
between 1 and 2032 users. The default value is the value defined
for the database before it was backed up.
5 – File or Area Qualifiers
NOTE
Use these qualifiers to reconcile the information in the
database root file with the storage area files on disk.
These values can get out of synchronization when changes
have been made to storage areas or snapshot files after the
backup from which you are restoring the database root file
was created.
Setting these parameters updates the data in the root file
only; it does not change the attributes of the storage areas
or snapshot files themselves.
5.1 – Blocks Per Page
Blocks_Per_Page=integer
Noblocks_Per_Page
Updates the database root file with the number of blocks per
page for the storage area. Use this qualifier to update the root
when the blocks per page for a storage area has changed since
the backup file from which you are restoring was created. This
qualifier does not change the page size of a storage area itself;
its purpose is to update the database root file with corrected
information.
If you use the default, the Noblocks_Per_Page qualifier, RMU
Restore Only_Root takes the page size for the storage area from
the page size specified for the database you backed up. This is a
positional qualifier. This qualifier conflicts with storage areas
that have a uniform page format.
5.2 – File
File=file-spec
Updates the database root file with the file specification
for the storage-area-name parameter it qualifies. Use this
qualifier to update the root when the file specification for a
storage area has changed since the backup file from which you are
restoring the root was created. (For example, if you have used
the RMU Move_Area command since the backup file was created.)
This qualifier does not change the file specification of the
storage area it qualifies; its purpose is to update the database
root file with corrected information. When you specify the File
qualifier, you must supply a file name.
See the Usage Notes for information on how this qualifier
interacts with the Root, Snapshot, and Directory qualifiers.
This qualifier is not valid for single-file databases. This is a
positional qualifier.
5.3 – Read Only
Updates the database root file to reflect the read-only attribute
for the storage area it qualifies. Use this qualifier to update
the root when the read/write or read-only attribute has changed
since the backup file from which you are restoring has changed.
This qualifier does not change the attribute of the storage area
it qualifies; its purpose is to update the database root file
with corrected information.
If you do not specify the Read_Only or the Read_Write qualifier,
the storage areas is restored with the read/write attributes that
were in effect when the database was backed up.
5.4 – Read Write
Updates the database root file to reflect the read/write
attribute for the storage area it qualifies. Use this qualifier
to update the root when the read/write or read-only attribute
has changed since the backup file from which you are restoring
has changed. This qualifier does not change the attribute of the
storage area it qualifies; its purpose is to update the database
root file with corrected information.
If you do not specify the Read_Only or the Read_Write qualifier,
the storage areas is restored with the read/write attributes that
were in effect when the database was backed up.
5.5 – Snapshot
Snapshot=(Allocation=n,File=file-spec)
Updates the database root file to reflect the snapshot allocation
or snapshot file specification (or both) for the area it
qualifies. Use this qualifier to update the root when the
snapshot attributes have changed since the backup file from which
you are restoring the database root has changed. This qualifier
does not change the attributes of the snapshot file it qualifies;
its purpose is to update the database root file with corrected
information.
See the Usage Notes for information on how this qualifier
interacts with the Root, Snapshot, and Directory qualifiers.
The Snapshot qualifier is a positional qualifier.
When you do not specify the Snapshot qualifier, RMU Restore Only_
Root restores snapshot areas according to the information stored
in the backup file.
5.6 – Spams
Spams
Nospams
Updates the database root file to reflect the space area
management (SPAM) information for the storage areas in the
storage-area-list. Use this qualifier when the setting of SPAM
pages (enabled or disabled) has changed since the backup file
from which you are restoring the root was created. This qualifier
does not change the attributes of the storage area it qualifies;
its purpose is to update the database root file with corrected
information.
Use the Spams qualifier to update the root file information
to indicate that SPAM pages are enabled for the storage areas
qualified; use the Nospams qualifier to update the root file
information to indicate that SPAM pages are disabled for the
storage areas qualified. The default is to leave the attribute
unchanged from the setting recorded in the backup file. This is a
positional qualifier.
5.7 – Thresholds
Thresholds=(val1[,val2[,val3]])
Updates the database root file to reflect the threshold
information for the storage areas in the storage-area-list. Use
this qualifier when the threshold values have changed since the
backup file from which you are restoring the root was created.
This qualifier does not change the attributes of the storage area
it qualifies; its purpose is to update the database root file
with corrected information.
This is a positional qualifier.
The Thresholds qualifier applies only to storage areas with a
mixed page format.
If you do not use the Thresholds qualifier with the RMU Restore
Only_Root command, Oracle Rdb uses the storage area's thresholds
as recorded in the backup file.
See the Oracle Rdb7 Guide to Database Performance and Tuning for
more information on SPAM thresholds.
6 – Usage Notes
o To use the RMU Restore Only_Root 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 The RMU Restore Only_Root command provides two qualifiers,
Directory, and Root, that allow you to specify the target for
the restored database root file. In addition, the Directory,
File, and Snapshot file qualifiers allow you to specify a
target for updates to the database root for the storage
area and snapshot file locations. The target can be just a
directory, just a file name, or a directory and file name.
If you use all or some of these qualifiers, apply them as
follows:
- Use the Root qualifier to indicate the target for the
restored database root file.
- Use local application of the File qualifier to specify the
current location of a storage area file if its location
has changed since the database was backed up. The storage
area is not affected by this qualifier. This qualifier
updates the location of the storage area as recorded in the
database root file.
- Use local application of the Snapshots qualifier to specify
the current location of a snapshot file if its location
has changed since the database was backed up. The snapshot
file is not affected by this qualifier. This qualifier
updates the location of the snapshot file as recorded in
the database root file.
- Use the Directory qualifier to specify a default target
directory for the root file and as a default directory
for where the storage areas and snapshot files currently
reside. The default target directory is where the database
root file is restored if a directory specification is not
specified with the Root qualifier. The default directory
for the storage area and snapshot files is the directory
specification with which the root file is updated if these
files are not qualified with the Root, File, or Snapshot
qualifier. It is also the default directory with which the
Root file is updated for files qualified with the Root,
File, or Snapshot qualifier if these qualifiers do not
include a directory specification.
Note the following when using these qualifiers:
- Global application of the File qualifier when the target
specification includes a file name causes RMU Restore Only_
Root to update the file name recorded in the database root
file for all storage areas to be the same file name.
- Global application of the Snapshot qualifier when the
target specification includes a file name causes RMU
Restore Only_Root to update the file name recorded in the
database root file for all snapshot files to be the same
file name.
- Specifying a file name or extension with the Directory
qualifier is permitted, but causes RMU Restore Only_Root to
restore the database root file to the named directory and
file and update the file name recorded in the database root
file for all the storage areas and snapshot files to be the
same directory and file specification.
o When you restore a database root into a directory owned by
a resource identifier, the ACE for the directory is applied
to the database root file ACL first, and then the Oracle RMU
ACE is added. This method is employed to prevent database
users from overriding OpenVMS file security. However, this can
result in a database which you consider yours, but to which
you have no Oracle RMU privileges to access. See the Oracle
Rdb Guide to Database Maintenance for details.
o Only the database parameter values and the storage area
parameter values for which there are qualifiers can be updated
in the database root (.rdb) file using the restore-only-root
operation. All other database and storage area parameter
values that have changed since the database was last backed
up must be reapplied to the .rdb file using the SQL ALTER
DATABASE statement.
o There are no restrictions on the use of the Nospams qualifier
option with storage areas that have a mixed page format,
but the use of the Nospams qualifier typically causes severe
performance degradation. The Nospams qualifier is useful only
where updates are rare and batched, and access is primarily by
database key (dbkey).
o You must set both TSN and CSN values at the same time. You
cannot set the TSN value lower than the CSN value; however,
you can set a CSN value higher than the TSN value.
o The RMU Restore Only_Root command cannot be used if any
storage area has been extended since the backup operation
was done. You can use the RMU Dump Backup command with the
Option=Root qualifier to determine if this is the case.
7 – Examples
Example 1
To prevent corruption of your databases, check your CSN and TSN
values and set them to zero based on when they approach the
maximum. First, enter an RMU Dump command to display the next
CSN and next TSN values:
$ RMU/DUMP/HEADER=(SEQUENCE_NUMBERS) MF_PERSONNEL
.
.
.
Sequence Numbers...
- Transaction sequence number
Next number is 0:256
Group size is 0:32
- Commit sequence number
Next number is 0:256
Group size is 0:32
If the next CSN and the next TSN values are approaching the
maximum number allowed, you must perform the following operations
to initialize all TSN and CSN values to the value zero in your
database. The operation might take some time to execute as it
writes to every page in the database.
First, create a backup file for the database. Then restore
the database and initialize the CSN and TSN values with the
Initialize_Tsns qualifier. Then, enter an RMU Dump command again
to examine the next CSN and next TSN values. This example shows
that both values have been set to zero. If you displayed the
database pages, you would also notice that all TSN and CSN values
are set to zero.
$ RMU/BACKUP MF_PERSONNEL MF_PER_124.RBF
$ RMU/RESTORE/ONLY_ROOT /INITIALIZE_TSNS MF_PER_124.RBF
$ RMU/DUMP/HEADER=(SEQUENCE_NUMBERS) MF_PERSONNEL
.
.
.
Sequence Numbers...
- Transaction sequence number
Next number is 0:0
Group size is 0:32
- Commit sequence number
Next number is 0:0
Group size is 0:32
Example 2
Perform the following to set the TSN and CSN values to a number
that you select; a number that is greater than or equal to the
next CSN and next TSN values. If the number you have selected
is less than the next CSN and next TSN values recorded in the
database header, you receive an error as follows:
$ RMU/RESTORE/ONLY_ROOT/SET_TSN=(TSN=40,CSN=40)
_$ MF_PERSONNEL.RBF
%RMU-F-TSNLSSMIN, value (0:40) is less than minimum
allowed value (0:224) for /SET_TSN=TSN
%RMU-F-FTL_RSTR, Fatal error for RESTORE operation
at 18-JUN-1997 16:59:19.32
Enter a number equal to or greater than the next CSN and next TSN
values recorded in the database header:
$ RMU/RESTORE/ONLY_ROOT/SET_TSN=(TSN=274,CSN=274) -
_$ MF_PERSONNEL.RBF
Enter an RMU Dump command to see the next CSN and next TSN
values:
$ RMU/DUMP/HEADER=(SEQUENCE_NUMBERS) MF_PERSONNEL
.
.
.
Sequence Numbers...
- Transaction sequence number
Next number is 0:288
Group size is 0:32
- Commit sequence number
Next number is 0:288
Group size is 0:32
- Database bind sequence number
Next number is 0:288
Example 3
The following RMU Restore Only_Root command restores the database
root file from the database backup file (.rbf) to another device:
$ RMU/RESTORE/ONLY_ROOT/ROOT=DXXV9:[BIGLER.TESTING]MF_PERSONNEL -
_$ MF_PERSONNEL_BACKUP.RBF
The following DIRECTORY command confirms that the MF_
PERSONNEL.RDB file was restored in the specified directory:
$ DIRECTORY DXXV9:[BIGLER.TESTING]MF_PERSONNEL.RDB
Directory DXXV9:[BIGLER.TESTING]
MF_PERSONNEL.RDB;1 21-JAN-1991 14:37:36.87
Total of 1 file.
Example 4
Use the File=file-spec qualifier to update the .rdb file with a
storage area's new location. If you have moved a storage area to
a new location, use the File qualifier to show its new location
and the Snapshot qualifier to indicate the current version of
the area's snapshot (.snp) file. Enter the following RMU commands
to execute a series of operations that use the File and Snapshot
qualifiers in a restore-only-root operation to update the .rdb
file with new information since the database was last backed up.
Back up the database file:
$ RMU/BACKUP MF_PERSONNEL MFPERS_122.RBF.
Move the area to another directory:
$ RMU/MOVE_AREA MF_PERSONNEL JOBS -
_$ /FILE=[BIGLER.MFTEST.TEST1]JOBS.RDA
With the RMU Restore Only_Root command, give the area name, and
specify both the storage area file specification and its new
location. Also specify the snapshot (.snp) file with its correct
version. Note that .snp file version numbers increment with the
RMU Move_Area command.
$ RMU/RESTORE/ONLY_ROOT MFPERS_122.RBF JOBS -
_$ /FILE=[BIGLER.MFTEST.TEST1]JOBS.RDA -
_$ /SNAPSHOT=(FILE=[BIGLER.V41MFTEST]JOBS.SNP;2)
Display the .rdb file header and note that the file is correctly
updated.
The dump of the database root file lists these file
specifications:
$ RMU/DUMP/HEADER MF_PERSONNEL
DXXV9:[BIGLER.MFTEST.TEST1]JOBS.RDA;1
DXXV9:[BIGLER.MFTEST]JOBS.SNP;2
Verify the .rdb file to be certain that it has been properly
and completely updated relative to the files and their version
numbers that comprise the database.
$ RMU/VERIFY/ROOT MF_PERSONNEL
Example 5
The following command achieves the same results as the RMU
Restore Only_Root command in Example 4, but uses an options file
to specify the current location of the JOBS storage area and the
associated .snp file.
$ RMU/RESTORE/ONLY_ROOT MFPERS_122.RBF -
_$ JOBS/OPTIONS=OPTIONS_FILE.OPT
$ !
$ TYPE OPTIONS_FILE.OPT
JOBS /FILE=[BIGLER.V41MFTEST.TEST1]JOBS.RDA -
/SNAPSHOT=(FILE=BIGLER.V41MFTEST]JOBS.SNP)
Example 6
The following example demonstrates the use of the Noset_Tsn
qualifier and the Noupdate_Files qualifier to restore a database
using by-area backup files. In addition, it demonstrates the
automatic recovery feature of the RMU Restore command.
$ !
$ SET DEFAULT DISK1:[USER]
$ !
$ ! Create .aij files for the database. Because three .aij files are
$ ! created, fixed-size after-image journaling will be used.
$ !
$ RMU/SET AFTER_JOURNAL/ENABLE/RESERVE=4 -
_$ /ADD=(name=AIJ1, FILE=DISK2:[CORP]AIJ_ONE) -
_$ /ADD=(name=AIJ2, FILE=DISK2:[CORP]AIJ_TWO) -
_$ /ADD=(NAME=AIJ3, FILE=DISK2:[CORP]AIJ_THREE) -
_$ MF_PERSONNEL
%RMU-W-DOFULLBCK, full database backup should be done to
ensure future recovery
$ !
$ !
$ ! For the purposes of this example, assume the backup operation
$ ! recommended in the preceding warning message is done, but
$ ! that the time between this backup operation and the following
$ ! operations is several months so that this backup file is too
$ ! old to use in an efficient restore operation.
$ !
$ ! Update the DEPARTMENTS table.
$ !
$ SQL
SQL> ATTACH 'FILENAME MF_PERSONNEL';
SQL> --
SQL> -- On Monday, insert a new row in the DEPARTMENTS table. The
SQL> -- new row is stored in the DEPARTMENTS storage area.
SQL> --
SQL> INSERT INTO DEPARTMENTS
cont> (DEPARTMENT_CODE, DEPARTMENT_NAME, MANAGER_ID,
cont> BUDGET_PROJECTED, BUDGET_ACTUAL)
cont> VALUES ('WLNS', 'Wellness Center', '00188', 0, 0);
1 row inserted
SQL>
SQL> COMMIT;
SQL> DISCONNECT DEFAULT;
SQL> EXIT
$ !
$ ! Perform a by-area backup operation, including half of the
$ ! storage areas from the mf_personnel database.
$ !
$ RMU/BACKUP/INCLUDE=(RDB$SYSTEM, EMPIDS_LOW, EMPIDS_MID, -
_$ EMPIDS_OVER, DEPARTMENTS) MF_PERSONNEL -
_$ DISK3:[BACKUP]MONDAY_FULL.RBF
%RMU-I-NOTALLARE, Not all areas will be included in
this backup file
$ !
$ ! Update the SALARY_HISTORY table.
$ !
$ SQL
SQL> ATTACH 'FILENAME MF_PERSONNEL';
SQL> --
SQL> -- On Tuesday, one row is updated in the
SQL> -- SALARY_HISTORY storage area.
SQL> --
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.00'
cont> AND EMPLOYEE_ID = '00164';
1 row updated
SQL> COMMIT;
SQL> DISCONNECT DEFAULT;
SQL> EXIT
$ !
$ ! On Tuesday, back up the other half of the storage areas.
$ !
$ RMU/BACKUP/INCLUDE=(SALARY_HISTORY, JOBS, EMP_INFO, -
_$ MF_PERS_SEGSTR, RDB$SYSTEM) MF_PERSONNEL -
_$ DISK3:[BACKUP]TUESDAY_FULL.RBF
%RMU-I-NOTALLARE, Not all areas will be included in this
backup file
$ !
$ ! On Wednesday, perform additional updates.
$ !
$ SQL
SQL> ATTACH 'FILENAME MF_PERSONNEL';
SQL> --
SQL> -- Update another row in the SALARY_HISTORY table:
SQL> UPDATE SALARY_HISTORY
cont> SET SALARY_START ='23-SEP-1991 00:00:00.00'
cont> WHERE SALARY_START='21-SEP-1981 00:00:00.00'
cont> AND EMPLOYEE_ID = '00164';
1 row updated
SQL> COMMIT;
SQL> DISCONNECT DEFAULT;
SQL> EXIT
$ !
$ ! Assume the database is lost on Wednesday.
$ !
$ ! Restore the database root from the latest full-area backup file.
$ !
$ RMU/RESTORE/ONLY_ROOT/NOUPDATE_FILES/NOSET_TSN -
_$ DISK3:[BACKUP]TUESDAY_FULL.RBF/LOG
%RMU-I-AIJRSTBEG, restoring after-image journal "state" information
%RMU-I-AIJRSTJRN, restoring journal "AIJ1" information
%RMU-I-AIJRSTSEQ, journal sequence number is "0"
%RMU-I-AIJRSTSUC, journal "AIJ1" successfully restored from
file "DISK2:[CORP]AIJ_ONE.AIJ;1"
%RMU-I-AIJRSTJRN, restoring journal "AIJ2" information
%RMU-I-AIJRSTNMD, journal has not yet been modified
%RMU-I-AIJRSTSUC, journal "AIJ2" successfully restored from
file "DISK2:[CORP]AIJ_TWO.AIJ;1"
%RMU-I-AIJRSTJRN, restoring journal "AIJ3" information
%RMU-I-AIJRSTNMD, journal has not yet been modified
%RMU-I-AIJRSTSUC, journal "AIJ3" successfully restored from
file "DISK2:[CORP]AIJ_THREE.AIJ;1"
%RMU-I-AIJRSTEND, after-image journal "state" restoration complete
%RMU-I-RESTXT_00, Restored root file
DISK1:[USER]MF_PERSONNEL.RDB;1
%RMU-I-AIJRECBEG, recovering after-image journal "state" information
%RMU-I-AIJRSTAVL, 3 after-image journals available for use
%RMU-I-AIJRSTMOD, 1 after-image journal marked as "modified"
%RMU-I-LOGMODSTR, activated after-image journal "AIJ2"
%RMU-I-AIJISON, after-image journaling has been enabled
%RMU-W-DOFULLBCK, full database backup should be done to
ensure future recovery
%RMU-I-AIJRECEND, after-image journal "state" recovery complete
$ !
$ ! Restore the database areas, starting with the most recent
$ ! full-area backup file. (If the RDB$SYSTEM area is not in the
$ ! most recent full-area backup file, however, it must be restored
$ ! first.) Do not restore any area more than once.
$ !
$ ! Specify the Norecovery qualifier since there are additional
$ ! backup files to apply.
$ !
$ RMU/RESTORE/AREA/NOCDD/NORECOVER -
_$ DISK3:[BACKUP]TUESDAY_FULL.RBF -
_$ RDB$SYSTEM, SALARY_HISTORY, JOBS, -
_$ EMP_INFO, MF_PERS_SEGSTR/LOG
%RMU-I-RESTXT_21, Starting full restore of storage area
DISK1:[USER]MF_PERS_DEFAULT.RDA;1 at 18-JUN-1997 16:14:40.88
%RMU-I-RESTXT_21, Starting full restore of storage area
DISK1:[USER]SALARY_HISTORY.RDA;1 at 18-JUN-1997 16:14:41.28
%RMU-I-RESTXT_21, Starting full restore of storage area
DISK1:[USER]JOBS.RDA;1 at 18-JUN-1997 16:14:41.83
%RMU-I-RESTXT_21, Starting full restore of storage area
DISK1:[USER]EMP_INFO.RDA;1 at 18-JUN-1997 16:14:42.06
%RMU-I-RESTXT_21, Starting full restore of storage area
DISK1:[USER]MF_PERS_SEGSTR.RDA;1 at 18-JUN-1997 16:14:42.27
%RMU-I-RESTXT_24, Completed full restore of storage area
DISK1:[USER]JOBS.RDA;1 at 18-JUN-1997 16:14:42.49
%RMU-I-RESTXT_24, Completed full restore of storage area
DISK1:[USER]EMP_INFO.RDA;1 at 18-JUN-1997 16:14:42.74
.
.
.
%RMU-I-RESTXT_01, Initialized snapshot file
DISK1:[USER]MF_PERS_DEFAULT.SNP;1
%RMU-I-LOGINIFIL, contains 100 pages, each page
is 2 blocks long
%RMU-I-RESTXT_01, Initialized snapshot file
DISK1:[USER]EMP_INFO.SNP;1
%RMU-I-LOGINIFIL, contains 100 pages, each page
is 2 blocks long
.
.
.
%RMU-I-AIJWASON, AIJ journaling was active when
the database was backed up
%RMU-I-AIJRECFUL, Recovery of the entire database
starts with AIJ file sequence 0
%RMU-I-COMPLETED, RESTORE operation completed
at 18-JUN-1997 16:14:46.82
$ !
$ ! Complete restoring database areas by applying the most
$ ! recent full-area backup file. However, do not include
$ ! the RDB$SYSTEM table because that was already restored
$ ! in the previous restore operation. This restore
$ ! operation will attempt an automatic recovery of the .aij files.
$ !
$ RMU/RESTORE/AREA/NOCDD DISK3:[BACKUP]MONDAY_FULL.RBF -
_$ EMPIDS_LOW, EMPIDS_MID, EMPIDS_OVER, DEPARTMENTS/LOG
%RMU-I-RESTXT_21, Starting full restore of storage area
DISK1:[USER]EMPIDS_OVER.RDA;1 at 18-JUN-1997 16:20:05.08
%RMU-I-RESTXT_21, Starting full restore of storage area
DISK1:[USER]EMPIDS_MID.RDA;1 at 18-JUN-1997 16:20:05.40
%RMU-I-RESTXT_21, Starting full restore of storage area
DISK1:[USER]EMPIDS_LOW.RDA;1 at 18-JUN-1997 16:20:05.91
%RMU-I-RESTXT_21, Starting full restore of storage area
DISK1:[USER]DEPARTMENTS.RDA;1 at 18-JUN-1997 16:20:06.01
%RMU-I-RESTXT_24, Completed full restore of storage area
DISK1:[USER]EMPIDS_OVER.RDA;1 at 18-JUN-1997 16:20:06.24
.
.
.
%RMU-I-RESTXT_01, Initialized snapshot file
DISK1:[USER]DEPARTMENTS.SNP;1
%RMU-I-LOGINIFIL, contains 100 pages, each page
is 2 blocks long
%RMU-I-RESTXT_01, Initialized snapshot file
DISK1:[USER]EMPIDS_LOW.SNP;1
%RMU-I-LOGINIFIL, contains 100 pages, each page
is 2 blocks long
.
.
.
%RMU-I-AIJWASON, AIJ journaling was active when
the database was backed up
%RMU-I-AIJRECFUL, Recovery of the entire database
starts with AIJ file sequence 0
%RMU-I-AIJRECARE, Recovery of area DEPARTMENTS starts
with AIJ file sequence 0
%RMU-I-AIJRECARE, Recovery of area EMPIDS_LOW starts
with AIJ file sequence 0
%RMU-I-AIJRECARE, Recovery of area EMPIDS_MID starts
with AIJ file sequence 0
%RMU-I-AIJRECARE, Recovery of area EMPIDS_OVER starts
with AIJ file sequence 0
%RMU-I-AIJBADAREA, inconsistent storage area
DISK1:[USER]DEPARTMENTS.RDA;1 needs AIJ sequence number 0
%RMU-I-AIJBADAREA, inconsistent storage area
DISK1:[USER]EMPIDS_LOW.RDA;1 needs AIJ sequence number 0
.
.
.
%RMU-I-LOGRECDB, recovering database file
DISK1:[USER]MF_PERSONNEL.RDB;1
%RMU-I-AIJAUTOREC, starting automatic after-image
journal recovery
%RMU-I-LOGOPNAIJ, opened journal file DISK2:[CORP]AIJ_ONE.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, 2 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 2 transactions ignored
%RMU-I-AIJSUCCES, database recovery completed successfully
%RMU-I-AIJGOODAREA, storage area
DISK1:[USER]DEPARTMENTS.RDA;1 is now consistent
%RMU-I-AIJGOODAREA, storage area
DISK1:[USER]EMPIDS_LOW.RDA;1 is now consistent
%RMU-I-AIJGOODAREA, storage area
DISK1:[USER]EMPIDS_MID.RDA;1 is now consistent
.
.
.
%RMU-I-AIJFNLSEQ, to start another AIJ file recovery,
the sequence number needed will be 0
%RMU-I-COMPLETED, RESTORE operation completed at
18-JUN-1997 16:20:11.45
$ !
$ ! The database is now restored and recovered. However, if
$ ! for some reason the automatic .aij file recovery was not
$ ! possible (for example, if you had backed up the .aij files),
$ ! apply the .aij files in the same order in
$ ! which they were created. That is, if .aij files were backed
$ ! up each night, apply aij_mon.aij first and aij_tues.aij second.
Example 7
The following example demonstrates the use of the Directory,
File, and Root qualifiers. First, the database is backed up, then
a couple storage area files and a snapshot file are moved. The
restore-only-root operation does the following:
o The default directory is specified as DISK2:[DIR].
o The target directory and file name for the database root file
is specified with the Root qualifier. The target directory
specified with the Root qualifier overrides the default
directory specified with the Directory qualifier. Thus, the
RMU Restore Only_Root process restores the database root in
DISK3:[ROOT] and names it COPYRDB.RDB.
o The target directory for the EMPIDS_MID storage area is
DISK4:[FILE]. The RMU Restore Only_Root process updates the
database root file to indicate that EMPIDS_MID currently
resides in DISK4:[FILE].
o The target for the EMPIDS_MID snapshot file is
DISK5:[SNAP]EMPIDS_MID.SNP Thus, the RMU Restore Only_
Root process updates the database root file to indicate
that the EMPIDS_MID snapshot file currently resides in
DISK5:[SNAP]EMPIDS_MID.SNP.
o The target file name for the EMPIDS_LOW storage area is
EMPIDS. Thus, the RMU Restore Only_Root process updates
the database root file to indicate that the EMPIDS_LOW
storage area currently resides in the DISK2 default directory
(specified with the Directory qualifier), and the file is
currently named EMPIDS.RDA.
o The target for the EMPIDS_LOW snapshot file is
DISK5:[SNAP]EMPIDS.SNP. Thus, the RMU Restore Only_
Root process updates the database root file to indicate
that the EMPIDS_LOW snapshot file currently resides in
DISK5:[SNAP]EMPIDS.SNP.
o Data for all the other storage area files and snapshot files
remain unchanged in the database root file.
$ ! Back up the database:
$ !
$ RMU/BACKUP MF_PERSONNEL.RDB MF_PERSONNEL.RBF
$ !
$ ! Move a couple of storage areas and a snapshot file:
$ !
$ RMU/MOVE_AREA MF_PERSONNEL.RDB -
_$ /DIRECTORY=DISK2:[DIR] -
_$ EMPIDS_MID/FILE=DISK4:[FILE] -
_$ /SNAPSHOT=(FILE=DISK3:[SNAP]EMPIDS_MID.SNP), -
_$ EMPIDS_LOW/FILE=EMPIDS -
_$ /SNAPSHOT=(FILE=DISK5:[SNAP]EMPIDS.SNP)
$ !
$ ! Database root is lost. Restore the root and update the
$ ! locations of the moved storage areas and snapshot file as
$ ! recorded in the database root file because the locations
$ ! recorded in the backup file from which the root is restored
$ ! are not up-to-date:
$ !
$ RMU/RESTORE/ONLY_ROOT MF_PERSONNEL.RBF -
_$ /ROOT=DISK3:[ROOT]MF_PERSONNEL.RDB -
_$ EMPIDS_MID/FILE=DISK4:[FILE] -
_$ /SNAPSHOT=(FILE=DISK2:[DIR]EMPIDS_MID.SNP), -
_$ EMPIDS_LOW/FILE=DISK2:[DIR]EMPIDS -
_$ /SNAPSHOT=(FILE=DISK5:[SNAP]EMPIDS.SNP)