Restores a database to the condition it was in at the time a
full or incremental backup operation was performed with an
RMU Backup command. In addition, if after-image journal (.aij)
files have been retained, RMU Restore attempts to apply any pre-
existing .aij files to recover the database completely. See the
Description help entry under this command for details on the
conditions under which RMU Restore attempts an automatic .aij
file recovery as part of the restore operation.
When you use the RMU Restore command to restore the database
to a system with a more recent version of Oracle Rdb software,
an RMU Convert command with the Noconfirm and Commit qualifiers
is automatically executed as part of RMU Restore. Therefore, by
executing the RMU Restore command, you convert that database
to the current version. See the Oracle Rdb Installation and
Configuration Guide for the proper backup procedure prior
to installing a new release of Oracle Rdb and restoring (or
converting) databases.
When you use the RMU Restore command to restore a database that
was recently RMU/Converted but with the /NoCommit qualifier,
the behavior is different than that stated above. /Commit is
the default for an RMU Restore of an uncommited database (a
database that contains both current and previous versions of the
metadata that was converted by specifying RMU/CONVERT/NOCOMMIT or
RMU/RESTORE/NOCOMMIT) but ONLY if the noncommited database being
restored is NOT of the current Rdb version. RMU/RESTORE/COMMIT
and RMU/RESTORE/NOCOMMIT only take effect if RMU/RESTORE needs
to call RMU/CONVERT because the database being restored is of a
previous Rdb version.
If the /COMMIT is specified or defaulted for the Restore of a
database of the current level, it is ignored. In this case, an
RMU/CONVERT/COMMIT must be used to commit the previous uncommited
restore or conversion.
NOTE
When you restore a database, default or propagated OpenVMS
access control entries (ACEs) for the database root (.rdb)
file take precedence over any Oracle RMU database access you
might have.
Therefore, if default or propagated entries are in use,
you must use the RMU Show Privilege and RMU Set Privilege
commands after a restore operation completes to verify and
correct the Oracle RMU access. (You can tell if default or
propagated entries are in use because RMU Restore displays
the warning message "RMU-W-PREVACL, Restoring the root ACL
over a pre-existing ACL". This is a normal condition if the
RMU Restore command was invoked from the CDO utility.)
To use RMU Show Privilege and RMU Set Privilege commands,
you must have the rights to edit the access control
list (ACL) using RMU$SECURITY access (which is VMS BIT_
15 access in the access control entry (ACE)) and also
(READ+WRITE+CONTROL) access. (Note that you can grant
yourself BIT_15 access by using the DCL SET ACL command
if you have (READ+WRITE+CONTROL) access.
If you do not have the required access after a restore
operation to make the needed changes, someone with the
required access or OpenVMS BYPASS or SECURITY access must
examine and correct the ACL.
This behavior exists in Oracle RMU to prevent someone from
using Oracle RMU to override the existing OpenVMS security
policy.
1 – Description
RMU Restore rebuilds a database from a backup file, produced
earlier by an RMU Backup command, to the condition the database
was in when the backup operation was performed and attempts to
automatically recover the .aij files to provide a fully restored
and recovered database.
You can specify only one backup file parameter in an RMU Restore
command. If this parameter is a full backup file, you cannot use
the Incremental qualifier. However, you must use the Incremental
qualifier if the parameter names an incremental backup file.
RMU Restore attempts automatic .aij file recovery by default when
you issue a database restore command if you are using fixed-
size .aij files, if .aij files have been retained, and if a
database conversion has not been performed. (The .aij files are
not retained when you specify any of the following qualifiers:
Aij_Options, After_Journal, or Duplicate.) RMU Restore does not
attempt automatic .aij file recovery if you have backed up any
of your .aij files (using the RMU Backup After_Journal command)
because RMU Restore has no knowledge of those backup files.
In addition, success of the automatic .aij file recovery
operation requires that the following criteria be met:
o Fixed-size after-image journaling is in effect.
o The .aij files must be on disk (not on tape).
o The .aij files must not have been marked as inaccessible at
the time the database backup operation was performed.
o The .aij files must exist and have proper privileges for both
read and write operations.
o The .aij files must be able to be accessed exclusively;
failure indicates that an .aij file is in use by another
database user.
o The .aij files must have a nonzero length.
o The .aij files must have valid header information that
corresponds to the current Oracle Rdb product and version
number.
o The sequence number in the .aij file header must not conflict
with the restored definition in the database root information.
o The original .rdb file name must not exist.
NOTE
RMU Restore attempts automatic .aij file recovery when you
restore a database from a full, incremental, by-area, or
by-page backup file. However, in some cases, you will want
to disable this feature by using the Norecovery qualifier.
Specifically, you should specify the Norecovery qualifier if
either of the following are true:
o You are restoring the database from a previous version of
Oracle Rdb.
o You need to issue more than one RMU Restore command to
completely restore the database.
For example, if you intend to restore a database by
first issuing a full RMU Restore command followed by
the application of one or more RMU Restore commands with
the Incremental or Area qualifiers, you must specify the
Norecovery qualifier on all but the last RMU Restore
command in the series you intend to issue. Allowing
Oracle RMU to attempt automatic recovery with a full
restore operation when you intend to apply additional
incremental, by-area, or by-page backup files can result
in a corrupt database.
RMU Restore does not attempt automatic .aij file recovery if any
of the following conditions are true:
o The database has been converted since the time you created the
backup file that you are attempting to restore.
o The first .aij file is not available (perhaps because it has
been backed up).
o After-image journaling was disabled when the backup operation
was performed.
o After-image journaling was disabled when the database (or
portion of it) was lost.
o You specify the Aij_Options, After_Journal, or Duplicate
qualifier with the RMU Restore command.
If RMU Restore attempts automatic .aij file recovery but fails,
you can still recover your database by using the RMU Recover
command if the restore operation was successful.
NOTE
Using the DCL COPY command with a multifile database
(assuming the files are copied to a new location) will
result in an unsupported, unusable database. This happens
because the DCL COPY command cannot update the full file
specification pointers (stored in the database root file) to
the other database files (.rda, .snp, and optional .aij).
You can rename or move the files that comprise a multifile
Oracle Rdb database by using one of the following commands:
o The RMU Backup and RMU Restore commands
o The SQL EXPORT and IMPORT statements
o The RMU Move_Area command
o The RMU Copy_Database command
By default, RMU Restore integrates the metadata stored in the
database root (.rdb) file with the data dictionary copy of the
metadata (assuming the data dictionary is installed on your
system). However, you can prevent dictionary integration by
specifying the Nocdd_Integrate qualifier.
When you specify the Incremental or Area qualifiers, do not
specify the following additional qualifiers:
Directory
Nodes_Max
New_Version
Nonew_Version
Users_Max
The RMU Restore command ignores the Confirm qualifier if you
omit the Incremental qualifier. Also, you must specify the Root
qualifier when you restore an incremental backup file to a new
version of the database, renamed database, or a restored database
in a new location.
See the Usage Notes subentry for information on restoring a
database from tape.
2 – Format
(B)0[mRMU/Restore backup-file-spec [storage-area-name[,...]]
[4mCommand[m [4mQualifiers[m x [4mDefaults[m
x
/[No]Acl x /Acl
/Active_IO=max-reads x /Active_IO=3
/[No]After_Journal=file-spec x See description
/[No]Aij_Options=journal-opts x See description
/Area x See description
/[No]Cdd_Integrate x /Cdd_Integrate
/Close_Wait=n x See description
/[No]Commit x /Commit
/[No]Confirm x See description
/Directory=directory-spec x See description
/Disk_File[=(Reader_Threads=n)] x /Disk_File=(Reader_Threads=1)
/[No]Duplicate x /Noduplicate
/Encrypt=({Value=|Name=}[,Algorithm=]) x See description
/Global_Buffers=global-buffer-options x Current value
/Incremental x Full restore
/Journal=file-name x See description
/Just_Corrupt x See description
/Label=(label-name-list) x See description
(B)0[m/Librarian[=options] x None
/Loader_Synchronization x See description
/Local_Buffers=local-buffer-options x Current value
/[No]Log[=Brief|Full] x Current DCL verify value
/Master x See description
/[No]Media_Loader x See Description
/[No]New_Version x /Nonew_Version
/Nodes_Max=number-cluster-nodes x See description
/[No]Online x /Noonline
/Open_Mode={Automatic|Manual} x Current value
/Options=file-spec x None
/Page_Buffers=number-buffers x /Page_Buffers=3
/Path=cdd-path x Existing value
/Prompt={Automatic|Operator|Client} x See description
/[No]Recovery[=Aij_Buffers=n] x See description
/[No]Rewind x /Norewind
/Root=root-file-spec x Existing value
/Transaction_Mode=(mode-list) x /Transaction_Mode=Current
/Users_max=number-users x Existing value
/Volumes=n x /Volumes=1
(B)0[m[4mFile[m [4mor[m [4mArea[m [4mQualifiers[m x [4mDefaults[m
x
/Blocks_Per_Page=integer x See description
/Extension= {Disable|Enable} x Current value
/File=file-spec x See description
/Just_Corrupt 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 Current value
3 – Parameters
3.1 – backup-file-spec
A file specification for the backup file produced by a previous
RMU Backup command. 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.
The default file extension is .rbf.
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 To restore 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 To restore from single or multiple 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 also be sure to include the Disk_
File qualifier. For example:
$ RMU/RESTORE/DISK_FILE DISK1:[DIR1]MFP.RBF,DISK2:[DIR2],DISK3:[DIR3]
As an alternative to listing the disk device names on the
command line (which, if you use several devices, can exceed
the line-limit length for a command line), you can specify an
options file in place of the backup-file-spec. For example:
$ RMU/RESTORE/DISK_FILE "@DEVICES.OPT"
The contents of devices.opt might appear as follows:
DISK1:[DIR1]MFP.RBF
DISK2:[DIR2]
DISK3:[DIR3]
The backup files referenced from such an options file are:
DISK1:[DIR1]MFP.RBF
DISK2:[DIR2]MFP01.RBF
DISK3:[DIR3]MFP02.RBF
3.2 – storage-area-name
storage-area-name[,...]
A storage area name from the database. This parameter is
optional. Use it in the following situations:
o When you want to change the values for thresholds or blocks
per page.
o When you want to change the names specified with the Snapshot
or the File qualifier for the restored database.
o If you want to restore only selected storage areas from your
backup file, you must use the Area qualifier and specify the
names of the storage areas you want to restore in either the
storage-area-name parameter in the RMU Restore command line,
or in the file specified with the Options qualifier.
To use this option, specify the storage area name rather than
the file specification for the storage area.
By using the RMU Backup and RMU Restore commands, you can back up
and restore selected storage areas of your database. This Oracle
RMU backup and restore by-area feature is designed to:
o Speed recovery when corruption occurs in some (not all) of the
storage areas of your database.
o Reduce the time needed to perform backup operations because
some data (data in read-only storage areas, for example) does
not need to be backed up with every backup operation performed
on the database.
If you plan to use the RMU Backup and RMU Restore commands to
back up and restore only selected storage areas for a database,
you must perform full and complete backup operations on the
database at regular intervals. A full and complete backup is a
full backup (not an incremental backup) operation on all the
storage areas in the database. If the database root (.rdb) file
is corrupted, you can only recover storage areas up to (but not
past) the date of the last full and complete backup operation.
Therefore, Oracle Corporation recommends that you perform full
and complete backup operations regularly.
If you plan to back up and restore only selected storage areas
for a database, Oracle Corporation strongly recommends that you
enable after-image journaling for the database (in addition to
performing the full and complete backup operation on the database
as described earlier). That is, if you are not backing up and
restoring all the storage areas in your database, you should have
after-image journaling enabled. This ensures that you can recover
all the storage areas in your database in the event of a system
failure. If you do not have after-image journaling enabled and
one or more of the areas restored by RMU Restore are not current
with the storage areas not restored, Oracle Rdb will not allow
any transactions to use the storage areas that are not current
in the restored database. In this situation, you can return to a
working database by restoring the database, using the backup file
from the last full and complete backup operation on the database
storage areas. However, any changes made to the database since
the last full and complete backup operation was performed are not
recoverable.
If you have after-image journaling enabled, use the RMU Recover
command to apply transactions from the .aij file to storage areas
that are not current after the RMU Restore command completes.
When the RMU Recover command completes, your database will be
consistent and usable.
4 – Command Qualifiers
4.1 – Acl
Acl
Noacl
Allows you to specify whether to restore the root file access
control list (ACL) that was backed up.
If you specify the Acl qualifier, the root file ACL that was
backed up is restored with the database. If the root file ACL
was not backed up and you specify the Acl qualifier with the RMU
Restore command, then RMU Restore restores the database without a
root file ACL.
If you specify the Noacl qualifier, the root file ACL is not
restored with the database.
The default is the Acl qualifier.
4.2 – Active IO
Active_IO=max-reads
Specifies the maximum number of read operations from the backup
file that RMU Restore attempts simultaneously. The value of the
Active_IO qualifier can range from 1 to 5. The default value is
3. Values larger than 3 might improve performance with multiple
tape drives.
4.3 – 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
interested in creating an extensible .aij file only. (An
extensible .aij file is one that is extended by a specified
amount when it reaches a certain threshold of fullness-
assuming there is sufficient space on the disk where it
resides.)
Specifies how RMU Restore 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, the RMU process 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 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
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 the .aij files. For
example, suppose your database has .aij file sequence number 1
when you back it up. If you issue an RMU Restore command with
the Noafter_Journal 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 recovers the
journal state (enabled or disabled) and tries to reuse the
.aij file or files. (See the Description help entry under this
command for details on when automatic .aij file recovery is
not attempted.)
When you specify an .aij file name, you should specify a new
device and directory for the .aij file. If you do not specify a
device and directory, you receive a warning message. To protect
yourself against media failures, put the .aij file on a different
device from that of your database files.
If the original database is lost or corrupted but the journal
files are unaffected, you would typically restore the database
without the use of either the Aij_Options or the After_Journal
qualifier.
The After_Journal qualifier conflicts with the Area and
Incremental qualifiers; you cannot specify the After_Journal
qualifier and either of these two other qualifiers in the same
RMU Restore command line.
You cannot use the After_Journal qualifier to create fixed-size
.aij files; use the Aij_Options qualifier.
4.4 – Aij Options
Aij_Options=journal-opts
Noaij_Options
Specifies how RMU Restore 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 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
restored database, they will be fixed-size .aij files (as long
as at least two .aij files are always available). Depending on
what is specified in the options file, after-image journaling
can either be disabled or enabled.
o If you specify the Aij_Options qualifier, but do not provide
a journal-opts file, RMU Restore disables journaling and does
not create any new .aij files.
o If you specify the Noaij_Options qualifier, RMU Restore
reuses the original .aij file configuration and recovers the
journaling state (enabled or disabled) from the backed-up .aij
file.
o If you do not specify an After_Journal, Noafter_Journal, Aij_
Options, or Noaij_Options qualifier, RMU Restore recovers the
journaling state (enabled or disabled) and tries to reuse the
.aij file or files. (This is the same as specifying the Noaij_
Options qualifier.)
See the Description help entry under this command for details
on when automatic .aij file recovery is not attempted.
The Aij_Options qualifier conflicts with the Area and Incremental
qualifiers; you cannot specify the Aij_Options qualifier and
either of these two other qualifiers in the same RMU Restore
command line.
If the original database is lost or corrupted but the journal
files are unaffected, you would typically restore the database
without the use of either the Aij_Options or the After_Journal
qualifier.
See Show After_Journal for information on the format of a
journal-opts-file.
4.5 – Area
Area
Specifies that only the storage areas listed in the storage-area-
name parameter on the command line or in the Options file are
to be restored. You can use this qualifier to simplify physical
restructuring of a large database.
By default, the Area qualifier is not specified. When the Area
qualifier is not specified, all the storage areas and the
database root (.rdb) file are restored. Therefore, if you want
to restore all the storage areas, omit the Area qualifier. If
you specify the Area qualifier, a valid database root must exist.
(First issue the RMU Restore Only Root command with a full backup
file to create a valid database if one does not exist.)
By using the RMU Backup and RMU Restore commands, you can back up
and restore selected storage areas of your database. This Oracle
RMU backup- and restore-by-area feature is designed to:
o Speed recovery when corruption occurs in some (not all) of the
storage areas of your database.
o Reduce the time needed to perform backup operations because
some data (data in read-only storage areas, for example) does
not need to be backed up with every backup operation performed
on the database.
NOTE
When you perform a by-area restore operation, an area may
be marked as inconsistent; that is, the area may not be at
the same transaction state as the database root when the
restore operation completes. This may happen, for example,
when automatic aij recovery is disabled with the Norecovery
qualifier, or if automatic recovery fails. You can check
to see if an area is consistent by using the RMU Show
Corrupt_Pages command. If you find that one or more areas
are inconsistent, use the RMU Recover command to apply the
.aij files. If the .aij files are not available, refer to
the section on Clearing an Inconsistent Flag in the Oracle
Rdb Guide to Database Maintenance for information on the
implications of setting a corrupt area to consistent. Then
refer to Set Corrupt_Pages for information on using the Set
Corrupt_Pages command to clear the inconsistent flag.
If you attempt to restore a database area that is not in the
backup file, you receive an error message and, typically, the
database will be inconsistent or unusable until the affected area
is properly restored.
In the following example, the DEPARTMENTS storage area is
excluded from the backup operation; therefore, a warning message
is displayed when the attempt is made to restore DEPARTMENTS,
which is not in the backup file. Note that when this restore
operation is attempted on a usable database, it completes, but
the DEPARTMENTS storage area is now inconsistent.
$ RMU/BACKUP /EXCLUDE=DEPARTMENTS MF_PERSONNEL.RDB -
_$ PERS_BACKUP5JAN88.RBF
$ RMU/RESTORE /NEW_VERSION /AREA PERS_BACKUP5JAN88.RBF DEPARTMENTS
%RMU-W-AREAEXCL, The backup does not contain the storage
area - DEPARTMENTS
If you create a backup file by using the RMU Backup command and
the Exclude qualifier, it is your responsibility to ensure that
all areas of a database are restored and recovered when you
use the RMU Restore and RMU Recover commands to duplicate the
database.
The Area qualifier conflicts with the After_Journal and Aij_
Options qualifiers.
4.6 – Cdd Integrate
Cdd_Integrate
Nocdd_Integrate
Integrates the metadata from the database root (.rdb) file into
the data dictionary (assuming the data dictionary is installed on
your system).
If you specify the Nocdd_Integrate qualifier, no integration
occurs during the restore operation.
You might want to delay integration of the database metadata with
the data dictionary until after the restore operation finishes
successfully.
You can use the Nocdd_Integrate qualifier even if the DICTIONARY
IS REQUIRED clause was used when the database was defined.
The Cdd_Integrate qualifier integrates definitions in one
direction only-from the database file to the dictionary. The
Cdd_Integrate qualifier does not integrate definitions from the
dictionary to the database file.
4.7 – Close Wait
Close_Wait=n
Specifies a wait time of n minutes before RMU Restore
automatically closes the database. You must supply a value for
n.
In order to use this qualifier, the Open_Mode qualifier on the
RMU Restore command line must be set to Automatic.
4.8 – Commit
Commit
NoCommit
Instructs Oracle RMU to commit the converted database to the
current version of Oracle Rdb before completing the restore
operation. Use this qualifier only when the backup file being
restored is from a previous version of Oracle Rdb. The conversion
is permanent and the database cannot be returned to the previous
version. The NoCommit qualifier instructs Oracle RMU not to
commit the converted database. In this case, you can rollback the
database to its original version using the RMU Convert command
with the Rollback qualifier, or you can permanently commit it to
the current version by issuing the RMU Convert command with the
Commit qualifier. It is important to either Commit or Rollback
the conversion after you have verified that the conversion
was successful otherwise unnecessary space is taken up in the
database to store the obsolete alternate version of the metadata.
(RMU will not let you convert to a newer version if the previous
Convert was never committed, even if it was years ago.)
The Commit qualifier is the default.
4.9 – Confirm
Confirm
Noconfirm
Specifies that RMU Restore notify you of the name of the database
on which you are performing the incremental restore operation.
You can thus be sure that you have specified the correct .rdb
file name to which the incremental backup file will be applied.
This is the default for interactive processing.
Confirmation is especially important on an incremental restore
operation if you have changed the .rdb file name or created a new
version of the database during a restore operation from the full
backup file. (You must specify the Root qualifier also to create
new version or change the .rdb file name.)
Specify the Noconfirm qualifier to have RMU Restore apply the
incremental backup file to the database without prompting for
confirmation. This is the default for batch processing.
RMU Restore ignores the Confirm and Noconfirm qualifiers unless
you use the Incremental qualifier.
4.10 – Directory
Directory=directory-spec
Specifies the default destination for the restored database
files. If you specify a file name or file extension, all restored
files are given that file name or file extension. There is no
default directory specification for this qualifier. If you do not
specify the Directory qualifier, RMU Restore attempts to restore
all the database files to the directories they were in at the
time the backup file was created; if those directories no longer
exist, the restore operation fails.
See the Usage Notes for information on how this qualifier
interacts with the Root and File qualifiers and for warnings
regarding restoring database files into a directory owned by a
resource identifier.
4.11 – Disk File
Disk_File[=(Reader_Threads=integer)]
Specifies that you want to perform a multithreaded restore
operation from disk files, floppy disks, or other disks external
to the PC. This qualifier must have been specified on the RMU
Backup command when the backup files from which you are restoring
were created.
The Reader_Threads keyword specifies the number of threads that
Oracle RMU should use when performing a multithreaded restore
operation from disk files. You can specify no more than one
reader thread per device specified on the command line (or in the
command parameter options file). By default, one reader thread is
used.
This qualifier and all qualifiers that control tape operations
(Label, Loader_Synchronization, Master, Media_Loader, and Rewind)
are mutually exclusive.
4.12 – Duplicate
Duplicate
Noduplicate
Specifies a new database with the same content but different
identity from that of the original database. The default is the
Noduplicate qualifier.
The Duplicate qualifier creates a copy of your database that is
not expected to remain in sequence with the original database.
Note that you cannot interchange after-image journal (.aij) files
between the original and duplicate copy of the database because
each database is unique.
You can create a duplicate database when you use the Duplicate
qualifier or create the original database again when you use the
Noduplicate qualifier.
The Duplicate qualifier conflicts with the Incremental, Area, and
Online qualifiers.
4.13 – Encrypt
Encrypt=({Value=|Name=}[,Algorithm=])
The Encrypt qualifier decrypts the save set file of a database
backup.
Specify a key value as a string or, the name of a predefined
key. If no algorithm name is specified the default is DESCBC.
For details on the Value, Name and Algorithm parameters see HELP
ENCRYPT.
This feature requires the OpenVMS Encrypt product to be installed
and licensed on this system.
4.14 – Global Buffers
Global_Buffers=global-buffer-options
Allows you to change the default global buffer parameters when
you restore a database. The following options are available:
o Disabled
Use this option to disable global buffering for the database
being restored.
o Enabled
Use this option to enable global buffering for the database
being restored. You cannot specify both the Global_
Buffers=Disabled and Global_Buffers=Enabled qualifiers in
the same RMU Restore command.
o Total=total-buffers
Use this option to specify the number of buffers available for
all users. The minimum value you can specify is 2; the maximum
value you can specify is the global buffer count stored in the
.rdb file.
o User_Limit=buffers-per-user
Use this option to specify the maximum number of buffers
available to each user.
If you do not specify a Global_Buffers qualifier, the database
is restored with the values that were in effect when the database
was backed up.
When you specify two or more options with the Global_Buffers
qualifier, use a comma to separate each option and enclose the
list of options within parentheses.
4.15 – Incremental
The Incremental qualifier restores a database from an incremental
backup file.
Use the Incremental qualifier only when you have first issued an
RMU Restore command that names the full backup file that was the
basis for this incremental backup file. Each incremental backup
file is tied to a particular full backup file.
After restoring both the full and the incremental backup files,
you have restored the database to the condition it was in when
you performed the incremental database backup operation.
By default, RMU Restore performs a full restore operation on the
backup file.
You cannot specify the After_Journal or Just_Corrupt qualifier
with the Incremental qualifier.
4.16 – Journal
Journal=file-name
Allows you to specify a journal file to be used to improve tape
performance by a restore operation (including a by-area or just-
corrupt restore operation).
The backup operation creates the journal file and writes to it
a description of the backup operation. This description contains
identification of the tape drives, the tape volumes and their
contents. The Journal qualifier directs RMU Restore to read the
journal file and select only the useful tape volumes.
The journal file must be the one created at the time the backup
operation was performed. If the wrong journal file is supplied,
RMU Restore returns an informational message and does not use the
specified journal file to select the volumes to be processed.
If you omit the Label qualifier, the restore operation creates a
list of volume labels from the contents of the journal file.
A by-area restore operation also constructs a list of useful
tape volume labels from the journal file; only those volumes are
mounted and processed.
4.17 – 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 command should be the same Label qualifier
you specified with the RMU Backup command that backed up your
database.
You can use the Label qualifier with indirect file references.
See the Indirect-Command-Files help entry for more information.
4.18 – 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 Reader_Threads=n
Use the Reader_Threads option to specify the number of backup
data streams to read from the Librarian utility. The value of
n can be from 1 to 99. The default is one reader thread. The
streams are named BACKUP_FILENAME.EXT, BACKUP_FILENAME.EXT02,
BACKUP_FILENAME.EXT03, up to BACKUP_FILENAME.EXT99. BACKUP_
FILENAME.EXT is the backup file name specified in the RMU
Backup command.
The number of reader threads specified for a database restore
from the Librarian utility should be equal to or less than the
number of writer threads specified for the database backup.
If the number of reader threads exceeds the number of writer
threads, the number of reader threads is set by Oracle RMU
to be equal to the number of data streams actually stored
in the Librarian utility by the backup. If the number of
reader threads specified for the restore is less than the
number of writer threads specified for the backup, Oracle RMU
will partition the data streams among the specified reader
threads so that all data streams representing the database are
restored.
The Volumes qualifier cannot be used with the Librarian
qualifer. Oracle RMU sets the volume number to be the actual
number of data streams stored in the specified Librarian
utility.
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. For a parallel RMU backup, define RMU$LIBRARIAN_
PATH as a system-wide logical name so that the multiple
processes created by a parallel backup can all translate the
logical.
$ DEFINE /SYSTEM /EXECUTIVE_MODE -
_$ RMU$LIBRARIAN_PATH librarian_shareable_image.exe
o RMU$DEBUG_SBT
This logical name is not required. If it is defined, Oracle
RMU will display debug tracing information messages from
modules that make calls to the Librarian shareable image.
For a parallel RMU backup, the RMU$DEBUG_SBT logical should
be defined as a system logical so that the multiple processes
created by a parallel backup can all translate the logical.
The following lines are from a backup plan file created by the
RMU Backup/Parallel/Librarian command:
Backup File = MF_PERSONNEL.RBF
Style = Librarian
Librarian_trace_level = #
Librarian_logical_names = (-
logical_name_1=equivalence_value_1, -
logical_name_2=equivalence_value_2)
Writer_threads = #
The "Style = Librarian" entry specifies that the backup is going
to a Librarian utility. The "Librarian_logical_names" entry is
a list of logical names and their equivalence values. This is an
optional parameter provided so that any logical names used by a
particular Librarian utility can be defined as process logical
names before the backup or restore operation begins. For example,
some Librarian utilities provide support for logical names for
specifying catalogs or debugging.
You cannot use device specific qualifiers such as Rewind,
Density, or Label with the Librarian qualifier because the
Librarian utility handles the storage meda, not Oracle RMU.
4.19 – Loader Synchronization
Loader_Synchronization
Allows you to preload tapes in order to minimize the need for
operator support. When you specify the Loader_Synchronization
qualifier and specify multiple tape drives, the restore operation
reads from the first set of tape volumes concurrently, then waits
until all concurrent tape operations conclude before assigning
the next set of tape volumes. This ensures that the tapes can be
loaded into the loaders or stackers in the order required by the
restore operation.
The Loader_Synchronization qualifier does result in reduced
performance. For maximal performance, no drive should remain
idle, and the next identified volume should be placed on the
first drive that becomes idle. However, because the order in
which the drives become idle depends on many uncontrollable
factors and cannot be predetermined, the drives cannot be
preloaded with tapes.
Because the cost of using the Loader_Synchronization qualifier is
dependent on the hardware configuration and the system load, the
cost is unpredictable. A 5% to 20% additional elapsed time for
the operation is typical. You must determine whether the benefit
of a lower level of operator support compensates for the loss of
performance. The Loader_Synchronization qualifier is most useful
for large restore operations.
The Loader_Synchronization qualifier has no effect unless you
specify the Volumes qualifier also.
4.20 – Local Buffers
Local_Buffers=local-buffer-options
Allows you to change the default local buffer parameters when you
restore a database. The following options are available:
o Number=number-buffers
Use this option to specify the number of local buffers
available for all users. You must specify a number between
2 and 32,767 for the number-buffers parameter.
o Size=buffer-blocks
The size (in blocks) for each buffer. You must specify a
number between 2 and 64 for the buffer-blocks parameter.
If you specify a value smaller than the size of the largest
page defined, RMU Restore automatically adjusts the size of
the buffer to hold the largest page defined. For example, if
you specify the Local_Buffers=Size=8 qualifier and the largest
page size for the storage areas in your database is 64 blocks,
RMU Restore automatically interprets the Local_Buffers=Size=8
qualifier as though it were a Local_Buffers=Size=64 qualifier.
The value you specify for the Size option determines the
number of blocks for each buffer, regardless of whether local
buffering or global buffering is enabled for the database.
If you do not specify a Local_Buffers qualifier, the database is
restored with the values that were in effect when the database
was backed up.
4.21 – Log
Log
Log=Brief
Log=Full
Nolog
Specifies whether the processing of the command is reported
to SYS$OUTPUT. Specify the Log qualifier to request that the
progress of the restore operation be written to SYS$OUTPUT,
or the Nolog qualifier to suppress this report. If you specify
the Log=Brief option, which is the default if you use the Log
option without a qualifier, the log contains the start and
completion time of each storage area. If you specify the Log=Full
option, the log also contains thread assignment and storage area
statistics messages.
If you do not specify the Log or the Nolog qualifier, the default
is the current setting of the DCL verify switch. (The DCL SET
VERIFY command controls the DCL verify switch.)
4.22 – Master
Master
Allows you to explicitly state how drives should be used when
they are to be accessed concurrently. This is a positional
qualifier that designates a tape drive as a master tape drive.
When the Master qualifier is used, it must be used on the first
drive specified. All additional drives become slaves to that
master until the end of the command line, or until the next
Master qualifier, whichever comes first.
If the Master qualifier is used on a drive that does not have
an independent I/O path (not a hardware master), performance
decreases.
If the Master qualifier is not used, and concurrent tape access
is requested (using the Volumes=n qualifier), RMU Restore uses
the same automatic configuration procedure it employs with the
backup operation to select the master drives.
Using the Master qualifier is an error if you do not specify
concurrent tape access (you do not specify the Volumes=n
qualifier). See the description of the Volumes qualifier for
further information on specifying concurrent tape access.
4.23 – Media Loader
Media_Loader
Nomedia_Loader
Use the Media_Loader qualifier to specify that the tape device
from which RMU Restore is reading the backup file has a loader
or stacker. Use the Nomedia_Loader qualifier to specify that the
tape device does not have a loader or stacker.
By default, if a tape device has a loader or stacker, RMU Restore
should recognize this fact. However, occasionally RMU Restore
does not recognize that a tape device has a loader or stacker.
Therefore, after reading the first tape, RMU Restore 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 behaves as though a tape device has a loader or
stacker when actually it does not.
If you find that RMU Restore is not recognizing that your
tape device has a loader or stacker, specify the Media_Loader
qualifier. If you find that RMU Restore expects a loader or
stacker when it should not, specify the Nomedia_Loader qualifier.
4.24 – New Version
New_Version
Nonew_Version
Specifies whether new versions of database files should be
produced if the destination device and directory contain a
previous version of the database files.
If you use the New_Version qualifier, the new database file
versions are produced. The New_Version qualifier conflicts with
the Incremental qualifier.
If you use the Nonew_Version qualifier, the default, an error
occurs if an old copy exists of any of the database files being
restored.
A restore operation that creates a new database root (.rdb) file
must always either disable after-image journaling or create a
new .aij file. Attempting to use a pre-existing .aij file with a
restored database corrupts the journal and makes future recovery
from .aij files impossible. The New_Version qualifier cannot and
does not apply to the .aij file.
4.25 – 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 accepts 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.
You cannot specify the Nodes_Max qualifier if you use the
Incremental or Area qualifier.
4.26 – Online
Online
Noonline
Specifies that the restore operation be performed while other
users are attached to the database. You can specify the online
qualifier only with the Area or Just_Corrupt qualifier. The pages
to be restored are locked for exclusive access, so the operation
is not compatible with any other use of the data in the specified
pages.
The default is the Noonline qualifier.
4.27 – Open Mode
Open_Mode=Automatic
Open_Mode=Manual
Allows you to change the mode for opening a database when you
restore that database. When you specify Open_Mode=Automatic,
users can invoke the database immediately after it is restored.
If you specify Open_Mode=Manual, an RMU Open command must be used
to open the database before users can invoke the database.
The Open_Mode qualifier also specifies the mode for closing a
database. If you specify Open_Mode=Automatic, you can also use
the Close_Wait qualifier to specify a time in minutes before the
database is automatically closed.
If you do not specify the Open_Mode qualifier, the database is
restored with the open mode of the database that was in effect
when the database was backed up.
4.28 – 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 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. You can include any or all of the area
qualifiers in the options file. (See the format help entry under
this command for the list of Area qualifiers.) You can use the
DCL line continuation character, a hyphen (-), or the comment
character (!) in the options file. The default file extension is
.opt.
4.29 – Page Buffers
Page_Buffers=number-buffers
Specifies the maximum number of buffers Oracle Rdb uses during
the RMU Restore operation while the database files are being
created. The value of the Page_Buffers qualifier can range from
1 to 5. The default is 3 buffers. Values larger than 3 might
improve performance, especially during incremental restore
operations.
When RMU Restore enters the stage of reconstructing internal
structures at the end of the restore operation, a high value
for the Page_Buffers qualifier can be useful for very large
databases. However, the cost of using these extra buffers is
that memory use is high. Thus, the trade-off during a restore
operation is memory use against performance.
4.30 – Path
Path=cdd-path
Specifies a data dictionary path into which the database
definitions be integrated. If you do not specify the Path
qualifier, RMU Restore uses the CDD$DEFAULT logical name value
of the user who entered the RMU Restore command.
If you specify a relative path name, Oracle Rdb appends the
relative path name you enter to the CDD$DEFAULT value. If the
cdd-path parameter contains nonalphanumeric characters, you must
enclose it within quotation marks ("").
Oracle Rdb ignores the Path qualifier if you use the Nocdd_
Integrate qualifier or if the data dictionary is not installed
on your system.
4.31 – 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.32 – Recovery
Recovery[=Aij_Buffers=n]
Norecovery
The Recovery=Aij_Buffers=n qualifier allows you to specify the
number of recovery buffers to use during an automatic recovery.
The default value of n is 100 recovery buffers.
The Recovery qualifier explicitly specifies that RMU Restore
should attempt an automatic recovery of the .aij files during the
restore operation.
Specify either the Recover=Aij_Buffers=n qualifier and the
Recovery qualifier only if .aij files are being retained. If
you specify either qualifier in a situation where .aij files
are not retained (the Aij_Options, After_Journal, or Duplicate
qualifier has been specified), a warning message is displayed and
RMU Restore performs the restore operation without attempting to
recover the .aij files.
The Norecovery qualifier specifies that RMU Restore should not
attempt an automatic recovery of the .aij files during the
restore operation. Specify this qualifier if you want to use
the RMU Recover command with the Until qualifier or if you intend
to perform an incremental restore operation.
4.33 – Rewind
Rewind
Norewind
Specifies that 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 returns an error message if you use these
qualifiers and the target device is not a tape device.
4.34 – Root
Root=root-file-spec
Specifies the database root (.rdb) file specification of the
restored database. 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.35 – Transaction Mode
Transaction_Mode=(mode-list)
Sets the allowable transaction modes for the database root
file restored by the restore operation. The primary use of
this qualifier is when you restore a backup file (of a master
database) to create a Hot Standby database. Because only read-
only transactions are allowed on a standby database, you should
use the Transaction_Mode=Read_Only qualifier setting. This
setting prevents modifications to the standby database at all
times, even when replication operations are not active. For more
information on Hot Standby see the Oracle Rdb7 and Oracle CODASYL
DBMS: Guide to Hot Standby Databases. 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
Your restore operation must include the database root file.
Otherwise, RMU Restore returns the CONFLSWIT error when you issue
an RMU Restore command with the Transaction_Mode qualifier.
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, it indicates
that a mode is not an allowable access mode. For example, if
you specify the Noexclusive_Write access mode, it indicates
that exclusive write is not an allowable access mode for the
restored 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.36 – 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.
You cannot specify the Users_Max qualifier if you use the
Incremental qualifier or the Area qualifier.
4.37 – Volumes
Volumes = n
Allows you to specify that concurrent tape access is to be used
to accelerate the restore operation.
The Volumes qualifier indicates concurrent tape access and
specifies the number of tape volumes in the backup file. The
number of volumes must be specified accurately for the restore
operation to complete.
If you are restoring from a multidisk backup file, the value of
"n" indicates the number of disk devices containing backup files
needed for the restore operation.
If you do not specify the Volumes qualifier, the restore
operation does not use concurrent tape access.
4.38 – Blocks Per Page
Blocks_Per_Page=integer
Lets you restore a database with larger mixed page sizes than
existed in the original database. This creates new free space on
each page in the storage area file and does not interfere with
record clustering. RMU Restore ignores this qualifier when it
specifies an integer less than or equal to the current page size
of the area.
You might want to increase the page size in storage areas
containing hash indexes that are close to full. By increasing
the page size in such a situation, you prevent the storage area
from extending.
4.39 – Extension
Extension=Disable
Extension=Enable
Allows you to change the automatic file extension attribute
when you restore a database. These qualifiers are positional
qualifiers.
Use the Extension=Disable qualifier to disable automatic file
extension for a storage area.
Use the Extension=Enable qualifier to enable automatic file
extension for a storage area.
If you do not specify the Extension=Disable or Extension=Enable
qualifier, the storage areas are restored with the automatic file
extension attributes that were in effect when the database was
backed up.
4.40 – File
File=file-spec
Requests that the storage area to which this qualifier is applied
be restored in the specified location.
This qualifier is not valid for single-file databases. This is a
positional qualifier.
See the Usage Notes for information on how this qualifier
interacts with the Root, Directory, and Snapshot qualifiers and
for warnings regarding restoring database files into a directory
owned by a resource identifier.
4.41 – Just Corrupt
Just_Corrupt
This qualifier replaces the Just_Pages qualifier beginning in
Oracle Rdb V7.0.
Allows you to restore the corrupt pages and areas in the
database as recorded in the corrupt page table (CPT). The CPT
is maintained in the .rdb file. (Note that if the corrupt page
table becomes full, the area with the highest number of corrupt
pages is marked corrupt and the individual pages for that area
are removed from the CPT.)
Often, only one or a few pages in the database are corrupted
due to hardware or software faults. The Just_Corrupt qualifier
allows you to recover that database in minimal time with minimal
interference; availability of the uncorrupted data is unaffected.
It allows you to restrict the restoration to the pages (or areas)
logged as corrupt in the corrupt page table.
The Just_Corrupt qualifier is a positional qualifier. If you use
it in the global position, RMU Restore restores all the corrupt
pages and all the corrupt areas as logged in the corrupt page
table. If you use it in the local position, RMU Restore restores
only the corrupt pages (or the entire area) of the area name it
modifies.
It is possible to mix restoration of complete areas and just
corrupt pages in the same command. The following example restores
all of AREA_1 (regardless of whether or not it is corrupt), but
just the corrupt pages (logged to the CPT) in AREA_2.
$ RMU/RESTORE/AREA backup_file AREA_1, AREA_2/JUST_CORRUPT
Note that when the Just_Corrupt qualifier is used globally, all
the corrupt pages logged to the CPT for the areas specified
are restored. For example, the following command restores all
the corrupt pages logged to the CPT for AREA_1 and AREA_2.
(However, if one of the areas specified contains no corruptions,
an informational message is displayed and that area is not
restored.)
$ RMU/RESTORE/JUST_CORRUPT backup_file /AREA AREA_1, AREA_2
Restoration of corrupt pages and area can be performed on line.
Online operations lock only the corrupt pages or areas for the
duration of the restore operation. The remainder of the storage
area can be read or updated by an application. When an entire
area is restored on line, applications are locked out of the
entire area for the duration of the restore operation.
There are some restrictions on the use of the Just_Corrupt
qualifier:
o The backup file must be a full backup file that contains the
selected area.
o When space area management (SPAM) pages are restored, RMU
Restore rebuilds the SPAM page using information from the
range of data pages that the SPAM page manages.
o Area bit map (ABM) pages can be restored, but their content
is not reconstructed. If ABM pages have been corrupted,
regenerate them with the RMU Repair command.
o A by-page restore operation is like a by-area restore
operation in that after-image journal (AIJ) recovery is
required to make the restored data consistent with the rest
of the database.
Once the pages are restored, access to these restored pages is
prohibited until they are made consistent. Inconsistent pages
are stored in the corrupt page table (CPT) and have their
timestamp field flagged by Oracle Rdb.
o You can also use the Just_Corrupt qualifier in a restore
options file. However, you cannot use any of the following
qualifiers with the Just_Corrupt qualifier (neither within an
options file nor on the command line):
- Blocks_Per_Page
- Extension
- File
- Incremental
- Read_Only
- Read_Write
- Snapshot
- Spams
- Thresholds
You can use the Just_Corrupt qualifier in conjunction with
the Journal=file qualifier to greatly speed up processing of
a large tape backup file. When you use the Journal qualifier,
only those tapes containing corrupt pages, areas, or both, are
mounted and processed.
4.42 – Just Pages
Just_Pages[=(p1,p2,...)]
This qualifier is replaced with the Just_Corrupt qualifier
beginning in Oracle Rdb V7.0. See the description of the Just_
Corrupt qualifier.
4.43 – Read Only
Use the Read_Only qualifier to change a read/write storage area
or a write-once storage area to a read-only storage area.
If you do not specify the Read_Only or the Read_Write qualifier,
the storage areas are restored with the read/write attributes
that were in effect when the database was backed up.
This is a positional qualifier.
4.44 – Read Write
Use the Read_Write qualifier to change a read-only storage area
or a write-once storage area to a read/write storage area.
If you do not specify the Read_Only or the Read_Write qualifier,
the storage areas are restored with the read/write attributes
that were in effect when the database was backed up.
This is a positional qualifier.
4.45 – Snapshot
Snapshot=(Allocation=n,File=file-spec)
If you specify the Allocation parameter, specifies the snapshot
file allocation size in n pages for a restored area. If you
specify the File parameter, specifies a new snapshot file
location for the restored storage area to which it is applied.
You can specify the Allocation parameter only, the File parameter
only, or both parameters; however, if you specify the Snapshots
qualifier, you must specify at least one parameter.
This is one of the commands used to alter the parameters of the
restored database from those defined at the time of the database
backup. Others are /DIRECTORY, /ROOT and /FILE.
See the Usage Notes for information on how this qualifier
interacts with the Root, File, and Directory qualifiers.
The Shapshot qualifier is a positional qualifier. It can be used
locally or globally, depending on where the qualifier is placed
on the command line. See Examples 22 and 23.
To save read/write disk space, you can specify that less space be
allocated for the storage area's .snp file when it remains as a
read/write file on a read/write disk. If the keyword Allocation
is omitted, the original allocation is used. This qualifier is
not valid for single-file databases.
You cannot specify an .snp file name for a single-file database.
When you create an .snp file for a single-file database, Oracle
Rdb does not store the file specification of the .snp file.
Instead, it uses the file specification of the database root
(.rdb) file to determine the file specification of the .snp file.
If you want to place the .snp file on a different device or
directory, Oracle Corporation recommends that you create a
multifile database. However, you can work around the restriction
by defining a search list for a concealed logical name. (However,
do not use a nonconcealed rooted logical name to define database
files; a database created with a non-concealed rooted logical
name can be backed up, but may not restore correctly when you
attempt to restore the files to a new directory.)
To create a database with an .snp file on a different device
or directory, define a search list by using a concealed logical
name. Specify the location of the root file as the first item in
the search list. When you create the database, use the logical
name for the directory specification. Then, copy the .snp file
to the second device. The following example demonstrates the
workaround:
$ ! Define a concealed logical name.
$ DEFINE /TRANS=CONCEALED/SYSTEM TESTDB USER$DISK1:[DATABASE], -
_$ USER$DISK2:[SNAPSHOT]
$
$ SQL
SQL> -- Create the database.
SQL> --
SQL> CREATE DATABASE FILENAME TESTDB:TEST;
SQL> EXIT
$ !
$ ! Copy the snapshot (.snp) file to the second disk.
$ COPY USER$DISK1:[DATABASE]TEST.SNP -
_$ USER$DISK2:[SNAPSHOT]TEST.SNP
$ !
$ ! Delete the snapshot (.snp) file from the original disk.
$ DELETE USER$DISK1:[DATABASE]TEST.SNP;
4.46 – Spams
Spams
Nospams
Enables the space area management (SPAM) pages for the specified
area. The Nospams qualifier disables the SPAM pages for the
specified area. The default is to leave the attribute unchanged.
The Spams and Nospams qualifiers are not allowed for a storage
area that has a uniform page format. This is a positional
qualifier.
4.47 – Thresholds
Thresholds=(val1[,val2[,val3]])
Specifies a storage area's fullness percentage threshold. You
can adjust SPAM thresholds to improve future space utilization in
the storage area. Each threshold value represents a percentage of
fullness on a data page. When a data page reaches the percentage
of fullness defined by a given threshold value, the space
management entry for the data page is updated to contain that
threshold value.
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
command, Oracle Rdb uses the storage area's original thresholds.
This is a positional qualifier.
See the Oracle Rdb7 Guide to Database Performance and Tuning for
more information on setting SPAM thresholds.
5 – Usage Notes
o To use the RMU Restore 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 command provides four qualifiers, Directory,
Root, File, and Snapshots, that allow you to specify the
target for the restored files. 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 four 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
target for the restored storage area or areas.
- Use local application of the Snapshots qualifier to specify
the target for the restored snapshot file or files.
- Use the Directory qualifier to specify a default target
directory. The default target directory is the directory
to which all files not qualified with the Root, File, or
Snapshot qualifier are restored. It is also the default
directory for files qualified with the Root, File, or
Snapshot qualifier if the target for these qualifiers does
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 to
restore all of the storage areas to different versions
of the same file name. This creates a database that is
difficult to manage.
- Global application of the Snapshot qualifier when the
target specification includes a file name causes RMU
Restore to restore all of the snapshot files to different
versions of the same file name. This creates a database
that is difficult to manage.
- Specifying a file name or extension with the Directory
qualifier is permitted, but causes RMU Restore to restore
all of the files (except those specified with the File
or Root qualifier) to different versions of the same file
name. Again, this creates a database that is difficult to
manage.
See Example 17.
o When you restore a database 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 If a backup file to tape is created using a single tape
device, it must be restored using a single tape device; it
cannot be restored using multiple tape devices.
NOTE
An incremental backup file created for a database running
under one version of Oracle Rdb cannot be applied if
that database has been restored under another version of
Oracle Rdb. For example, if you do the following, step 6
fails with the error message, "XVERREST, Cross version
RESTORE is not possible for by-area or incremental
functions":
1. Apply a full backup operation to a Version 7.1
database.
2. Apply updates to the database.
3. Perform an incremental backup operation on the
database.
4. Move backup files to a system running Oracle Rdb
Version 7.2.
5. Restore the database by using the full backup file.
6. Attempt to apply the incremental backup file created
in step 1.
o If you apply an incremental backup file, you must specify the
Norecovery qualifier when you issue a full RMU Restore command
for the corresponding full backup file.
o If you mistakenly attempt to restore a backup file in a
version of Oracle Rdb that is earlier than the version for
which the backup file was created, you might receive INVRECTYP
errors and your operation will probably terminate with an
access violation (ACCVIO) exception. If you receive this
error, check the version of the backup file and the version
of Oracle Rdb you are running. Be sure the environment version
matches, or is greater than, the version under which the
backup file was created.
o RMU Restore might create an .rdb file and .rda files when it
starts up. If you specify the Log qualifier, these files will
be noted in the log file. These are not database files until
the end of the operation when they have been populated with
the backed-up contents. Therefore, if the restore operation
aborts or is stopped using Ctrl/Y, you must delete these
unpopulated files by using the DCL DELETE command. You know
which files to delete by the contents of the backup file and
the form of the command issued, or by examining the output
in the log file if you specified the Log qualifier. Deleting
the files usually requires OpenVMS privileges. Until they are
restored, these files are not a database, and Oracle RMU or
SQL operations do not function with them.
o RMU Restore preserves any area reservations and after-image
journal (.aij) file reservations that exist in the backed-up
database.
o If you restore a database without its root file ACL (using the
Noacl qualifier with the RMU Restore command, for example),
a user who wants to create ACL entries for the database must
have the OpenVMS SECURITY or BYPASS privilege.
o The RMU Restore command with the Area and Online qualifiers
requires exclusive access to the area files being restored.
The RMU Restore command with the Area, Online, and Just_
Corrupt qualifiers requires exclusive access to only the pages
being restored.
o There are no restrictions on the use of the Nospams qualifier
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 The RMU Restore command automatically uses the RMU Convert
command when restoring the database to a system with a
more recent version of Oracle Rdb software. When this is
done, the metadata in the Oracle Rdb database changes and
invalidates incremental backup files from the previous
version. By default, no areas are reserved and one .aij file
is reserved. (You can override the after-image journal default
reservation by using the Aij_Options qualifier.) See Convert
for information on the versions of Oracle Rdb that the Convert
command supports.
o Always back up your Oracle Rdb databases as recommended in the
Oracle Rdb Installation and Configuration Guide just prior to
installing a newer version of Oracle Rdb software. The last
backup file made prior to converting to a more recent version
of Oracle Rdb should be a full and complete backup file.
o See the Oracle Rdb Guide to Database Maintenance for
information on the steps RMU Restore follows in tape label
checking when you restore a database from tape.
o RMU Restore might initialize the SPAM thresholds for some data
pages of some storage areas that have a uniform page format
to values that are not acceptable to the RMU Verify command.
This occurs when some of the data pages in a logical area are
restored before the logical area definition (Area Inventory).
This is not a frequent occurrence, and when it does happen,
the consequences are usually cosmetic (the RMU Verify command
issues a warning message for each page affected). However, if
many pages are affected, the volume of warnings can cause you
to overlook a real problem. Moreover, in some cases, this can
result in additional I/O operations when new data is stored in
an affected table.
As a workaround, you can use the RMU Repair command to
reconstruct the SPAM pages in one or more storage areas. The
RMU Repair command corrects the condition caused by the RMU
Restore command as well as other SPAM page corruptions. See
the help entry for the RMU Repair command for more information
on the RMU Repair command.
6 – Examples
Example 1
The following example restores the mf_personnel database from
the backup file pers_bu.rbf and requests a new version of the
database file. Because the After_Journal qualifier has been
specified, automatic recovery will not be attempted.
$ RMU/RESTORE/NEW_VERSION/AFTER_JOURNAL=AIJ_DISK:[AIJS]PERSAIJ -
_$ /NOCDD_INTEGRATE/LOG PERS_BU -
_$ EMP_INFO /THRESHOLDS=(65,75,80)/BLOCKS_PER_PAGE=3
The command changes the .aij file location and name to
AIJ_DISK:[AIJS]PERSAIJ.AIJ, prevents integration with the data
dictionary, and displays the progress of the restore operation.
For the storage area, EMP_INFO, the command changes the SPAM
threshold values to 65%, 75%, and 80%, and increases the number
of blocks per page to 3 blocks.
Example 2
Assume that at 10 A.M., Wednesday, October 25, 2005, a disk
device hardware failure corrupted all the files on the device,
including the mf_personnel.rdb file. The following command
restores the full database backup file (pers_full_oct22.rbf)
created on the previous Sunday and then restores the incremental
backup file made on Tuesday. Note that an incremental database
backup file was created on Monday, but each new incremental
backup file made since the latest full backup file replaces
previous incremental backup files made since the last full backup
operation.
$ RMU/RESTORE/LOG/NORECOVERY MUA1:PERS_FULL_OCT22.RBF
$ RMU/RESTORE/INCREMENTAL/CONFIRM/LOG/NORECOVERY -
_$ PERS_INCR_OCT24.RBF
At this point, the database is current up until 11:30 P.M.,
Tuesday, when the last incremental backup file was made of mf_
personnel. Because after-image journaling is enabled for this
database, automatic recovery of the .aij file could have been
employed. However, if the recovery process should fail for
some reason or, as in this case, the Norecovery qualifier is
specified, you can still use the RMU Recover command to apply
the .aij file that contains changes made to the database from
11:30 P.M., Tuesday, until just before the hardware failure to
the restored mf_personnel.rdb file and its storage area files.
For example:
$ RMU/RECOVER/UNTIL = "25-OCT-2005 09:55:00.00" -
_$ AIJ_DISK:[AIJS]PERSAIJ.AIJ;1
Example 3
If a storage area is on a disk that fails, you might want to
move that storage area to another disk by using the RMU Restore
command. The following RMU Restore command restores only the
EMPIDS_OVER storage area from the full backup file of mf_
personnel, and moves the EMPIDS_OVER storage area and snapshot
(.snp) file to a new location on the 333$DUA11 disk. The recovery
operation is only required if the required .aij file has been
backed up and is no longer in the current aij state.
$ RMU/RESTORE/AREA 222$DUA20:[BACKUPS]MF_PERS_BU.RBF -
_$ EMPIDS_OVER /FILE=333$DUA11:[DBS]EMPIDS_OVER.RDA -
_$ /SNAPSHOT=(FILE=333$DUA11:[DBS]EMPIDS_OVER.SNP)
$ !
$ ! Recovery from the after-image journal is automatic. If
$ ! automatic recovery is not possible, or if the Norecovery
$ ! qualifier had been specified, perform the following:
$ !
$ RMU/RECOVER/AREA AIJ_DISK:PERS.AIJ
Example 4
The following example demonstrates how you can use by-area backup
and restore operations for a single storage area in the mf_
personnel database. In addition, it demonstrates the use of the
automatic recovery feature of the RMU Restore command.
$ !
$ ! Create an .aij file for the database. Because three
$ ! .aij files are created, fixed-size .aij
$ ! 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.RDB
%RMU-W-DOFULLBCK, full database backup should be done to
ensure future recovery
$ RMU/BACKUP MF_PERSONNEL DISK3:[BACKUP]MF_PERS.RBF
$ SQL
SQL> ATTACH 'FILENAME MF_PERSONNEL';
SQL> --
SQL> -- On Monday, define 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> EXIT;
$ !
$ ! Assume that you know that the only storage area ever updated in
$ ! the mf_personnel database on Tuesdays is the SALARY_HISTORY
$ ! storage area, and you decide that you will create an incremental
$ ! backup file of just the SALARY_HISTORY storage area on Tuesday.
$ ! Before you perform the by-area backup operation on the
$ ! SALARY_HISTORY storage area on Tuesday, you must perform a full
$ ! and complete backup operation on the mf_personnel database when
$ ! it is in a known and working state.
$ !
$ RMU/BACKUP MF_PERSONNEL.RDB -
_$ DISK3:[BACKUP]MF_MONDAY_FULL.RBF
$ !
SQL> --
SQL> -- On Tuesday, two rows are updated in
SQL> -- the SALARY_HISTORY storage area.
SQL> --
SQL> UPDATE SALARY_HISTORY
cont> SET SALARY_END ='20-JUL-2003 00:00:00.00'
cont> WHERE SALARY_START='14-JAN-1993 00:00:00.00'
cont> AND EMPLOYEE_ID = '00164';
1 row updated
SQL> UPDATE SALARY_HISTORY
cont> SET SALARY_START ='5-JUL-2000 00:00:00.00'
cont> WHERE SALARY_START='5-JUL-1990 00:00:00.00'
cont> AND EMPLOYEE_ID = '00164';
1 row updated
SQL> COMMIT;
SQL> EXIT;
$ !
$ ! On Tuesday, you create an incremental backup file of the
$ ! SALARY_HISTORY storage area only. Only the SALARY_HISTORY
$ ! storage area is included in the by-area backup file.
$ ! Oracle RMU provides an informational message telling
$ ! you that not all storage areas in the database are included
$ ! in the mf_tuesday_partial.rbf backup file.
$ RMU/BACKUP/INCLUDE=(SALARY_HISTORY) -
_$ /INCREMENTAL/LOG DISK1:[USER]MF_PERSONNEL.RDB -
_$ DISK3:[BACKUPS]MF_TUESDAY_PARTIAL.RBF
%RMU-I-NOTALLARE, Not all areas will be included in
this backup file
%RMU-I-LOGLASCOM, Last full and complete backup was dated
18-JAN-2006 11:19:46.31
%RMU-I-BCKTXT_00, Backed up root file
DISK1:[DB]MF_PERSONNEL.RDB;1
%RMU-I-BCKTXT_03, Starting incremental backup of
storage area DISK3:[SA}SALARY_HISTORY.RDA;1 at
18-JAN-2006 11:20:49.29
%RMU-I-BCKTXT_13, Completed incremental backup of
storage area DISK3:[SA]SALARY_HISTORY.RDA;1 at
18-JAN-2006 11:20:49.40
%RMU-I-COMPLETED, BACKUP operation completed at
18-JSN-2006 11:20:49.59
.
.
.
$ !
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> EXIT;
$ ! Assume that a disk device hardware error occurs here
$ ! and only the SALARY_HISTORY storage area and snapshot
$ ! file is lost. Also assume that the database root (.rdb)
$ ! file and other storage areas in the database are still
$ ! fine and do not need to be restored or recovered.
$ ! Therefore, you do not need to restore the .rdb file or
$ ! other storage areas from the full and complete backup
$ ! file. Because only the SALARY_HISTORY storage area was
$ ! lost, you must do the following:
$ ! 1) Restore the SALARY_HISTORY storage area and snapshot
$ ! file from the last full and complete backup file. Note
$ ! this operation can be done on line. Specify the Norecovery
$ ! qualifier because you still have an incremental restore
$ ! operation to perform.
$ ! 2) Restore the SALARY_HISTORY storage area from the last
$ ! incremental backup file. Note this operation can be
$ ! done on line. This time do not specify the Norecovery
$ ! qualifier so that the automatic recovery provided by
$ ! Oracle RMU will be implemented.
$ !
$ RMU/RESTORE/NOCDD_INTEGRATE/ONLINE/LOG/NORECOVERY -
_$ /AREA DISK3:[BACKUP]MF_MONDAY_FULL.RBF SALARY_HISTORY
%RMU-I-RESTXT_21, Starting full restore of storage area
DISK1:[USER]SALARY_HISTORY.RDA;1 at 18-JAN-2006 11:25:13.17
%RMU-I-RESTXT_24, Completed full restore of storage area
DISK1:[USER]SALARY_HISTORY.RDA;1 at 18-JAN-2006 11:25:13.86
%RMU-I-RESTXT_01, Initialized snapshot file
DISK1:[USER]SALARY_HISTORY.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 SALARY_HISTORY starts with
AIJ file sequence 0
%RMU-I-COMPLETED, RESTORE operation completed at 18-JAN-2006 11:25:14.51
$ RMU/RESTORE/NOCDD_INTEGRATE/INCREMENTAL/ONLINE/LOG -
_$ /AREA DISK3:[BACKUPS]MF_TUESDAY_PARTIAL.RBF SALARY_HISTORY
DISK1:[USER]MF_PERSONNEL.RDB;1, restore incrementally? [N]:Y
%RMU-I-RESTXT_22, Starting incremental restore of storage area
DISK1:[USER]SALARY_HISTORY.RDA;1 at 18-JAN-2006 11:29:35.54
%RMU-I-RESTXT_25, Completed incremental restore of storage area
DISK1:[USER]SALARY_HISTORY.RDA;1 at 18-JAN-2006 11:29:35.64
%RMU-I-RESTXT_01, Initialized snapshot file
DISK1:[USER]SALARY_HISTORY.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 SALARY_HISTORY starts with
AIJ file sequence 0
%RMU-I-AIJBADAREA, inconsistent storage area
DISK1:[USER]SALARY_HISTORY.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;17
%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, 3 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 3 transactions ignored
%RMU-I-AIJSUCCES, database recovery completed successfully
Example 5
In the following example, the options file specifies that the
storage area (.rda) files are to be restored to different disks.
Note that storage area snapshot (.snp) files are restored to
different disks from one another and from their associated
storage area (.rda) files; this is recommended for optimal
performance. (This example assumes that the disks specified for
each storage area file in options_file.opt are different from
those where the storage area files currently reside.)
$ RMU/RESTORE/NOCDD_INTEGRATE/OPTIONS=OPTIONS_FILE.OPT -
_$ MF_PERS_BCK.RBF
$ TYPE OPTIONS_FILE.OPT
EMPIDS_LOW /FILE=DISK1:[CORPORATE.PERSONNEL]EMPIDS_LOW.RDA -
/SNAPSHOT=(FILE=DISK2:[CORPORATE.PERSONNEL]EMPIDS_LOW.SNP )
EMPIDS_MID /FILE=DISK3:[CORPORATE.PERSONNEL]EMPIDS_MID.RDA -
/SNAPSHOT=(FILE=DISK4:[CORPORATE.PERSONNEL]EMPIDS_MID.SNP )
EMPIDS_OVER /FILE=DISK5:[CORPORATE.PERSONNEL]EMPIDS_OVER.RDA -
/SNAPSHOT=(FILE=DISK6:[CORPORATE.PERSONNEL]EMPIDS_OVER.SNP )
DEPARTMENTS /FILE=DISK7:[CORPORATE.PERSONNEL]DEPARTMENTS.RDA -
/SNAPSHOT=(FILE=DISK8:[CORPORATE.PERSONNEL]DEPARTMENTS.SNP )
SALARY_HISTORY /FILE=DISK9:[CORPORATE.PERSONNEL]SALARY_HISTORY.RDA -
/SNAPSHOT=(FILE=DISK10:[CORPORATE.PERSONNEL]SALARY_HISTORY.SNP )
JOBS /FILE=DISK7:[CORPORATE.PERSONNEL]JOBS.RDA -
/SNAPSHOT=(FILE=DISK8:[CORPORATE.PERSONNEL]JOBS.SNP )
EMP_INFO /FILE=DISK9:[CORPORATE.PERSONNEL]EMP_INFO.RDA -
/SNAPSHOT=(FILE=DISK10:[CORPORATE.PERSONNEL]EMP_INFO.SNP )
RESUME_LISTS /FILE=DISK11:[CORPORATE.PERSONNEL]RESUME_LISTS.RDA -
/SNAPSHOT=(FILE=DISK12:[CORPORATE.PERSONNEL]RESUME_LISTS.SNP )
RESUMES /FILE=DISK9:[CORPORATE.PERSONNEL]RESUMES.RDA -
/SNAPSHOT=(FILE=DISK10:[CORPORATE.PERSONNEL]RESUMES.SNP )
Example 6
The following example shows what .aij file sequence to use
following an RMU Restore command with the Area qualifier if
automatic recovery fails:
$ RMU/RESTORE/AREA MFPERS_62691.RBF -
DEPARTMENTS, JOBS
.
.
.
%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
Example 7
The following example shows how to move a single-file database to
a new directory, using the RMU Backup and RMU Restore commands:
$ RMU/BACKUP PERSONNEL PERS
$!
$ RMU/RESTORE/NOCDD/NOAFTER_JOURNAL -
_$ /DIRECTORY=DISK4:[USER2] PERS
Example 8
The following example shows how to rename a single-file database
when you move the database by using the RMU Backup and RMU
Restore commands:
$ RMU/BACKUP PERSONNEL PERS
$!
$ RMU/RESTORE/NOCDD/NOAFTER_JOURNAL -
_$ /DIRECTORY=DISK4:[USER2]TEST_PERSONNEL PERS
Example 9
The following example causes the database being restored from
the mf_pers_bck.rbf backup file to have 60 global buffers, with
a limit of 2 buffers for each database user. Because the Enabled
option is used, global buffering is in effect for the database
immediately after it is restored:
$ RMU/RESTORE/NOCDD/GLOBAL_BUFFERS=(ENABLED,TOTAL=60,USER_LIMIT=2) -
_$ MF_PERS_BCK.RBF
Example 10
The following command causes the SALARY_HISTORY storage area
from the database being restored from the mf_pers_bu.rbf backup
file to be restored as a read-only storage area. None of the
other database storage areas are modified as part of this restore
operation.
$ RMU/RESTORE/NOCDD MF_PERS_BU.RBF SALARY_HISTORY /READ_ONLY
Example 11
The following example assumes that you are using multiple tape
drives to perform a large restore operation. By specifying the
Loader_Synchronization and Volumes qualifiers, this command does
not require you to load tapes as each completes. Instead, you
can load tapes on a loader or stacker and the RMU restore process
will wait until all concurrent tape operations have concluded
for one set of tape volumes before assigning the next set of tape
volumes. This example assumes that the backup operation used two
tape output threads and each thread wrote four tapes.
This example uses Master qualifiers to indicate that you want the
$111$MUA0: and $444$MUA2: drives to be master drives.
Using this example, you would:
1. Allocate each tape drive.
2. Manually place tapes BACK01 and BACK05 on the $111$MUA0:
master drive.
3. Manually place tapes BACK02 and BACK06 on the $333$MUA2:
master drive.
4. Manually place tapes BACK03 and BACK07 on the $222$MUA1: slave
drive.
5. Manually place tapes BACK04 and BACK08 on the $444$MUA3: slave
drive.
6. Mount the first volume (BACK01).
7. Perform the restore operation.
8. Dismount the last tape mounted.
9. Deallocate each tape drive.
$ ALLOCATE $111$MUA0:
$ ALLOCATE $222$MUA1:
$ ALLOCATE $333$MUA2:
$ ALLOCATE $444$MUA3:
$
$ MOUNT/FOREIGN $111$MUA0:
$
$ RMU/RESTORE/LOG/REWIND/LOADER_SYNCHRONIZATION -
_$ /LABEL=(BACK01, BACK02, BACK03, BACK04, BACK05, -
_$ BACK06, BACK07, BACK08) -
_$ /VOLUMES=8 -
_$ $111$MUA0:PERS_FULL_MAR30.RBF/MASTER, $222$MUA1: -
_$ $333$MUA2:/MASTER, $444$MUA3
$
$ DISMOUNT $222$MUA3:
$
$ DEALLOCATE $111$MUA0:
$ DEALLOCATE $222$MUA1:
$ DEALLOCATE $333$MUA2:
$ DEALLOCATE $444$MUA3:
Example 12
The following example demonstrates the automatic .aij recovery
mechanism in the RMU Restore command. The example does the
following:
o Uses the RMU Set After_Journal command to reserve space for
four .aij files, adds three .aij files, and enables after-
image journaling
o Performs a backup operation on the database
o Performs database update activity, which will be written to an
.aij file
o Determines the database root file is lost
o Restores and recovers the database in one RMU Restore command
$ SET DEFAULT DISK1:[USER]
$ !
$ 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
$ !
$ ! Back up database, as instructed.
$ !
$ RMU/BACKUP MF_PERSONNEL DISK3:[BACKUPS]MF_PERS.RBF
$ !
$ ! Database update activity occurs.
$ !
$!
$! Database is lost. Issue the RMU Restore command to
$! restore and recover the database. Because the Norecovery
$! qualifier is not specified, Oracle RMU will
$! automatically attempt to recover the database.
$!
$ RMU/RESTORE DISK3:[BACKUPS]MF_PERS.RBF/NOCDD_INTEGRATE
%RMU-I-AIJRSTAVL, 3 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
DISK1:[USER]MF_PERSONNEL.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 13
The following example demonstrates how to restore and recover all
the corrupt pages and areas in the mf_personnel database. Assume
that the RMU Show Corrupt_Pages command shows that the JOBS
storage area is corrupt and that only page 3 in the DEPARTMENTS
storage area is corrupt. All the other storage areas are neither
corrupt nor inconsistent. Because the Just_Corrupt qualifier is
specified in the global position, and mf_personnel.rbf is a full
backup file, the RMU restore process restores all of the JOBS
storage area and just page 3 in the DEPARTMENTS storage area.
If after-image journaling is enabled, automatic recovery will be
attempted.
$ RMU/RESTORE/AREA/JUST_CORRUPT MF_PERSONNEL.RBF
Example 14
The following example demonstrates how to restore and recover
specific corruptions in the mf_personnel database. Like example
12, assume that the RMU Show Corrupt_Pages command shows that
the JOBS storage area is corrupt and that only page 3 in the
DEPARTMENTS storage area is corrupt. All the other storage
areas are neither corrupt nor inconsistent. The backup file,
mf_partial.rbf, is a by-area backup file containing backups of
the JOBS, DEPARTMENTS, and SALARY_HISTORY storage areas. In this
example, the JOBS, DEPARTMENTS, and SALARY_HISTORY areas are
specified for restoring. Because the SALARY_HISTORY area contains
no corruptions, an informational message is returned. The RMU
restore process restores all of the JOBS storage area and just
page 3 in the DEPARTMENTS storage area. If after-image journaling
is enabled, automatic recovery will be attempted.
$ RMU/RESTORE/JUST_CORRUPT/AREA MF_PARTIAL.RBF JOBS, -
_$ DEPARTMENTS,SALARY_HISTORY
%RMU-I-RESTXT_20, Storage area DISK1:[AREA]SALARY_HISTORY.RDA;1 is not
corrupt and will not be restored
Example 15
The following example demonstrates how to restore and recover
specific corruptions in the mf_personnel database along with
restoring an area that is not corrupt. Like example 13, assume
that the RMU Show Corrupt_Pages command shows that the JOBS
storage area is corrupt and that only page 3 in the DEPARTMENTS
storage area is corrupt. All the other storage areas are neither
corrupt nor inconsistent. The backup file, mf_personnel.rbf, is a
full backup file. In this example, the Just_Corrupt qualifier is
used locally with the DEPARTMENTS storage area.
The JOBS, DEPARTMENTS, and SALARY_HISTORY areas are specified
for restoring. Although the SALARY_HISTORY area contains no
corruptions, an informational message is not returned in this
case because by specifying the Just_Corrupt qualifier locally
with DEPARTMENTS, the Restore command is requesting that the RMU
restore process restore the JOBS and SALARY_HISTORY storage areas
regardless of corruptions, and the DEPARTMENTS storage area be
restored to fix corruptions. The RMU restore process restores
all of the JOBS and SALARY_HISTORY storage areas and just page
3 in the DEPARTMENTS storage area. If after-image journaling is
enabled, automatic recovery will be attempted.
$ RMU/RESTORE/AREA MF_PERSONNEL.RBF JOBS, SALARY_HISTORY, -
_$ DEPARTMENTS/JUST_CORRUPT
Example 16
The following example is the same as example 15, except the Just_
Corrupt qualifier is specified locally with the SALARY_HISTORY
storage area. Because the SALARY_HISTORY qualifier contains no
corruptions, an error message is returned:
$ RMU/RESTORE/AREA MF_PERSONNEL.RBF JOBS,SALARY_HISTORY/JUST_CORRUPT, -
_$ DEPARTMENTS/JUST_CORRUPT
%RMU-I-RESTXT_20, Storage area DISK1:[AREA]SALARY_HISTORY.RDA;1 is
not corrupt and will not be restored
Example 17
The following example demonstrates the behavior of the RMU
Restore command when the Just_Corrupt qualifier is used both
globally and locally. The global use of the Just_Corrupt
qualifier overrides an local use of the qualifier. In this case,
the RMU restore process restores the JOBS, SALARY_HISTORY, and
DEPARTMENTS storage areas only if they contain corruptions;
otherwise an error is returned. Assume, like the previous
examples, that only the JOBS and DEPARTMENTS storage areas
contain corruptions:
$ RMU/RESTORE/JUST_CORRUPT/AREA MF_PERSONNEL.RBF SALARY_HISTORY, -
_$ JOBS/JUST_CORRUPT, DEPARTMENTS/JUST_CORRUPT
%RMU-I-RESTXT_20, Storage area DISK1:[AREA]SALARY_HISTORY.RDA;1 is
not corrupt and will not be restored
7 – Examples (Cont.)
Example 18
The following example demonstrates the use of the Directory,
File, and Root qualifiers. In this example:
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 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 process restores EMPIDS_MID
in DISK4:[FILE].
o The target file name for the EMPIDS_LOW storage area is
EMPIDS. Thus, the RMU restore process restores the EMPIDS_LOW
storage area to the DISK2:[DIR] default directory (specified
with the Directory qualifier), and names the file EMPIDS.RDA.
o The target for the EMPIDS_LOW snapshot file is
DISK5:[SNAP]EMPIDS.SNP. Thus, the RMU restore process restores
the EMPIDS_LOW snapshot file to DISK5:[SNAP]EMPIDS.SNP.
o All the other storage area files and snapshot files in the mf_
personnel database are restored in DISK2:[DIR]; the file names
for these storage areas and snapshot files remain unchanged.
$ RMU/RESTORE MF_PERSONNEL.RBF -
_$ /DIRECTORY=DISK2:[DIR] -
_$ /ROOT=DISK3:[ROOT]MF_PERSONNEL.RDB -
_$ EMPIDS_MID/FILE=DISK4:[FILE], -
_$ EMPIDS_LOW/FILE=EMPIDS -
_$ /SNAPSHOT=(FILE=DISK5:[SNAP]EMPIDS.SNP)
Example 19
The following example demonstrates how to restore a database
such that the newly restored database will allow read-only
transactions only. After the RMU restore process executes the
command, the database is ready for you to start Hot Standby
replication operations. See the Oracle Rdb7 and Oracle CODASYL
DBMS: Guide to Hot Standby Databases for details on starting Hot
Standby replication operations.
$RMU/RESTORE/TRANSACTION_MODE=READ_ONLY MF_PERSONNEL.RBF
Example 20
The following example uses the Nocommit qualifier while restoring
a backup file of a database that has a structure level of V7.1 in
a V7.2 environment.
$ RMU/SHOW VERSION
Executing RMU for Oracle Rdb V7.2-00
$ RMU/RESTORE MFP71.RBF /NOCOMMIT/NOCDD/NORECOVER
%RMU-I-AIJRSTAVL, 0 after-image journals available for use
%RMU-I-AIJISOFF, after-image journaling has been disabled
%RMU-I-LOGCONVRT, database root converted to current structure level
%RMU-S-CVTDBSUC, database USER1:[80]MF_PERSONNEL.RDB;1 successfully
converted from version V7.1 to V7.2
%RMU-W-USERECCOM, Use the RMU Recover command. The journals are not
available.
$ RMU/SHOW VERSION
Executing RMU for Oracle Rdb V7.2-00
$ RMU/CONVERT/ROLLBACK MF_PERSONNEL.RDB
%RMU-I-RMUTXT_000, Executing RMU for Oracle Rdb V7.2-00
Are you satisfied with your backup of RDBVMS_USER1:[V71]MF_PERSONNEL.RDB;1
and your backup of any associated .aij files [N]? Y
%RMU-I-LOGCONVRT, database root converted to current structure level
%RMU-I-CVTROLSUC, CONVERT rolled-back for RDBVMS_USER1:[V71]MF_PERSONNEL.
RDB;1 to version V7.1
Example 21
The following example uses the Close_Wait qualifier to set the
database close mode to TIMED AUTOMATIC, specifying that the
database will be closed automatically in 10 minutes.
$ RMU/RESTORE/OPEN_MODE=AUTOMATIC/CLOSE_WAIT=10/DIR=DISK:[DIR] TEST_DB.RBF
$ RMU/DUMP/HEADER=PARAMETERS TEST_DB.RDB
Example 22
The following example demonstrates that /SNAPSHOT=(ALLOCATION=N)
is a positional qualifier. The behavior is different (local
or global) depending on the placement of the qualifier on the
command line. In the following example, it is used both globally
and locally.
MALIBU-> RMU/RESTORE/NOCDD -
/DIR=SYS$DISK:[]/SNAP=ALLO=12345 [JONES.RDB]MF_PERSONNEL_V71.RDF -
DEPARTMENTS/SNAP=ALLO=2
MALIBU-> DIR/SIZE *.SNP
Directory DBMS_USER3:[JONES.WORK]
DEPARTMENTS.SNP;1 6
EMPIDS_LOW.SNP;1 24692
EMPIDS_MID.SNP;1 24692
EMPIDS_OVER.SNP;1 24692
EMP_INFO.SNP;1 24692
JOBS.SNP;1 24692
MF_PERS_DEFAULT.SNP;1
24692
MF_PERS_SEGSTR.SNP;1
24692
SALARY_HISTORY.SNP;1
24692
Total of 9 files, 197542 blocks.
Example 23
The following example demonstrates how /SNAPSHOT=(ALLOCATION=N)
can be used to alter the parameters of the restored database from
those defined at the time of the database backup. /SNAPSHOT is
ofter used with /FILE: /FILE for the storage area RDA file and
/SNAPSHOT for the storage area snapshot file.
$ RMU/RESTORE MFP.RBF -
/DIRECTORY=DISK1:[DIRECTORY] -
/ROOT=DISK2:[DIRECTORY]MF_PERSONNEL.RDB -
EMPIDS_MID /FILE=[DISK3:[DIRECTORY] /SNAPSHOT=(ALLOCATION=2000), -
EMPIDS_LOW /FILE=[DISK3:[DIRECTORY]NEWNAME -
/SNAPSHOT=(FILE=DISK4:[DIR]NEWNAME, ALLOCATION=3000)
In this example, the root would go to one disk, EMPIDS_MID
would go to another, EMPIDS_LOW to another disk and the snap
to another disk and both snaps would be allocated the specified
number of pages. All the other snaps and RDA files would go to
where /DIRECTORY points (and the snaps would keep their original
allocation).
8 – Only Root
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.
8.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.
8.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
8.3 – Parameters
8.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
8.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.
8.4 – Command Qualifiers
8.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.
8.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.
8.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.
8.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.
8.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.
8.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.
8.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.
8.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.)
8.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.
8.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.
8.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.
8.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.
8.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.
8.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.
8.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.
8.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.
8.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
8.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.
8.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.
8.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.
8.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.
8.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.
8.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.
8.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.
8.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.
8.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.
8.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.
8.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)