Enters new file specifications for database files. The file
specification you enter will be the file specification after
the change is committed to the database. The change does not
occur until you have committed all changes and ended the RdbALTER
session.
NOTE
Prior to Oracle Rdb Version 6.0, you could use the DEPOSIT
ROOT command to alter an after-image journal (.aij) file
name. This is no longer an option; use the RMU Set After_
Journal command instead.
1 – Description
The default is DEPOSIT ROOT SPECIFICATION if no other keyword
follows the DEPOSIT ROOT command.
The DEPOSIT ROOT command allows a user to remove recovery-unit
journal (.ruj) file references from the database root (.rdb)
file, allowing access to the database. However, this action
will mark the database as "eternally corrupt," which results
in a warning message in all future system management (Oracle
RMU) functions against the database. The database is either
structurally corrupt, logically corrupt (violates a constraint),
or "user-data" corrupt (for example, balance is $250.00 instead
of $300.00).
Removing the .ruj file references from the .rdb file permits
users to attach to the database in situations where the .ruj
files have been accidentally deleted. Users must realize that
the database is corrupt when they attach. The database must be
restored and recovered from clean backup files to guarantee the
consistency of the database contents.
Use the USER n RUJ_FILENAME="" clause to remove an .ruj file
reference from the .rdb file.
NOTE
After you commit a changed .rdb file name, the database
cannot be accessed until you copy it to the location (using
all the necessary qualifiers for the file specification)
that you specify with the DEPOSIT ROOT command. After that,
users attach to the database at the new location.
2 – Format
(B)0[mqwqqqqqq>qqqqqwq> [4mROOT[m qwqqqqqqqqqqqqqqqqqqqqqqqqwq> = file-spec qq>
mq> [4mDEPOSIT[m qj tq> [4mSPECIFICATION[m qqqqqqqu
mq> [4mUSER[m n [4mRUJ_FILENAME[m qj
3 – Arguments
3.1 – SPECIFICATION
Enters the new file specification of the .rdb file.
3.2 – USER n RUJ FILENAME
Enters the new file specification for the .ruj file for the
specified user. In this syntax, n is a valid user number.
3.3 – file-spec
Specifies the full file specification (including version number)
that the .rdb file will have after it has been committed and the
RdbALTER session is complete.
The file specification can be a set of double quotation marks
("") if you are removing the .ruj file specification.
4 – Examples
Example 1
The following example enters a new file specification for the
.rdb file. You must specify a version number in the new file
specification for the .rdb file. The word (marked) in the DEPOSIT
ROOT display indicates that the .rdb file is marked for the
specified location but has not been moved to that location.
RdbALTER> DISPLAY ROOT
Root file specification is: "DISK1:[RICK.RDB]MF_PERSONNEL.RDB;1"
RdbALTER> DEPOSIT ROOT SPECIFICATION="DISK1:[RICK]MF_PERSONNEL.RDB;1"
(marked) Root file specification is: "DISK1:[RICK]MF_PERSONNEL.RDB;1"
See the Oracle Rdb Guide to Database Maintenance for more
examples of how to use the DEPOSIT ROOT command.
5 – UNIQUE_IDENTIFIER
Enters a new unique identifier into the storage area header
blocks of ALL active storage area and storage area snapshot files
which are currently defined in the database root.
5.1 – Description
To ensure Oracle Rdb database security and integrity, a Unique
Identifier has been added to the database root file and the
database storage area file and storage area snapshot file
headers. The Unique Identifier in the root file must match the
Unique Identifier in the storage area file headers or a storage
area cannot be accessed from the database root.
The Unique Identifier values are displayed both in VMS date
format surrounded by quotes and as a hexadecimal number
surrounded by parentheses. The values displayed are the Unique
Identifier values for the current RMU/ALTER session. The Unique
Identifier values will not be written to the root or storage area
files until the user ends the current session with the RMU/ALTER
"COMMIT" command. If the user ends the current session with the
RMU/ALTER "ROLLBACK" command, the Unique Identifier values will
not be written to the root or storage area files and the Unique
Identifier values in effect at the start of the session just
ended will be restored for the new session. Any Unique Identifier
values that have been changed during the current session will be
displayed as "(marked)" before they are committed or rolled back.
If "= NEW" is not specified, this command stores the current
database root Unique Identifier value into the storage area
header blocks of ALL active storage area and storage area
snapshot files which are currently defined in the database root
when the user executes the next COMMIT command. If "= NEW" is
specified, a new Unique Identifier value is created and stored
in both the root file and ALL active storage area file headers
when the user executes the next COMMIT command. Note that to
ensure database integrity, ALL storage area file headers will be
updated.
To execute the DISPLAY or DEPOSIT ROOT command, the user must
be attached to the database which the root and areas belong to,
either by specifying the database name when issuing the RMU/ALTER
command or by executing the "ATTACH" command from the "RdbALTER>"
prompt.
5.2 – Format
(B)0[mqwqqqqqq>qqqqqwq> [4mROOT[m [4mUNIQUE_IDENTIFIER[m ( = NEW ) qqq> mq> [4mDEPOSIT[m qj
5.3 – Arguments
5.3.1 – = NEW
If "= NEW" is specified, a new Unique Identifier value is created
and stored in both the root file and ALL active storage area file
headers when the user executes the next COMMIT command. Note that
to ensure database integrity, ALL storage area file headers will
be updated. Use the AREA_HEADER commands described elsewhere in
this chapter for storing the current root Unique Identifier value
in specific designated storage areas.
If "= NEW" is not specified, this command stores the current
database root Unique Identifier value into the storage area
header blocks of ALL active storage area and storage area
snapshot files which are currently defined in the database root
when the user executes the next COMMIT command.
5.4 – Examples
Example 1
The following example shows how to enter a new unique_identifier
value using RMU/ALTER.
$ RMU/ALTER MF_PERSONNEL
%RMU-I-ATTACH, now altering database
"DEVICE:[DIRECTORY]MF_PERSONNEL.RDB;1"
DEPOSIT ROOT UNIQUE_IDENTIFIER = NEW
(marked) Root file unique identifier is: "22-OCT-2010 13:49:31.72"
(00AA55786ACFB115)
COMMIT
EXIT
Example 2
The following example shows that RMU/ALTER is invoked specifying
the database MF_PERSONNEL.RDB. The user then displays the current
Unique Identifier value in the database root, creates a new
Unique Identifier value in the database root, displays the new
Unique Identifier in the root, and finally specifies "commit"
to write the new Unique Identifier value to the database root
file and ALL database storage area files. The display messages
designate the pending new Unique Identifier value as "(marked)"
until the user either executes "commit" to write out the new
Unique Identifier value or "rollback" to restore the original
Unique Identifier value. The user then verifies the database
changes.
$ RMU/ALTER MF_PERSONNEL
%RMU-I-ATTACH, now altering database "DISK:[DIRECTORY]MF_PERSONNEL.RDB;1"
DISPLAY ROOT UNIQUE_IDENTIFIER
Root file unique identifier is: "22-OCT-2010 13:49:27.87"
(00AA5578688428BB)
DEPOSIT ROOT UNIQUE_IDENTIFIER = NEW
(marked) Root file unique identifier is: "22-OCT-2010 13:49:28.34"
(00AA557868CC9F7A)
DISPLAY ROOT UNIQUE_IDENTIFIER
(marked) Root file unique identifier is: "22-OCT-2010 13:49:28.34"
(00AA557868CC9F7A)
COMMIT
EXIT
$ RMU/VERIFY/ALL/NOLOG MF_PERSONNEL