1 – After Journal
Allows you to do any of the following with respect to after-image
journal (.aij) files:
o Enable or disable after-image journaling.
o Alter an .aij file (occurs only if .aij file is re-created).
o Add, drop, modify, or reserve .aij files.
o Suppress the use of an .aij file.
o Add AIJ caches.
o Set the initial .aij file allocation.
o Set the .aij file extent (for extensible journals).
o Enable or disable .aij file overwriting.
o Send OpenVMS operator communication manager (OPCOM) messages
when specific after-image journal events occur.
o Set the shutdown timeout period.
NOTE
Prior to Oracle Rdb Version 6.0, the ability to alter an
.aij file name was provided through the RdbALTER DEPOSIT
ROOT command. Beginning with Oracle Rdb Version 6.0, the
RdbALTER DEPOSIT ROOT command no longer provides this
capability; use the Alter qualifier with the RMU Set After_
Journal command instead.
1.1 – Description
Many of the RMU Set After_Journal functions are also available
through the use of the following SQL ALTER DATABASE clauses:
ADD JOURNAL clause
DROP JOURNAL clause
ALTER JOURNAL clause
1.2 – Format
(B)0[mRMU/Set After_Journal root-file-spec
[4mCommand[m [4mQualifiers[m x [4mDefaults[m
x
/Add=(keyword[,...]) x No journals added
/Aij_Options=OptionsFile x None
/Allocation=number-blocks x See description
/Alter=(keyword[,...]) x No journals altered
/Backups=(keyword_list) x See description
/[No]Cache=file x See description
/Disable x None
/Drop=(Name=name) x No journals deleted
/Enable x None
/Extent=number-blocks x See description
/[No]Log x Current DCL verify value
/[No]Notify=(operator-class-list) x See description
/[No]Overwrite x None
/Reserve=number-journals x None
/Shutdown_Timeout=minutes x 60 minutes
/Suppress=(Name=name) x No journals suppressed
/Switch_Journal x None
1.3 – Parameters
1.3.1 – root-file-spec
Specifies the database root file for which you want to enable
journaling or set .aij file characteristics.
1.4 – Command Qualifiers
1.4.1 – Add
Add=(keyword, ...)
Adds an .aij file to the after-image journal file configuration.
You can add an .aij file while users are attached to the
database. If you specify the Suppress, Drop, or Alter qualifiers
in the same RMU Set After_Journal command, they are processed
before the Add qualifier. The Add qualifier can appear several
times in the same command.
Specify an .aij file to add by using the following keywords:
o Name=name
Specifies a unique name for the after-image journal object
to be added. An after-image journal object is the .aij file
specification plus all of its attributes, such as allocation,
extent, and backup file name.
This keyword is required.
o File=file
Specifies the file for the journal to be added. This keyword
is required. If you do not provide a full file specification,
and only the file name, the file is placed in your current
directory. If more than one journal resides in the same
directory, each journal must have a unique file name. However,
each fixed-size journal file should be located on a separate
device. This minimizes risks associated with journal loss or
unavailability should a device fail or be brought off line.
For example, if two or more journal files reside on the same
failed device, the loss of information or its unavailability
is far greater than that of a single journal file.
o Backup_File=file
Specifies the file to be used for automatic backup operations.
This keyword is optional. If you specify a file name, but
not a file extension, the .aij file extension is used by
default. If you supply only a file name (not a complete file
specification), the backed up .aij file is placed in the
database root file directory.
o Edit_Filename=(option)
Specifies an edit string to apply to the backup file
when an .aij is backed up automatically. This keyword is
optional. However, if it is specified, the Backup_File=file
keyword must be specified also. When you specify the Edit_
Filename=(options) keyword, the .aij backup file name is
modified by appending the options you specify.
See the description of the Edit_Filename keyword for the
Backups qualifier for a list of the available keyword options.
This keyword and the options you specify affect the backup
file name of the .aij file specified with the associated Name
keyword only. If you want the same edit string applied to all
backed up .aij files, you might find it more efficient to use
the Backups qualifier with the Edit_Filename keyword instead
of the Add qualifier with the Edit_Filename keyword.
If you use a combination of the Edit_Filename keyword with the
Add qualifier and the Edit_Filename keyword with the Backups
qualifier, the Add qualifier keyword takes precedence over the
Backups qualifier keyword for the named .aij file. In other
words, the options you specify with Edit_Filename keyword
to the Backups qualifier are applied to all backed up .aij
files except those for which you explicitly specify the Edit_
Filename keyword with the Add qualifier. See Example 6.
This keyword is useful for creating meaningful file names for
your backup files and makes file management easier.
o Allocation=number-blocks
Sets the initial size, in disk blocks, of the .aij file. If
this keyword is omitted, the default allocation is used.
The minimum valid value is 512, the maximum value is eight
million. The default is 512.
See the Oracle Rdb Guide to Database Maintenance for guidance
on setting the allocation size.
o Extent=number-blocks
Specifies the maximum size to extend an .aij file if it is,
or becomes, an extensible .aij file (in blocks). (If the
number of available after-image journal files falls to one,
extensible journaling is employed.)
If there is insufficient free space on the .aij file device,
the journal is extended using a smaller extension value than
specified. However, the minimum, and default, extension size
is 512 blocks.
See the Oracle Rdb Guide to Database Maintenance for guidance
on setting the extent size.
1.4.2 – AIJ Options
AIJ_Options=OptionsFile
Specifies an options file name. The default extension is .opt.
The OptionsFile is the same as that generated by an RMU Show
After_Journal command and is also used by the RMU Copy_Database,
Move_Area, Restore, and Restore Only_Root commands. The AIJ_
Options qualifier may be used alone or in combination with other
RMU Set After_Journal command qualifiers.
1.4.3 – Allocation
Allocation=number-blocks
Sets the default .aij file allocation. You can change the
allocation while users are attached to the database. If the
Allocation qualifier is omitted, the default allocation is
unchanged.
The minimum value you can specify is 512. The default is also
512.
See the Oracle Rdb Guide to Database Maintenance for guidance on
setting the allocation size.
1.4.4 – Alter
Alter=(keyword,...)
Specifies that an after-image journal object be altered.
You can alter an after-image journal object while users are
attached to the database. The Alter qualifier can be used
several times within the same RMU Set After_Journal command.
If you specify a previously suppressed .aij file with the
Alter qualifier, that named .aij file is unsuppressed. Oracle
RMU performs this unsuppress action as soon as the command is
processed.
The changes specified by the Alter qualifier are stored in the
database root file (and thus are visible in the dump file if you
issue an RMU Dump command), but the changes are not applied to
the .aij file until it is re-created (or backed up, in the case
of the Backup_File= file keyword). A new extensible .aij file is
re-created, for example, when the following are true:
o Fast commit is enabled.
o Extensible after-image journaling is being used.
o Users are actively updating the database.
o You issue an RMU Backup After_Journal command with the
Noquiet_Point qualifier.
Backing up an extensible .aij file does not ensure that a new
.aij file will be created. In most cases, the existing .aij file
is truncated and reused.
Specify an after-image journal object to alter by using the
following keywords:
o Name=name
Specifies the name of the after-image journal object. This
is a required keyword that must match the name of an existing
after-image journal object.
o File=file
This option only takes effect if a journal is, or becomes,
an extensible .aij file and only when that journal is re-
created. This option allows you to supply a new .aij file
specification to be used for the extensible .aij file if and
when it is re-created. This can be used to move the re-created
.aij file to a new location. If you do not provide a full file
specification, and only the file name, the file is placed in
your current directory. See the general description of the
Alter qualifier for an example of when an extensible .aij file
is re-created.
This option cannot be used to move a fixed-size .aij file. To
move a fixed-size .aij file, you must first create a new .aij
file and then drop the existing .aij file.
This keyword is optional.
o Backup_File=file
Specifies a new file to be used for automatic backup
operations.
This keyword is optional.
o Edit_Filename=(options)
Specifies a new edit string to apply to the backup file
name of the named .aij file when the .aij is backed up
automatically. This keyword is optional. See the description
of the Edit_Filename keyword for the Backups qualifier for a
list of the available keyword options.
o Allocation=number-blocks
Specifies the initial size of the .aij file that is re-created
if that file is, or becomes, a fixed-size .aij file.
o Extent=number-blocks
Specifies the extent size of the .aij file that is re-created
if it is, or becomes, extensible.
See the Oracle Rdb Guide to Database Maintenance for guidance
on setting the extent size.
1.4.5 – Backups
Backups=(keyword_list)
Specifies options to control the AIJ backup server. You can
select one or more of the following keywords:
o Automatic
Specifies that the AIJ backup server will run automatically,
as required. You cannot specify both the Automatic and Manual
keywords. If neither the Automatic nor the Manual keyword is
specified, the backup server state is unchanged.
o Manual
Specifies that the RMU Backup After_Journal command will be
used to back up the .aij files. The AIJ backup server will
not run automatically. You cannot specify both Automatic
and Manual keywords. If neither the Automatic nor the Manual
keyword is specified, the backup server state is unchanged.
o Backup_File=file
Specifies a default file specification for the AIJ backup
server to use as the backup file name if no backup file name
is associated with the .aij file to be backed up.
o Nobackup_File
Specifies that there is no default backup file specification.
Omission of this keyword retains the current default backup
file specification.
o Edit_Filename=(options)
The Edit_Filename keyword specifies an edit string to apply
to .aij files when they are backed up automatically. When
the Edit_Filename=(options) keyword is used, the .aij backup
file names are edited by appending any or all of the values
specified by the following options to the backup file name:
- Day_Of_Year
The current day of the year expressed as a 3-digit integer
(001 to 366).
- Day_Of_Month
The current day of the month expressed as a 2-digit integer
(01 to 31).
- Hour
The current hour of the day expressed as a 2-digit integer
(00 to 23).
- Julian_Date
The number of days passed since 17-Nov-1858.
- Minute
The current minute of the hour expressed as a 2-digit
integer (00 to 59).
- Month
The current month expressed as a 2-digit integer (01 to
12).
- Sequence
The journal sequence number of the first journal in the
backup operation.
- Vno
Synonymous with the Sequence option. See the description of
the Sequence option.
- Year
The current year (A.D.) expressed as a 4-digit integer.
If you specify more than one option, place a comma between
each option.
The edit is performed in the order specified. For example, the
file backup.aij and the keyword EDIT_FILENAME=(HOUR, MINUTE,
MONTH, DAY_OF_MONTH, SEQUENCE) creates a file with the name
backup_160504233.aij when journal 3 is backed up at 4:05 P.M.
on April 23rd.
You can make the name more readable by inserting quoted
strings between each Edit_Filename option. For example, the
option shown in the following code adds the string "$30_0155-
2" to the .aij file name if the day of the month is the 30th,
the time is 1:55 and the version number is 2:
/EDIT_FILENAME=("$",DAY_OF_MONTH,"_",HOUR,MINUTE,"-",SEQUENCE)
This keyword is useful for creating meaningful file names for
your backup files and makes file management easier.
If you use a combination of the Edit_Filename keyword with
the Add qualifier and the Edit_Filename keyword with the
Backups qualifier, the Add qualifier keyword takes precedence
over the Backups qualifier keyword for the named .aij file.
In other words, the options you specify with Edit_Filename
keyword to the Backups qualifier are applied to all .aij back
up files except those for which you explicitly specify the
Edit_Filename keyword with the Add qualifier. See Example 6.
o Quiet_Point
Specifies that the after-image journal backup operation is
to acquire the quiet-point lock prior to performing an .aij
backup operation for the specified database. This option
(as with all the other Backup options) affects only the
database specified in the RMU Set After_Journal command line.
For information on specifying that the quiet-point lock be
acquired before any .aij backup operation is performed on a
system, see the Usage Notes.
o Noquiet_Point
Specifies that the after-image journal backup operation will
not acquire the quiet-point lock prior to performing an .aij
backup operation for the specified database. This option (as
with all the other Backup options) affects only the database
specified in the RMU Set After_Journal command line. For
information on specifying that the quiet-point lock will not
be acquired prior to any .aij backup operations performed on a
system, see the Usage Notes.
1.4.6 – Cache
Cache=file
Nocache
Specifies an after-image journal cache file specification on a
solid-state disk. If the Cache qualifier is specified, after-
image journal caches are enabled. If you specify a file name, but
not a file extension, the file extension .aij is used by default.
If the Nocache qualifier is specified, AIJ caches are disabled.
You can use this qualifier only when users are detached from the
database.
This file must be written to a solid-state disk. If a solid-state
disk is not available, after-image journal caching should not be
used. Unless you are involved in a high performance, high-volume
environment, you probably do not need the features provided by
this qualifier.
You can determine whether the cache file is accessible by
executing the RMU Dump command with the Header qualifier. If
caching is enabled, but the cache file is unavailable, the cache
file is marked inaccessible and after-image journaling continues
as if caching was disabled. Once the cache file has been marked
inaccessible, it will remain so marked until either the existing
cache file is dropped from the database, or a new cache file is
added to the database (even if this is the same cache file as was
previously used).
If this qualifier is omitted, the AIJ cache state remains
unchanged.
1.4.7 – Disable
Disable
Disables after-image journaling if it has already been enabled.
If after-image journaling has already been disabled, this
qualifier has no effect. You can specify the Disable qualifier
only when users are detached from the database.
When the Disable qualifier and other qualifiers are specified
with the RMU Set After_Journal command, after-image journaling is
disabled before other requested operations.
There is no default for the Disable qualifier. If you do not
specify either the Disable or Enable qualifier, the after-image
journaling state remains unchanged.
1.4.8 – Drop
Drop=(Name=name)
Specifies that the named after-image journal object be deleted.
You can drop an after-image journal object while users are
attached to the database, but the named after-image journal
object must not be the current .aij file or be waiting to be
backed up. When the Drop qualifier is specified with the Alter
or Add qualifiers on the RMU Set After_Journal command, the named
after-image journal object is dropped before any after-image
journal objects are altered or added.
Each after-image journal object to be deleted is specified by
the required keyword, Name=name. This specifies the name of the
after-image journal object to be dropped, which must match the
name of an existing after-image journal object.
1.4.9 – Enable
Enable
Enables after-image journaling if it has been disabled. You can
specify the Enable qualifier only when users are detached from
the database and at least one unmodified .aij file is available
(unless you also specify the Overwrite qualifier). After-image
journaling is enabled after other specified qualifiers have been
processed.
1.4.10 – Extent
Extent=number-blocks
Sets the size, in blocks, of the default .aij file extension.
This qualifier has no effect on fixed-length .aij files. This
qualifier can be used while users are attached to the database.
The minimum valid number-blocks value is 512. The default is also
512.
If the Extent qualifier is omitted, the default extension remains
unchanged.
See the Oracle Rdb Guide to Database Maintenance for guidance on
setting the extent size.
1.4.11 – Log
Log
Nolog
Specifies whether the processing of the command is reported to
SYS$OUTPUT. Specify the Log qualifier to request log output and
the Nolog qualifier to prevent it. If you specify neither, the
default is the current setting of the DCL verify switch. (The DCL
SET VERIFY command controls the DCL verify switch.)
1.4.12 – Notify
Notify=(operator-class-list)
Nonotify
Sets the operator notification state for after-image journaling
and selects the operators to be notified when the journaling
state changes. Oracle RMU uses the OpenVMS operator communication
manager (OPCOM). The following events evoke operator
notification:
o An error writing to an .aij file.
o No .aij file is available for write operations.
o The .aij file has been overwritten.
o The RMU Backup After_Journal command fails.
You can use this qualifier while users are attached to the
database. If you specify the Nonotify qualifier, operator
notification is disabled. If the qualifier is omitted, the
operator notification state is unchanged.
The operator classes follow:
o [No]All
The All operator class broadcasts a message to all terminals
that are attached to the system or cluster. These terminals
must be turned on and have broadcast-message reception
enabled. The Noall operator class inhibits the display of
messages to the entire system or cluster.
o [No]Central
The Central operator class broadcasts messages to the central
system operator. The Nocentral operator class inhibits the
display of messages to the central system operator.
o [No]Disks
The Disks operator class broadcasts messages pertaining to
mounting and dismounting disk volumes. The Nodisks operator
class inhibits the display of messages pertaining to mounting
and dismounting disk volumes.
o [No]Cluster
The Cluster operator class broadcasts messages from the
connection manager pertaining to cluster state changes. The
Nocluster operator class inhibits the display of messages from
the connection manager pertaining to cluster state changes.
o [No]Security
The Security operator class displays messages pertaining to
security events. The Nosecurity operator class inhibits the
display of messages pertaining to security events.
o [No]Oper1 through [No]Oper12
The Oper1 through Oper12 operator classes display messages
to operators identified as OPER1 through OPER12. The Nooper1
through Nooper12 operator classes inhibit messages from being
sent to the specified operator.
NOTE
Use the Notify qualifier conservatively. Be sure that
messages regarding a private database are not broadcast
to an entire system or cluster of users who may not be
interested in the broadcast information. Similarly, be
conservative regarding even a clusterwide database. You
do not want to overload the operators with insignificant
messages.
1.4.13 – Overwrite
Overwrite
Nooverwrite
The Overwrite qualifier specifies that .aij files can be
overwritten without first being backed up. The Nooverwrite
qualifier specifies that only an .aij file that has been backed
up can be overwritten. You can specify the Nooverwrite qualifier
only when users are detached from the database. If you do
not specify either the Overwrite qualifier or the Nooverwrite
qualifier, the Overwrite characteristic remains unchanged.
This qualifier is ignored if only one .aij file is available.
When you specify the Overwrite qualifier, it is only activated
when two or more .aij files are, or become, available.
Note that if you use the Overwrite qualifier, you will be unable
to perform a rollforward from a restored backup file. Most users
will not want to use the Overwrite qualifier; it is provided for
layered applications that might want to take advantage of some
performance features provided by Oracle Rdb that require after-
image journaling, but where the use of after-image journaling is
not required for the application to run reliably.
1.4.14 – Reserve
Reserve=number-journals
Reserves additional space in the after-image journal
configuration for the specified number of .aij files. You can
specify the Reserve qualifier only when users are detached from
the database. If you do not specify the Reserve qualifier, no
space is reserved for additional .aij files.
Note that you cannot reserve space in a single-file database for
.aij files by using this qualifier with the RMU Set After_Journal
command. After-image journal file reservations for a single-
file database can be made only when you use the RMU Convert, RMU
Restore, or RMU Copy_Database commands.
Note that once you reserve space in the journal configuration
(using the Reserve=n qualifier), the reservations are permanent.
There is no way to unreserve this space unless you back up and
restore the database. Specify fewer reservations with RMU Restore
command After_Journal qualifier.
Each reservation uses two blocks of space in the root file and
the run-time global sections.
When you reserve journals slots to create additional journals
for your journal system, the reserve operation is not journaled.
Therefore, you should perform a full database backup operation to
ensure database consistency.
1.4.15 – Shutdown Timeout
Shutdown_Timeout=minutes
Modifies the after-image journal shutdown time in the event that
after-image journaling becomes unavailable. The after-image
journaling shutdown time is the period, in minutes, between
the point when after-image journaling becomes unavailable and
the point when the database is shut down. During the after-
image journaling shutdown period, all database update activity
is stalled.
If operator notification has been enabled, operator messages are
broadcast to all enabled operator classes and to the RMU Show
Statistics screen at 1-minute intervals.
To recover from the after-image journaling shutdown state
and to resume normal database operations, you must make an
.aij file available for use. You can do this by backing up an
existing modified journal, or, if you have a journal reservation
available, by adding a new journal to the after-image journaling
configuration. If you do not make a journal available before the
after-image journal shutdown time expires, the database is shut
down and all active database attaches are terminated.
The after-image journaling shutdown period is only in effect when
fixed-size AIJ journaling is used. When a single extensible .aij
file is used, the default action is to shut down all database
operations when the .aij file becomes unavailable.
If you do not specify the Shutdown_Timeout qualifier, the
database shuts down 60 minutes after the after-image journaling
configuration becomes unavailable. The maximum value you can
specify for the Shutdown_Timeout qualifier is 4320 minutes (3
days).
1.4.16 – Suppress
Suppress=(Name=name)
Prevents further use of the named after-image journal object. The
named after-image journal object must be an existing after-image
journal object.
This qualifier is useful when you want to temporarily disallow
the use of an .aij file. For example, suppose the disk containing
the next .aij file to use goes off line. You do not want the
database to attempt to access that file until the disk is back on
line. Use the Suppress qualifier so the database does not attempt
to access the specified .aij file. When the disk is back on line,
use the RMU Set After_Journal command with the Alter qualifier
to unsuppress the after-image journal object that references this
.aij file.
You can specify the Suppress qualifier while users are attached
to the database, but the .aij file referenced by the after-image
journal object must not be the current journal or be waiting
to be backed up. You must back up the referenced .aij file
before the after-image journal object that references it can
be suppressed.
The Suppress qualifier is processed prior to any Drop, Add, or
Alter qualifiers specified with the same command.
1.4.17 – Switch Journal
Switch_Journal
Changes the currently active .aij file to the next available .aij
file in a fixed-size after-image journaling configuration.
In an extensible journal file configuration, the Switch_Journal
qualifier has no effect and is ignored if specified.
The Switch_Journal qualifier is useful for forcing a switch to an
.aij file on another disk when you want to perform maintenance on
the disk containing the currently active journal file.
You cannot specify the Switch_Journal qualifier and the Enable
or the Disable qualifier on the same command line. In addition,
after-image journaling must be enabled when you issue the Switch_
Journal qualifier.
It is seldom necessary to specify this option because normally a
switch occurs automatically.
1.5 – Usage Notes
o You must have the RMU$ALTER, RMU$BACKUP, or RMU$RESTORE
privilege in the root file access control list (ACL) for the
database or the OpenVMS SYSPRV or BYPASS privilege to use the
RMU Set After_Journal command.
o Use the RMU Dump command with the Header qualifier to see if
after-image journaling additions or changes you have made have
been recorded as you expect. However, note that although the
AIJ attributes change as you specify, the changed .aij file
might be flagged as unmodified in the dump of the header. This
occurs because the transaction containing your changes to the
.aij file is captured in the current .aij file, not the .aij
file for which you specified modifications.
o When you use RMU Set After_Journal to specify a fixed-size
journal configuration, specify a different disk for each
.aij file, if possible. Using this method, you can suppress
a journal on a given disk if that disk should start to fail.
o If the disk fails on which the current .aij file resides,
Oracle Rdb immediately starts using a new .aij file if your
journal configuration contains more than one journal. For
example, if AIJ_DISK1 contains AIJ_ONE, the current .aij file,
and AIJ_DISK1 fails, Oracle Rdb will immediately start using
AIJ_TWO, the .aij file on AIJ_DISK2.
o Execute a full database backup operation after issuing an RMU
Set After_Journal command that displays the RMU-W-DOFULLBCK
warning message (such as a command that includes the Reserve
or the Enable qualifier).
o Use the Alter qualifier to unsuppress an .aij file that has
been suppressed with the Suppress qualifier.
o Use the Backup=(Quiet_Point) qualifier to specify that the
quiet-point lock must be acquired prior to performing an
.aij backup operation for the specified database. (Use the
Backup=(Noquiet_Point) qualifier to specify that the quiet-
point lock will not be acquired prior to an .aij backup
operation for the specified database.)
o Use the RDM$BIND_ABS_QUIET_POINT logical to specify whether or
not the quiet-point lock must be acquired prior to performing
any .aij backup operation on any database on a cluster.
Define the value for the logical to be 1 to specify that the
quiet-point lock must be acquired prior to performing .aij
backup operations; define the value to be 0 to specify that
the quiet-point lock need not be acquired prior to .aij backup
operations. You must define this logical in the system table
on all nodes in the cluster as shown in the following example:
$ DEFINE/SYSTEM RDM$BIND_ABS_QUIET_POINT 1
o The selection of which journal in a set of fixed-size journal
files is used by Oracle RMU is unpredictable and depends on
availability. For example, while a journal is temporarily
unavailable, it cannot be selected as the next journal file.
Thus, a journal file might be reused before all journals in
the set have been used once.
1.6 – Examples
Example 1
The following command reserves space for three .aij files, adds
two .aij files to the mf_personnel database, and then enables
after-image journaling:
$ RMU/SET AFTER_JOURNAL/ENABLE/RESERVE=3 -
_$ /ADD=(NAME=AIJ2, FILE=DISK1:[JOURNAL]AIJ_TWO) -
_$ /ADD=(NAME=AIJ3, FILE=DISK2:[JOURNAL]AIJ_THREE) -
_$ MF_PERSONNEL
%RMU-W-DOFULLBCK, full database backup should be done to
ensure future recovery
Example 2
The following example demonstrates how to switch the current .aij
file from DISK1:[DB]AIJ1 to the next available journal file in a
fixed-size journal configuration, and then suppress the original
journal in anticipation of maintenance on the disk that contains
it. The last Oracle RMU command moves AIJ1 to a new disk and
implicitly unsuppresses it.
$ RMU/DUMP/HEADER=(JOURNAL) MF_PERSONNEL
.
.
.
AIJ Journaling...
- After-image journaling is enabled
- Database is configured for 5 journals
- Reserved journal count is 5
- Available journal count is 3
- Journal switches to next available when full
- 1 journal has been modified with transaction data
- 2 journals can be created while database is active
- Journal "AIJ1" is current
- All journals are accessible
.
.
.
$ RMU/SET AFTER_JOURNAL/SWITCH_JOURNAL MF_PERSONNEL/LOG
%RMU-I-OPERNOTIFY, system operator notification: Oracle Rdb Database
USER1:[DB]MF_PERSONNEL.RDB;1 Event Notification
After-image journal 0 switch-over in progress (to 1)
%RMU-I-OPERNOTIFY, system operator notification: Oracle Rdb Database
USER1:[DB]MF_PERSONNEL.RDB;1 Event Notification
After-image journal switch-over complete
%RMU-I-LOGMODSTR, switching to after-image journal "AIJ2"
.
.
.
$ RMU/BACKUP/AFTER_JOURNAL MF_PERSONNEL DISK1:[DB]AIJ1_BCK/LOG
%RMU-I-AIJBCKBEG, beginning after-image journal backup operation
%RMU-I-OPERNOTIFY, system operator notification: Oracle Rdb Database
USER1:[DB]MF_PERSONNEL.RDB;1 Event Notification
AIJ backup operation started
%RMU-I-AIJBCKSEQ, backing up after-image journal sequence number 2
%RMU-I-LOGBCKAIJ, backing up after-image journal AIJ1 at 10:59:58.83
%RMU-I-LOGCREBCK, created backup file DISK1:[DB]AIJ1_BCK.AIJ;1
%RMU-I-OPERNOTIFY, system operator notification: Oracle Rdb Database
USER1:[DB]MF_PERSONNEL.RDB;1 Event Notification
AIJ backup operation completed
%RMU-I-AIJBCKEND, after-image journal backup operation completed
successfully
%RMU-I-LOGAIJJRN, backed up 1 after-image journal at 11:00:02.59
%RMU-I-LOGAIJBLK, backed up 254 after-image journal blocks
at 11:00:02.59
$ RMU/SET AFTER_JOURNAL/SUPPRESS=(NAME=AIJ1) MF_PERSONNEL/LOG
%RMU-I-LOGMODSTR, suppressed after-image journal "AIJ1"
$ RMU/SET AFTER_JOURNAL MF_PERSONNEL -
_$ /ALTER=(NAME=AIJ1,FILE=DISK2:[DB]AIJ1)/LOG
%RMU-I-LOGMODSTR, unsuppressed after-image journal "AIJ1"
Example 3
The following example turns on the automatic backup server for
.aij files and defines a default backup file name:
$ RMU/SET AFTER_JOURNAL /BACKUPS=(AUTOMATIC, -
_$ BACKUP_FILE=DISK:[AIJ_BACKUPS]AIJ_BACKUP.AIJ) -
_$ DB$DISK:[DIRECTORY]MF_PERSONNEL.RDB
Example 4
The following example turns off the automatic backup server for
.aij files and removes the default backup file name:
$ RMU/SET AFTER_JOURNAL /BACKUPS=(MANUAL,NOBACKUP_FILE) -
_$ DB$DISK:[DIRECTORY]MF_PERSONNEL.RDB
Example 5
The following example changes the .aij backup file name without
changing the setting of the AIJ backup server:
$ RMU/SET AFTER_JOURNAL /BACKUPS= -
_$ (BACKUP_FILE=NEW_DISK:[AIJ_BACKUPS]BETTER_BACKUP_NAME.AIJ) -
_$ DB$DISK:[DIRECTORY]MF_PERSONNEL.RDB
Example 6
The following example sets a local and a global edit string for
.aij backup files. When AIJ_ONE is backed up, it is appended with
the string _LOCAL. When AIJ_TWO or AIJ_THREE are backed up, they
are appended with the string _GLOBAL. Although it is unlikely
that you would select these edit strings, they demonstrate the
behavior of the Edit_Filename keyword when it is used with the
Backup qualifier (global effect) versus the behavior of the Edit_
Filename keyword when it is used with the Add qualifier (local
effect).
$ RMU/SET AFTER_JOURNAL/ENABLE/RESERVE=5 -
_$ /BACKUP=EDIT_FILENAME=("_GLOBAL")/ADD=(NAME=AIJ1, -
_$ FILE=DISK1:[AIJS]AIJ_ONE, -
_$ BACKUP_FILE=AIJ1BCK, -
_$ EDIT_FILENAME=("_LOCAL")) -
_$ /ADD=(NAME=AIJ2, -
_$ FILE=DISK1:[AIJS]AIJ_TWO, -
_$ BACKUP_FILE=AIJ2BCK) -
_$ /ADD=(NAME=AIJ3, -
_$ FILE=DISK1:[AIJS]AIJ_THREE, -
_$ BACKUP_FILE=AIJ3BCK) -
_$ MF_PERSONNEL
$ !
$ ! After these .aij files are backed up:
$ !
$ DIR .AIJ
AIJ1BCK_LOCAL.AIJ;1
AIJ2BCK_GLOBAL.AIJ;1
AIJ3BCK_GLOBAL.AIJ;1
AIJ_ONE.AIJ;1
AIJ_THREE.AIJ;1
AIJ_TWO.AIJ;1
2 – AIP
Allows the user to modify the contents of the AIP (Area Inventory
Pages) structure. The AIP structure provides a mapping for
logical areas to physical areas as well describing each of those
logical areas. Information such as the logical area name, length
of the stored record, and storage thresholds can now be modified
using this simple command interface.
2.1 – Description
This RMU command is used to modify some attributes of an existing
logical area. It cannot be used to add or delete a logical area.
This command can be used to correct the record length, thresholds
and name of a logical area described by an AIP entry. It can also
be used to rebuild the SPAM pages for a logical area stored in
UNIFORM page format areas so that threshold settings for a page
correctly reflect the definition of the table.
See also the RMU Repair Spam command for information on
rebuilding SPAM pages for MIXED areas.
2.2 – Format
(B)0[mRMU/Set AIP root-file-spec [larea-name]
[4mCommand[m [4mQualifiers[m x [4mDefaults[m
x
/Larea=(n [,...]) x See description
/Length[=n] x See description
/Log x See description
/Rebuild_Spams x See description
/Rename_To=new-name x See description
/Threshold=(p,q,r) x See description
2.3 – Parameters
2.3.1 – root-file-spec
The file specification for the database root file to be
processed. The default file extension is .rdb.
2.3.2 – larea-name
An optional parameter that allows the logical areas to be
selected by name. Only those AIP entries are processed.
Any partitioned index or table will create multiple logical areas
all sharing the same name. This string may contain standard
OpenVMS wildcard characters (% and *) so that different names
can be matched. Therefore, it is possible for many logical areas
to match this name.
The value of larea-name may be delimited so that mixed case
characters, punctuation and various character sets can be used.
2.4 – Command Qualifiers
2.4.1 – Larea
Larea=(n [,...])
Specifies a list of logical area identifiers. The LAREA qualifier
and larea-name parameter are mutually exclusive.
2.4.2 – Length
Length[=value]
Sets the length of the logical area. If no value is provided on
the RMU Set AIP command, then Oracle Rdb will find the matching
table and calculate a revised AIP nominal record length and apply
it to the AIP.
2.4.3 – Log
Log
Logs the names and identifiers of logical areas modified by this
command.
2.4.4 – Rebuild Spams
Rebuild_Spams
Locate each logical area with the "rebuild-spam" flag set and
rebuild the SPAM pages.
2.4.5 – Rename To
Rename_To=new-name
Used to change the logical area name. This qualifier should be
used with caution as some RMU commands assume a strict mapping
between table/index names and names of the logical area. This
command can be used to repair names that were created in older
versions of Oracle Rdb where the rename table command did not
propagate the change to the AIP. The value of new-name may be
delimited so that mixed case, punctuation and various character
sets can be used.
2.4.6 – Threshold
Threshold=(t1 [,t2 [, t3]])
Changes the threshold on all logical areas specified using
the Larea qualifier or the larea-name parameter. RMU accepts
THRESHOLD=(0,0,0) as a valid setting to disable logical area
thresholds. Values must be in the range 0 through 100. Any
missing values default to 100.
2.5 – Usage Notes
o The database administrator requires RMU$ALTER privilege to run
the command and the Rdb server also requires SELECT and ALTER
privilege on the database.
o This command supersedes the RMU Repair Initialize=Larea_
Parameters command that can also change the Thresholds and
Length for a logical area. This command can be executed
online, whereas the RMU Repair command must be run offline.
o Wildcard names are not permitted with the following qualifiers
to prevent accidental propagation of values to the wrong
database objects.
- LENGTH qualifier with a value specified,
- RENAME_TO qualifier,
- and THRESHOLDS qualifier.
o RMU Set AIP may be used on a master database configured for
HOT STANDBY. All AIP changes and SPAM rebuild actions are
written to the after image journal and will be applied to the
standby database. This command cannot be applied to a STANDBY
database.
o THRESHOLDS for MIXED format areas are physical area attributes
and are not supported at the logical area (aka AIP) level.
Therefore, THRESHOLDS can not be applied to MIXED areas and
specifying logical areas will cause an exception to be raised.
o The REBUILD_SPAMS qualifier is only applied to logical areas
stored in UNIFORM page format storage areas.
o This command will implicitly commit any changes with no
opportunity to undo them using rollback. Access to the
functionality is controlled by privileges at the RMU and Rdb
database level. We suggest that RMU Show AIP be used prior to
any change so that you can compare the results and repeat the
RMU Set AIP command with corrections if necessary.
Some wildcard operations are restricted to prevent accidental
damage to the database. For instance, a wildcard matching
many objects will be rejected if more than one type of object
is being changed. If a wildcard selects both table and index
types then this command will be rejected.
o This command is an online command. Each logical area will be
processed within a single transaction and interact with other
online users.
o When the AIP entry is changed online, any existing users of
the table or index will start to use the new values if the
logical areas are reloaded.
o Various SQL alter commands will register changes for the AIP
and these are applied at COMMIT time. RMU Verify and RMU Show
AIP Option=REBUILD_SPAMS will report any logical areas that
require SPAM rebuilding. The database administrator can also
examine the output from the RMU Dump Larea=RDB$AIP command.
o How long can the SPAM rebuild be delayed? The fullness of
some page will have been calculated using the old AIP length
or THRESHOLD values. Therefore, it might appear that a page
is full when in fact the revised length will fit on the
page, or the page may appear to have sufficient free space
to store a row but once accessed the space is not available.
By rebuilding SPAM pages, you may reduce I/O during insert
operations. However, delaying the rebuild to a convenient time
will not affect the integrity of the database.
o The amount of I/O required for Rebuild_Spams depends upon
the number of pages allocated to the table or index involved.
Assuming just one logical area is selected then Oracle Rdb
will read the ABM (Area Bitmap) to locate all SPAM pages in
that area that reference this logical area. Rdb will then
read each page in the SPAM interval for that SPAM page and
recalculate the fullness based on the rows stored on each
page.
2.6 – Examples
Example 1
RMU will call Rdb for each logical area that requires rebuilding.
$ RMU/SET AIP/REBUILD_SPAMS MF_PERSONNEL
%RMU-I-AIPSELMOD, Logical area id 86, name ACCOUNT_AUDIT selected for
modification
%RMU-I-AIPSELMOD, Logical area id 94, name DEPARTMENTS_INDEX selected for
modification
Example 2
RMU will request that the EMPLOYEES table length be updated
in the AIP. Oracle Rdb will use the latest table layout to
calculate the length in the AIP and write this back to the AIP.
The EMPLOYEES table is partitioned across three storage areas and
therefore the Log qualifier shows these three logical areas being
updated.
$ RMU/SET AIP MF_PERSONNEL EMPLOYEES/LENGTH/LOG
%RMU-I-AIPSELMOD, Logical area id 80, name EMPLOYEES selected for modification
%RMU-I-AIPSELMOD, Logical area id 81, name EMPLOYEES selected for modification
%RMU-I-AIPSELMOD, Logical area id 82, name EMPLOYEES selected for modification
Example 3
RMU will request that the EMPLOYEES table length be updated
in the AIP and then the SPAM pages will be rebuilt. This is an
ONLINE operation. Note: there is an implied relationship between
the logical area name and the name of the object. This example
assumes that the EMPLOYEES object is mapped to a UNIFORM page
format area.
$ RMU/SET AIP MF_PERSONNEL EMPLOYEES/LENGTH/REBUILD_SPAMS
Example 4
When Thresholds for an index are modified they will not be
effective until the SPAM pages are updated (rebuilt) to use these
new values. The following example shows that index maintenance
performed by SQL. The SET FLAGS command is used to display
information about the change. Note that the change is applied at
COMMIT time and that the SPAM rebuild is deferred until a later
time. RMU Set AIP is then used to rebuild the SPAM pages.
$ SQL$
SQL> set flags 'index_stats';
SQL> alter index candidates_sorted store in rdb$system (thresholds are (32,56,
77));
~Ai alter index "CANDIDATES_SORTED" (hashed=0, ordered=0)
~Ai larea length is 215
~As locking table "CANDIDATES" (PR -> PU)
~Ai: reads: async 0 synch 58, writes: async 8 synch 0
SQL> commit;
%RDMS-I-LOGMODVAL, modified space management thresholds to (32%, 56%, 77%)
%RDMS-W-REBUILDSPAMS, SPAM pages should be rebuilt for logical area
CANDIDATES_SORTED
$
$ RMU/SET AIP MF_PERSONNEL CANDIDATES_SORTED/REBUILD_SPAMS/LOG
%RMU-I-AIPSELMOD, Logical area id 74, name CANDIDATES_SORTED selected for
modification
3 – Audit
Enables Oracle Rdb security auditing. When security auditing is
enabled, Oracle Rdb sends security alarm messages to terminals
that have been enabled as security operators and makes entries
in the database's security audit journal whenever specified audit
events are detected.
3.1 – Description
The RMU Set Audit command is the Oracle Rdb equivalent to the
DCL SET AUDIT command. Because Oracle Rdb security auditing uses
many OpenVMS system-level auditing mechanisms, certain auditing
characteristics (such as /FAILURE_MODE) can only be set and
modified by using the DCL SET AUDIT command, which requires the
OpenVMS SECURITY privilege.
3.2 – Format
(B)0[mRMU/Set Audit root-file-spec
[4mCommand[m [4mQualifiers[m x [4mDefaults[m
x
/Disable=enable-disable-options x See description
/Enable=enable-disable-options x See description
/[No]Every x /Every
/First x Synonym for /Noevery
/[No]Flush x /Noflush
/Start x See description
/Stop x See description
/Type={Alarm|Audit} x Alarm and Audit
3.3 – Parameters
3.3.1 – root-file-spec
The file specification of the database root for which auditing
information will be modified.
3.4 – Command Qualifiers
3.4.1 – Disable
Disable=enable-disable-options
Disables security auditing for the specified audit event classes.
To disable alarms and audits for all classes, specify the All
option. You can also selectively disable alarms and audits for
one or more classes that are currently enabled. You must specify
at least one class when you specify the Disable qualifier. See
the Enable qualifier description for a list of the classes you
can specify with the Disable qualifier.
When you specify audit classes with the Disable qualifier, the
events you specify are immediately disabled. For other audit
events that have not been explicitly disabled with the Disable
qualifier, records continue to be recorded in the security
audit journal and alarms continue to be sent to security-enabled
terminals, as specified.
When processing the RMU Set Audit command, Oracle Rdb processes
the Disable qualifier last. If you accidentally specify both
Enable and Disable for the same event type in the same command,
the Disable qualifier prevails.
3.4.2 – Enable
Enable=enable-disable-options
Enables security auditing for the specified audit event classes.
To enable alarms and audits for all events, specify the All
option. You can also selectively enable alarms and audits for
one or more classes that are currently disabled. You must specify
at least one class when you specify the Enable qualifier.
When you specify audit classes with the Enable qualifier, the
audit events you specify are immediately enabled, so that audit
events of currently attached users are recorded in the security
audit journal and alarms are sent to security-enabled terminals,
as specified.
With the Enable and Disable qualifiers, you can specify one or
more of the following six valid class options: All, Daccess,
Daccess=object-type, Identifier=(identifier-list), Protection,
and Rmu. If you specify more than one class, separate the classes
with commas, and enclose the list of classes within parentheses.
The following list provides a description of each option:
o All
Enables or disables all possible audit event classes.
o Daccess
Enables or disables DACCESS (discretionary access) audit
events.
A DACCESS audit event occurs whenever a user issues a command
that causes a check to be made for the existence of the
appropriate privilege in an access privilege set (APS). To
monitor access to a particular database object or group of
objects, use the Daccess=object-type option to specify that a
DACCESS audit record be produced whenever an attempt is made
to access the object.
Specifying the general Daccess option enables or disables the
general DACCESS audit event type. If DACCESS event auditing is
enabled and started for specific objects, auditing takes place
immediately after you issue the RMU Set Audit command with
the Enable=Daccess qualifier. Auditing starts for any users
specified in the Identifier=(identifier-list) option who are
attached to the database when the command is issued.
o Daccess=object-type[=(object name)]/Privileges=(privilege-
list)
Allows you to audit access to database objects by users in the
Identifier=(identifier-list) option with the privileges you
specify.
A DACCESS type event record indicates the command issued, the
privilege used by the process issuing the command, and whether
the attempt to access the object was successful.
The object-type option enables or disables DACCESS auditing
for the specified object type. You can specify one or more
object types in an RMU Set Audit command. The three valid
object types are:
- DATABASE
When you specify the DATABASE object type, you must use the
Privileges qualifier to specify one or more privileges to
be audited for the database. Do not specify an object name
with the DATABASE object type.
- TABLE
Specify the TABLE option for both tables and views. When
you specify the TABLE object type, you must specify one or
more table names with the object name parameter. You must
also use the Privileges qualifier to specify one or more
privileges to be audited for the specified tables.
- COLUMN
When you specify the COLUMN object type, you must specify
one or more column names with the object name parameter.
Specify the table name that contains the column by using
the following syntax:
table-name.column-name
If you specify more than one column, separate the list
of table-name.column-names with commas, and enclose the
list within parentheses. You must also use the Privileges
qualifier to specify one or more privileges to be audited
for the specified columns.
The object name parameter enables or disables DACCESS auditing
for the specified object or objects. If you specify more than
one object name, separate the object names with commas, and
enclose the list of object names within parentheses.
If you specify one or more object names, you must select one
or more privileges to audit. Use the Privileges=privilege-list
qualifier to select the privileges that are to be audited for
each of the objects in the object name list when the selected
objects are accessed. The privileges that can be specified
with the Privileges qualifier are listed in DACCESS Privileges
for Database Objects.
Privilege names SUCCESS and FAILURE can be used as a
convenient way to specify that all successful or failed
accesses to that object for all privileges should be audited.
The privilege name All can be used with the Enable or Disable
qualifier to turn on or turn off auditing for all privileges
applicable to the object.
If you specify a privilege that does not apply to an object,
Oracle Rdb allows it, but will not produce any auditing for
that privilege. You can specify only SQL privileges with the
Privileges=(privilege-list) qualifier. The privileges that
can be specified for each Oracle Rdb object type are shown
in DACCESS Privileges for Database Objects. The Relational
Database Operator (RDO) privileges that correspond to
the SQL privileges are included in DACCESS Privileges for
Database Objects to help RDO users select the appropriate SQL
privileges for auditing.
Table 13 DACCESS Privileges for Database Objects
SQL RDO
Privilege Privilege Database Table/ViColumn
ALTER CHANGE Y Y N
CREATE DEFINE Y Y N
DBADM ADMINISTRATOR Y N N
DBCTRL CONTROL Y Y N
DELETE ERASE N Y N
DISTRIBTRAN DISTRIBTRAN Y N N
DROP DELETE Y Y N
INSERT WRITE N Y N
REFERENCES REFERENCES N Y Y
SECURITY SECURITY Y N N
SELECT READ Y Y N
UPDATE MODIFY N Y Y
SUCCESS SUCCESS Y Y Y
FAILURE FAILURE Y Y Y
ALL ALL Y Y Y
o Identifier=(identifier-list)
Enables or disables auditing of user access to objects listed
in the Enable=Daccess=object-type qualifier. If you do not
specify this option, no users are audited for the DACCESS
event. Any user whose identifier you specify is audited for
accessing the database objects with the privileges specified.
You can specify wildcard characters within the identifiers
to identify groups of users. The [*,*] identifier indicates
public, and causes all users to be audited. If you specify a
nonexistent identifier, you receive an error message.
The order of identifiers in the identifier list is not
significant. A user is audited if he or she holds any of the
identifiers specified in the identifier list.
You can specify user identification code (UIC) identifiers,
general identifiers, and system-defined identifiers in the
identifier list. For more information on identifiers, see the
Oracle Rdb Guide to Database Design and Definition.
If you specify more than one identifier, separate the
identifiers with commas, and enclose the identifier list
within parentheses. UIC identifiers with commas such as
[RDB,JONES] must be enclosed within quotation marks as
follows:
IDENTIFIER=(INTERACTIVE,"[RDB,JONES]",SECRETARIES)
When you use Identifier=(identifier-list) to specify one or
more identifiers to be audited, those identifiers are audited
whenever they access any object for which auditing has been
enabled.
o Protection
Allows you to audit changes made to access privilege sets
for database objects by means of the SQL GRANT and REVOKE
statements.
o Rmu
Audits the use of Oracle RMU commands by users with the
privilege to use them.
3.4.3 – Every
Noevery
Sets the granularity of DACCESS event auditing for the database.
When you specify the Every qualifier, every access check
for the specified objects using the specified privilege or
privileges during a database attachment is audited. When you
specify the Noevery qualifier, each user's first access check
for the specified audit objects using the specified privilege
or privileges during a database attachment is audited. The
First qualifier is a synonym for the Noevery qualifier; the two
qualifiers can be used interchangeably.
The default is the Every qualifier.
3.4.4 – First
Specifies that when DACCESS event auditing is enabled, each
user's first access check for the specified audit objects
using the specified privilege or privileges during a database
attachment is audited. The First qualifier is a synonym
for the Noevery qualifier; the two qualifiers can be used
interchangeably.
3.4.5 – Flush
Noflush
Indicates whether forced writes of audit journal records are
currently enabled for the database. Forced writes will cause
Oracle Rdb to write (flush) the audit journal record immediately
out to disk when the audit record is produced, rather than
waiting for the audit server to flush the audit records at
specified intervals of seconds.
The default is the Noflush qualifier, which flushes audit records
every interval of seconds. To specify the interval, use the DCL
command SET AUDIT/INTERVAL=JOURNAL_FLUSH=time.
3.4.6 – Start
Starts Oracle Rdb security auditing for the database. The Start
qualifier by itself starts both security alarms and security
audit journal records. Also, you can supply the Type=Alarm
qualifier or the Type=Audit qualifier to start security alarms
only or security audit journaling only.
When you specify the Start qualifier, auditing starts immediately
for all audit event classes that are currently enabled. Any
subsequent audit events of currently attached users are recorded
in the security audit journal, or alarms are sent to security-
enabled terminals, or both, depending on what you have specified
for your database.
3.4.7 – Stop
Stops Oracle Rdb security auditing for the database. The Stop
qualifier by itself stops both security alarms and security audit
journal records. Also, you can supply the Type=Alarm qualifier or
the Type=Audit qualifier to stop security alarms only or security
audit journaling only.
When you specify the Stop qualifier, the alarms or audits
(or both) of all audit event classes are immediately stopped
(depending on whether you specified the Type=Alarm qualifier,
the Type=Audit qualifier, or neither). The audit event classes
previously specified with the Enable qualifier remain enabled,
and you can start them again by using the Start qualifier.
3.4.8 – Type
Type=option
Specifies that security alarms or security audit journal records
(or both) be enabled or disabled. The following options are
available with the Type qualifier:
o Alarm
Causes subsequent qualifiers in the command line (Start, Stop,
Enable, and Disable) to generate or affect security alarm
messages that are sent to all terminals enabled as security
operator terminals.
o Audit
Causes subsequent qualifiers in the command line (Start,
Stop, Enable, and Disable) to generate or affect security
audit journal records that are recorded in the security audit
journal file.
If you do not specify the Type qualifier with the RMU Set
Audit command, Oracle RMU enables or disables both security
alarms and security audit journal records.
3.5 – Usage Notes
o To use the RMU Set Audit command for a database, you must
have the RMU$SECURITY privilege in the root file ACL for the
database or the OpenVMS SECURITY or BYPASS privilege.
o Audit journal records collected on a database can be stored
only in the database from which they were collected. The
database name specified with the RMU Load command with the
Audit qualifier identifies to Oracle Rdb both the audit
records to be loaded and the database into which they are
to be loaded.
o There is very little overhead associated with security
auditing; no extra disk I/O is involved. Therefore, you need
not be concerned about the impact to database performance
should you decide to enable security auditing.
o You can use the Daccess=object-type option to enable DACCESS
checking for specific objects, but the general DACCESS class
is not enabled until you explicitly enable it by using the
Enable=Daccess qualifier with the RMU Set Audit command.
Also, you need to use the Start qualifier with the RMU Set
Audit command to start the auditing and alarms that have been
enabled.
o Alarms are useful for real-time tracking of auditing
information. At the moment an alarm occurs, text messages
regarding the alarm are displayed on security-enabled
terminals.
To enable a terminal to receive Oracle Rdb security alarms,
enter the DCL REPLY/ENABLE=SECURITY command. You must have
both the OpenVMS SECURITY and OpenVMS OPER privileges to use
the REPLY/ENABLE=SECURITY command.
o Audit records are useful for periodic reviews of security
events. Audit records are stored in a security audit journal
file, and can be reviewed after they have been loaded into
a database table with the RMU Load command with the Audit
qualifier. Use the DCL SHOW AUDIT/JOURNAL command to determine
the security audit journal file being used by your database.
o The AUDIT class is always enabled for both alarms and audit
records, but does produce any alarms or audit records until
auditing is started. The AUDIT class cannot be disabled.
o When you specify the Daccess=object-type option and
one or more other options in an options list, the
Privileges=(privilege-list) qualifier must begin after the
closing parenthesis for the options list.
o To display the results of an RMU Set Audit command, enter the
RMU Show Audit command.
o You can use the Disable and Enable qualifiers with indirect
file references. See the Indirect-Command-Files help entry for
more information.
o When the RMU Set Audit command is issued for a closed
database, the command executes without other users being able
to attach to the database.
3.6 – Examples
Example 1
In the following example, the first command enables alarms
for the RMU and PROTECTION classes. The second command shows
that alarms for the RMU and PROTECTION classes are enabled but
not yet started. The AUDIT class is always enabled and cannot
be disabled. The third command starts alarms for the RMU and
PROTECTION classes. The fourth command shows that alarms for the
RMU and PROTECTION classes are enabled and started.
$ ! Enable alarms for RMU and PROTECTION classes:
$ RMU/SET AUDIT/TYPE=ALARM/ENABLE=(RMU,PROTECTION) MF_PERSONNEL
$ !
$ ! Show that alarms are enabled, but not yet started:
$ RMU/SHOW AUDIT/ALL MF_PERSONNEL
Security auditing STOPPED for:
PROTECTION (disabled)
RMU (disabled)
AUDIT (enabled)
DACCESS (disabled)
Security alarms STOPPED for:
PROTECTION (enabled)
RMU (enabled)
AUDIT (enabled)
DACCESS (disabled)
Audit flush is disabled
Audit every access
Enabled identifiers:
None
$ ! Start alarms for the enabled RMU and PROTECTION classes:
$ RMU/SET AUDIT/START/TYPE=ALARM MF_PERSONNEL
$ !
$ ! Show that alarms are started for the RMU and PROTECTION classes:
$ RMU/SHOW AUDIT/ALL MF_PERSONNEL
Security auditing STOPPED for:
PROTECTION (disabled)
RMU (disabled)
AUDIT (enabled)
DACCESS (disabled)
Security alarms STARTED for:
PROTECTION (enabled)
RMU (enabled)
AUDIT (enabled)
DACCESS (disabled)
Audit flush is disabled
Audit every access
Enabled identifiers:
None
Example 2
In this example, the first command shows that alarms are started
and enabled for the RMU class. The second command disables alarms
for the RMU class. The third command shows that alarms for RMU
class are disabled.
$ ! Show that alarms are enabled and started for the RMU class:
$ RMU/SHOW AUDIT/ALL MF_PERSONNEL
Security auditing STOPPED for:
PROTECTION (disabled)
RMU (disabled)
AUDIT (enabled)
DACCESS (disabled)
Security alarms STARTED for:
PROTECTION (disabled)
RMU (enabled)
AUDIT (enabled)
DACCESS (disabled)
Audit flush is disabled
Audit every access
Enabled identifiers:
None
$ ! Disable alarms for the RMU class:
$ RMU/SET AUDIT/TYPE=ALARM/DISABLE=RMU MF_PERSONNEL
$ !
$ ! Show that alarms are disabled for the RMU class:
$ RMU/SHOW AUDIT/ALL MF_PERSONNEL
Security auditing STOPPED for:
PROTECTION (disabled)
RMU (disabled)
AUDIT (enabled)
DACCESS (disabled)
Security alarms STARTED for:
PROTECTION (disabled)
RMU (disabled)
AUDIT (enabled)
DACCESS (disabled)
Audit flush is disabled
Audit every access
Enabled identifiers:
None
Example 3
In this example, the first command enables auditing for users
with the [SQL,USER1] and [RDB,USER2] identifiers. The second
command shows the enabled identifiers. The third command enables
DACCESS checks requiring SELECT and INSERT privileges for the
EMPLOYEES and COLLEGES tables. The fourth command displays the
DACCESS checks that have been specified for the COLLEGES and
EMPLOYEES tables. Note that because the general DACCESS type has
not been enabled, DACCESS for the EMPLOYEES and COLLEGES tables
is displayed as disabled.
$ ! Enable auditing for users with the [SQL,USER1] and
$ ! [RDB,USER2] identifiers:
$ RMU/SET AUDIT/ENABLE=IDENTIFIER=("[SQL,USER1]","[RDB,USER2]") -
_$ MF_PERSONNEL
$ !
$ ! Show that [SQL,USER1] and [RDB,USER2] are enabled identifiers:
$ RMU/SHOW AUDIT/ALL MF_PERSONNEL
Security auditing STOPPED for:
PROTECTION (disabled)
RMU (disabled)
AUDIT (enabled)
DACCESS (disabled)
Security alarms STOPPED for:
PROTECTION (disabled)
RMU (disabled)
AUDIT (enabled)
DACCESS (disabled)
Audit flush is disabled
Audit every access
Enabled identifiers:
(IDENTIFIER=[SQL,USER1])
(IDENTIFIER=[RDB,USER2])
$ ! Enable and start DACCESS checks for the SELECT and INSERT
$ ! privileges for the COLLEGES and EMPLOYEES tables:
$ RMU/SET AUDIT/ENABLE=DACCESS=TABLE=(COLLEGES,EMPLOYEES) -
_$ /PRIVILEGES=(SELECT,INSERT)/START MF_PERSONNEL
$ !
$ ! Display the DACCESS checks that are enabled and
$ ! started for the COLLEGES and EMPLOYEES tables:
$ RMU/SHOW AUDIT/DACCESS=TABLE MF_PERSONNEL
Security auditing STARTED for:
DACCESS (disabled)
TABLE : EMPLOYEES
(SELECT,INSERT)
TABLE : COLLEGES
(SELECT,INSERT)
Security alarms STARTED for:
DACCESS (disabled)
TABLE : EMPLOYEES
(SELECT,INSERT)
TABLE : COLLEGES
(SELECT,INSERT)
Example 4
In this example, the first command enables auditing of the JOBS
and EMPLOYEES tables for DACCESS checks for users with the
[SQL,USER1] or BATCH identifier. The Privileges=All qualifier
specifies that auditing will be produced for every privilege.
The second command shows that auditing is enabled for users
with the [SQL,USER1] or BATCH identifier. The third command
shows that DACCESS checking for the JOBS and EMPLOYEES tables
for all privileges is specified. The fourth command enables the
general DACCESS class. The fifth command's output shows that the
general DACCESS class is now enabled. The sixth command starts
the auditing that is enabled, and the seventh command shows that
the enabled auditing is started.
$ ! Enable DACCESS checks for users with the [SQL,USER1] or
$ ! BATCH identifier for the JOBS and EMPLOYEES tables:
$ RMU/SET AUDIT/TYPE=AUDIT -
_$ /ENABLE=(IDENTIFIER=("[SQL,USER1]",BATCH), -
_$ DACCESS=TABLE=(JOBS,EMPLOYEES)) /PRIVILEGES=ALL MF_PERSONNEL
$ !
$ ! Show that auditing is enabled for users with the [SQL,USER1]
$ ! or BATCH identifiers:
$ RMU/SHOW AUDIT/ALL MF_PERSONNEL
Security auditing STOPPED for:
PROTECTION (disabled)
RMU (disabled)
AUDIT (enabled)
DACCESS (disabled)
Security alarms STOPPED for:
PROTECTION (disabled)
RMU (disabled)
AUDIT (enabled)
DACCESS (disabled)
Audit flush is disabled
Audit every access
Enabled identifiers:
(IDENTIFIER=[SQL,USER1])
(IDENTIFIER=BATCH)
$ ! Show that DACCESS checking for all privileges for the
$ ! JOBS and EMPLOYEES tables is enabled:
$ RMU/SHOW AUDIT/DACCESS=TABLE MF_PERSONNEL
Security auditing STOPPED for:
DACCESS (disabled)
TABLE : EMPLOYEES
(ALL)
TABLE : JOBS
(ALL)
Security alarms STOPPED for:
DACCESS (disabled)
$ ! Enable the general DACCESS class:
$ RMU/SET AUDIT/ENABLE=DACCESS MF_PERSONNEL
$ !
$ ! Show that the general DACCESS class is enabled:
$ RMU/SHOW AUDIT/DACCESS=TABLE MF_PERSONNEL
Security auditing STOPPED for:
DACCESS (enabled)
TABLE : EMPLOYEES
(ALL)
TABLE : JOBS
(ALL)
Security alarms STOPPED for:
DACCESS (enabled)
$ ! Start the auditing that is enabled:
$ RMU/SET AUDIT/START MF_PERSONNEL
$ !
$ ! Show that the enabled auditing is started:
$ RMU/SHOW AUDIT/ALL MF_PERSONNEL
Security auditing STARTED for:
PROTECTION (disabled)
RMU (disabled)
AUDIT (enabled)
DACCESS (enabled)
Security alarms STARTED for:
PROTECTION (disabled)
RMU (disabled)
AUDIT (enabled)
DACCESS (enabled)
Audit flush is disabled
Audit every access
Enabled identifiers:
(IDENTIFIER=[SQL,USER1])
(IDENTIFIER=BATCH)
Example 5
In this example, the first command enables DACCESS checks
requiring the INSERT privilege for the mf_personnel database,
for the EMPLOYEES table, and for the EMPLOYEE_ID column of the
EMPLOYEES table. The second command shows that the DACCESS check
for the INSERT privilege is enabled for the specified objects.
$ ! Enable a DACCESS check for the INSERT privilege for the
$ ! MF_PERSONNEL database, EMPLOYEES table, and EMPLOYEE_ID
$ ! column of the EMPLOYEES table:
$ RMU/SET AUDIT -
_$ /ENABLE=DACCESS=(DATABASE,TABLE=EMPLOYEES, -
_$ COLUMN=EMPLOYEES.EMPLOYEE_ID) -
_$ /PRIVILEGES=(INSERT) MF_PERSONNEL
$ !
$ ! Show that the DACCESS check for the INSERT privilege is
$ ! enabled for the specified objects. (The general DACCESS
$ ! class remains disabled until you issue an
$ ! RMU/SET AUDIT/ENABLE=Daccess command without specifying
$ ! any object-type parameter to the Daccess option.
$ ! See the fourth Oracle RMU command in Example 4.)
$ !
$ RMU/SHOW AUDIT/DACCESS=(DATABASE,TABLE,COLUMN) MF_PERSONNEL
Security auditing STOPPED for:
DACCESS (disabled)
DATABASE
(INSERT)
TABLE : EMPLOYEES
(INSERT)
COLUMN : EMPLOYEES.EMPLOYEE_ID
(INSERT)
Security alarms STOPPED for:
DACCESS (disabled)
DATABASE
(INSERT)
TABLE : EMPLOYEES
(INSERT)
COLUMN : EMPLOYEES.EMPLOYEE_ID
(INSERT)
Example 6
In this example, the first command enables a DACCESS check
requiring the INSERT privilege for the EMPLOYEES and COLLEGES
tables, as well as for the EMPLOYEE_ID and LAST_NAME columns of
the EMPLOYEES table and the COLLEGE_CODE column of the COLLEGES
table in the mf_personnel database. The second command shows that
the DACCESS check for the INSERT privilege is enabled for the
specified objects.
$ ! Enable a DACCESS check for the INSERT privilege for the
$ ! EMPLOYEES and COLLEGES table, the LAST_NAME and EMPLOYEE_ID
$ ! column of the EMPLOYEES table, and the COLLEGE_CODE column
$ ! of the COLLEGES table:
$ RMU/SET AUDIT -
_$ /ENABLE=DACCESS=(TABLE=(EMPLOYEES,COLLEGES), -
_$ COLUMN=(EMPLOYEES.EMPLOYEE_ID, -
_$ EMPLOYEES.LAST_NAME, -
_$ COLLEGES.COLLEGE_CODE)) -
_$ /PRIVILEGES=(INSERT) MF_PERSONNEL
$ !
$ ! Show that the DACCESS check for the INSERT privilege is
$ ! enabled for the specified objects. (The general DACCESS
$ ! class remains disabled until you issue an
$ ! RMU/SET AUDIT/ENABLE=Daccess command without specifying
$ ! any object-type parameter to the Daccess option.
$ ! See the fourth Oracle RMU command in Example 4.)
$ !
$ RMU/SHOW AUDIT/DACCESS=(DATABASE,TABLE,COLUMN) MF_PERSONNEL
Security auditing STOPPED for:
DACCESS (disabled)
DATABASE
(NONE)
TABLE : COLLEGES
(INSERT)
TABLE : EMPLOYEES
(INSERT)
COLUMN : COLLEGES.COLLEGE_CODE
(INSERT)
COLUMN : EMPLOYEES.EMPLOYEE_ID
(INSERT)
COLUMN : EMPLOYEES.LAST_NAME
(INSERT)
Security alarms STOPPED for:
DACCESS (disabled)
DATABASE
(NONE)
TABLE : COLLEGES
(INSERT)
TABLE : EMPLOYEES
(INSERT)
COLUMN : COLLEGES.COLLEGE_CODE
(INSERT)
COLUMN : EMPLOYEES.EMPLOYEE_ID
(INSERT)
COLUMN : EMPLOYEES.LAST_NAME
(INSERT)
4 – Buffer Object
On a database basis, controls which database objects use the
OpenVMS Fast I/O and Buffer Objects features.
4.1 – Description
Use the RMU Set Buffer_Object command to control, on a database
basis, which database objects use the OpenVMS Fast I/O and Buffer
Objects features.
4.2 – Format
(B)0[mRMU/Set Buffer_Object root-file-spec
[4mCommand[m [4mQualifiers[m x [4mDefaults[m
x
/Disable=enable-disable-options x See description
/Enable=enable-disable-options x See description
/[No]Log x Current DCL verify value
4.3 – Parameters
4.3.1 – root-file-spec
The root file specification of the database. The default file
extension is .rdb.
4.4 – Command Qualifiers
4.4.1 – Disable
Disable=enable-disable-options
Disables buffer objects for the specified Oracle Rdb buffers.
You can specify one or more of the following buffer objects:
Page, AIJ, RUJ, and Root. Refer to Buffer Object Control for more
information about these keywords. If you specify more than one
object, separate the objects with commas, and enclose the list of
objects within parentheses.
4.4.2 – Enable
Enable=enable-disable-options
Enables buffer objects for the specified Oracle Rdb buffers.
You can specify one or more of the following buffer objects:
Page, AIJ, RUJ, and Root. Refer to Buffer Object Control for more
information about these keywords. If you specify more than one
object, separate the objects with commas, and enclose the list of
objects within parentheses.
If you specify the Enable and Disable qualifiers for the same
buffer object, the Enable option prevails and the buffer object
state is enabled for the specified object type.
Table 14 Buffer Object Control
Object Keyword Logical Name
Data PAGE RDM$BIND_PAGE_BUFOBJ_ENABLED
pages
AIJ AIJ RDM$BIND_AIJ_BUFOBJ_ENABLED
output
RUJ RUJ RDM$BIND_RUJ_BUFOBJ_ENABLED
Root ROOT RDM$BIND_ROOT_BUFOBJ_ENABLED
file
NOTE
If a logical is defined as "1" then the corresponding buffer
will be created as an OpenVMS buffer object.
4.4.3 – Log
Log
Nolog
Specifies whether the processing of the command is reported to
SYS$OUTPUT. Specify the Log qualifier to request log output and
the Nolog qualifier to prevent it. If you specify neither, the
default is the current setting of the DCL verify switch.
4.5 – Usage Notes
o The Enable and Disable qualifiers are mutually exclusive.
o The RMU Set Buffer_Object command requires exclusive database
access; that is, the database cannot be open or be accessed by
other users.
o Buffer objects are memory resident and thus reduce the amount
of physical memory available to OpenVMS for other uses. Buffer
object use requires that the user be granted the VMS$BUFFER_
OBJECT_USER rights identifier. The system parameter MAXBOBMEM
needs to be large enough to allow all buffer objects for all
users to be created. For further information regarding Fast
I/O, consult the OpenVMS documentation.
4.6 – Example
The following example demonstrates enabling ROOT buffer objects
and disabling PAGE buffer objects. The RMU /DUMP /HEADER command
is used to validate the change.
$RMU /SET BUFFER_OBJECT /ENABLE=(ROOT) /DISABLE=(PAGE) MF_PERSONNEL
%RMU-I-MODIFIED, Buffer objects state modified
%RMU-W-DOFULLBCK, full database backup should be done to ensure futur
$ RMU/DUMP/HEAD MF_PERSONNEL
.
.
.
- OpenVMS Alpha Buffer Objects are enabled for
Root I/O Buffers
5 – Corrupt Pages
Allows you to set pages, storage areas, and snapshot files
as either corrupt or consistent in the corrupt page table
(CPT). A corrupt page is one that contains meaningless data; an
inconsistent page is one that contains old data (data that is not
at the same transaction level as the database root file). Corrupt
pages are logged to the CPT, which is maintained in the database
root file. When the CPT becomes full (due to a large number of
pages being logged), the area containing the most corrupt pages
is marked as corrupt and the individual corrupt pages for that
area are removed from the corrupt page table. The Oracle RMU Set
Corrupt_Pages operation is an offline operation.
If you reset a page or storage area in the CPT to consistent it
does not remove any true corruption or inconsistencies. However,
if you reset a snapshot file in the CPT to consistent, Oracle
RMU initializes the snapshot file and thus removes any true
corruption or inconsistency.
CAUTION
Use the RMU Set Corrupt_Pages command only after you
fully understand the internal data structure and know the
information the database should contain. Setting a page
in a storage area that is truly corrupt or inconsistent to
consistent does not remove the corruption or inconsistency.
Setting truly corrupt or inconsistent pages in a storage
area to consistent and continuing to access those pages can
result in unrecoverable corruptions to the database.
The RMU Restore and RMU Recover commands should be used
first and should be part of your normal operating procedure.
NOTE
This command replaces two RdbALTER statements: MAKE
CONSISTENT and UNCORRUPT. Both the RdbAlter statements,
MAKE CONSISTENT and UNCORRUPT, are deprecated commands that
may be removed in future versions.
When a storage area is restored from backup files on a by-area
basis, it does not reflect data that has been updated since
the backup operation. The transaction level of the restored
area reflects the transaction level of the backup file, not the
transaction level of the database. Therefore, the transaction
level of the restored area differs from that of the database.
Oracle Rdb marks the area by setting a flag in the storage area
file to inconsistent.
You can perform a recovery by area to upgrade the transaction
level of the restored area to that of the database. (After-
image journaling must be enabled in order to restore by area.)
If you are certain that no updates have been made to the database
since the backup operation, you can use the RMU Set Corrupt_Pages
command to change the setting of the flag from inconsistent to
consistent.
In addition, storage areas are corrupted by attempting an SQL
rollback with one or more storage areas opened in batch-update
transaction mode.
The RMU Set Corrupt_Pages command allows you to access a database
that is in an uncertain condition. Accordingly, the following
message and question are displayed when you enter it to correct a
corrupt or inconsistent storage area or storage area page. (This
message is not displayed if you enter it to correct a corrupt or
inconsistent snapshot file.)
***** WARNING! *****
Marking a storage area or page consistent does not
remove the inconsistencies. Remove any inconsistencies
or corruptions before you proceed with this action.
Do you wish to continue? [N]
5.1 – Description
The RMU Set Corrupt_Pages command allows you to override the
required RMU Recover command after a by-area restore operation.
Although Oracle RMU cannot determine when the recover operation
is superfluous, you might have that knowledge. If you are certain
of this knowledge, you can abridge the requirement for the
recover operation by using the RMU Set Corrupt_Pages command
to set corrupt pages to consistent.
Similarly, sometimes you might know of a problem that Oracle
RMU does not recognize. For example, you might find that a page
contains an index node that causes a bugcheck dump each time it
is accessed. You can use the RMU Set Corrupt_Pages command to
mark this page as corrupt and then follow your usual procedure
for recovering from database corruption.
Note that the RMU Set Corrupt_Pages command with the Consistent
qualifier does not make truly corrupt storage area pages usable.
Corrupt storage area pages detected during normal operation are
logged in the CPT, and likely have an invalid checksum value.
The RMU Set Corrupt_Pages command with the Consistent qualifier
removes the specified pages from the CPT, but the next time a
user tries to touch that storage area page, it is logged in the
CPT again because it is still physically corrupt. To correct a
storage area page that is truly corrupt, you must restore it from
a backup file.
The RMU Set Corrupt_Pages command with the Consistent qualifier
does make truly corrupt or inconsistent pages in a snapshot file
usable. When you use this command and specify a snapshot file
with the areas qualifier, Oracle RMU initializes the specified
snapshot file.
5.2 – Format
(B)0[mRMU/Set Corrupt_Pages root-file-spec
[4mCommand[m [4mQualifiers[m x [4mDefaults[m
x
/Area=identity x None
/Consistent x None
/Corrupt x None
/Disk=device x None
/Page=(n,...) x None
5.3 – Parameters
5.3.1 – root-file-spec
The file specification of the database root file for which you
want to set pages or areas to corrupt or consistent.
5.4 – Command Qualifiers
5.4.1 – Area
Area=identity
Specifies a particular storage area file or snapshot file. The
identity for a storage area can be either the area name (for
example, EMPIDS_OVER), or a storage area ID number (for example,
5). The identity for a snapshot file must be the snapshot file
ID number. Use the RMU Dump command with the Header qualifier to
display the ID numbers associated with a storage area file or a
snapshot file.
When you use the Area qualifier with the Page=(n,...) qualifier,
the command specifies the named pages in the named storage area
or snapshot file. When you specify the Area qualifier without the
Page qualifier, the command specifies all pages of the specified
storage area or snapshot file.
The Area qualifier cannot be used with the Disk qualifier.
5.4.2 – Consistent
Consistent
Specifies that the pages, areas, or snapshot files specified with
the Page, Area, or Disk qualifier are to be considered consistent
with the remainder of the database.
If you make a storage area or page in a storage area consistent
while it is marked in the database as not corrupt, but
inconsistent, you receive a warning and are required to confirm
your request to carry out this operation before the operation
will complete.
You cannot use the Consistent qualifier with the Corrupt
qualifier.
5.4.3 – Corrupt
Corrupt
Specifies that the pages, areas, or snapshot files specified with
the Page, Area, or Disk qualifier are to be considered corrupt.
You cannot use the Corrupt qualifier with the Consistent
qualifier.
5.4.4 – Disk
Disk=device
Specifies all the pages, all the storage areas, and all the
snapshot files on the named device be set as you indicate with
the Corrupt or the Consistent qualifier.
You cannot use the Disk qualifier with the Page or the Area
qualifier.
5.4.5 – Page
Page=(n,...)
Specifies the listed page numbers.
You must specify the Area qualifier when you use the Page
qualifier.
You cannot use the Page qualifier with the Disk qualifier.
5.5 – Usage Notes
o You must have the RMU$ALTER, RMU$BACKUP, or RMU$RESTORE
privilege in the root file access control list (ACL) for a
database or the OpenVMS SYSPRV or BYPASS privilege to use the
RMU Set Corrupt_Pages command for the database.
o You can issue the RMU Set Corrupt_Pages command while users
are attached to the database.
o You must specify either the Corrupt or the Consistent
qualifier (but not both) when you use the RMU Set Corrupt_
Pages command.
o When you use the RMU Set Corrupt_Pages command to mark a page
as corrupt or consistent, the database is marked as having
been altered.
5.6 – Examples
Example 1
The following command sets storage area EMPIDS_MID in the mf_
personnel database as corrupt:
$ RMU/SET CORRUPT_PAGES/AREA=EMPIDS_MID/CORRUPT MF_PERSONNEL
%RMU-I-AREAMARKED, Area 4 was marked corrupt.
Example 2
The following command marks EMPIDS_MID as consistent. This is the
area that was marked as corrupt in Example 1. However, in this
case, instead of using the storage area name in the Oracle RMU
command, the storage area identifier is used.
$ RMU/SET CORRUPT_PAGES/AREA=4/CONSISTENT MF_PERSONNEL
***** WARNING! *****
Marking a storage area or page consistent does not
remove the inconsistencies. Remove any inconsistencies
or corruptions before you proceed with this action.
Do you wish to continue? [N] Y
%RMU-I-AREAMARKED, Area 4 was marked consistent .
Example 3
The following command marks page 1 in area 3 in the mf_personnel
database as corrupt. Using the RMU Show Corrupt_Pages command
confirms that the page has been marked as expected.
$ RMU/SET CORRUPT_PAGES/AREA=3/PAGE=1/CORRUPT MF_PERSONNEL
%RMU-I-PAGEMARKED, Page 1 in area 3 was marked corrupt.
$ RMU/SHOW CORRUPT_PAGES MF_PERSONNEL.RDB
*--------------------------------------------------------------------
* Oracle Rdb V7.0-00 3-JUL-1996 17:01:20.62
*
* Dump of Corrupt Page Table
* Database: USER1:[DB]MF_PERSONNEL.RDB;1
*
*--------------------------------------------------------------------
Entries for storage area EMPIDS_LOW
-----------------------------------
Page 1
- AIJ recovery sequence number is -1
- Live area ID number is 3
- Consistency transaction sequence number is 0:0
- State of page is: corrupt
*--------------------------------------------------------------------
* Oracle Rdb V7.0-00 3-JUL-1996 17:01:20.82
*
* Dump of Storage Area State Information
* Database: USER1:[DB]MF_PERSONNEL.RDB;1
*
*--------------------------------------------------------------------
All storage areas are consistent.
Example 4
The following example sets page 4 of the snapshot file for
EMPIDS_OVER to consistent. Because Oracle RMU initializes
snapshot files specified with the Set Corrupt_Pages command,
the snapshot file is removed from the corrupt page table and is
now usable.
$ RMU/SET CORRUPT_PAGES MF_PERSONNEL.RDB/AREA=14/PAGE=3/CONSISTENT
%RMU-I-PAGEMARKED, Page 3 in area 14 was marked consistent.
6 – Database
Allows you to alter the database-allowed transaction modes
without marking the database as modified.
6.1 – Description
The RMU /SET command "DATABASE /TRANSACTION_MODE=(...)" allows
altering of the database-allowed transaction modes without
marking the database as modified. This command is intended to be
used to set the transaction modes allowed on a standby database.
This command requires exclusive database access (the database
cannot be open or be accessed by other users).
Because only read-only transactions are allowed on a standby
database, you may wish to use the TRANSACTION_MODE=READ_ONLY
qualifier setting on a standby database. This setting prevents
modifications to the standby database at all times, even when
replication operations are not active.
The RMU /SET DATABASE command requires a database specification.
Valid keywords for the RMU /SET DATABASE /TRANSACTION_MODE=(...)
qualifier are:
o ALL - Enables all transaction modes
o CURRENT - Enables all transaction modes that are set in the
database
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, 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.
6.2 – Format
(B)0[m RMU/Set Database /Transaction_Mode=[mode] root-file-spec
6.3 – Parameters
6.3.1 – root-file-spec
Specifies the database root file for which you want to specify
the database transaction mode.
7 – Galaxy
Allows you to enable or disable the database utilization of an
OpenVMS Galaxy configuration without requiring that the database
be open.
7.1 – Description
Use this command to enable or disable Galaxy features on an
Oracle Rdb database. Databases opened on multiple copies of the
OpenVMS operating system within a Galaxy system can share, in
memory, database structures including global buffers, row caches,
and root file objects.
7.2 – Format
(B)0[mRMU/Set Galaxy root-file-spec
[4mCommand[m [4mQualifiers[m x [4mDefaults[m
x
/Disable x See description
/Enable x See description
/[No]Log x Current DCL verify value
7.3 – Parameters
7.3.1 – root-file-spec
The root file specification of the database. The default file
extension is .rdb.
7.4 – Command Qualifiers
7.4.1 – Disable
Specifies that Galaxy features are to be disabled for the
database.
7.4.2 – Enable
Specifies that Galaxy features are to be enabled for the
database.
7.4.3 – Log
Log
Nolog
Displays a log message at the completion of the RMU Set Galaxy
operation.
7.5 – Usage Notes
o The Enable and Disable qualifiers are mutually exclusive.
o The RMU Set Galaxy command requires exclusive database access;
that is, the database cannot be open or be accessed by other
users.
7.6 – Example
The following example enables the Galaxy features for the
specified database.
$ RMU /SET GALAXY /ENABLE root-file-spec
8 – Global Buffers
Allows you to control the database global buffers feature without
requiring that the database be open.
8.1 – Description
If you move a database from one system to another, or when memory
usage or system parameters change, you may have to modify the
global buffer parameters for a database when it is not possible
to open the database. This situation could occur, for example, if
you have insufficient available physical or virtual memory.
The RMU Set Global_Buffers command allows you to alter some
of the global buffer-related parameters without opening the
database. This allows you to reconfigure the database so that
it can be opened and accessed on the system.
8.2 – Format
(B)0[mRMU/Set Global_Buffers root-file-spec
[4mCommand[m [4mQualifiers[m x [4mDefaults[m
x
/Disabled x None
/Enabled x None
/Large_Memory={Enabled|Disabled} x None
/Log x None
/Number=n x None
/User_Limit=n x None
8.3 – Parameters
8.3.1 – root-file-spec
Specifies the database root file for which you want to modify the
global buffers feature.
8.4 – Command Qualifiers
8.4.1 – Disabled
Disables global buffers for the specified database.
8.4.2 – Enabled
Enables global buffers for the specified database.
8.4.3 – Large Memory
Large_Memory=Enabled
Large_Memory=Disabled
Large_Memory=Enabled enables global buffers in large memory
(VLM).
Large_Memory=Disabled disables global buffers in large memory
(VLM).
8.4.4 – Log
Displays a log message at the completion of the RMU Set Global_
Buffers command.
8.4.5 – Number
Number=n
Sets the number of global buffers.
8.4.6 – User Limit
User_Limit=n
Sets the global buffers user limit value.
8.5 – Usage Notes
o This command requires exclusive database access (the database
cannot be open or accessed by other users).
o The Enabled and Disabled qualifiers are mutually exclusive.
o The Large_Memory=Enabled and Large_Memory=Disabled qualifiers
are mutually exclusive.
o Changes made by the RMU Set Global_Buffers command are not
journaled. You should make a subsequent full database backup
to ensure recovery.
o When global buffers are set to reside in large memory
(Large_Memory=Enabled), the process that opens the database
must be granted the VMS$MEM_RESIDENT_USER rights identifier.
Oracle Corporation recommends that you use the RMU Open
command when you utilize this feature.
9 – Logminer
Allows you to change the LogMiner state of a database.
9.1 – Description
Use this command to enable or disable LogMiner operations on an
Oracle Rdb database. When LogMiner is enabled, the Oracle Rdb
database software writes additional information to the after-
image journal file when records are added, modified, and deleted
from the database. This information is used during the unload
operation.
9.2 – Format
(B)0[m RMU/Set Logminer root-file-spec
[4mCommand[m [4mQualifiers[m x [4mDefaults[m
x
/Continuous x /NoContinuous
/Disable x See description
/Enable x See description
/[No]Log x Current DCL verify value
9.3 – Parameters
9.3.1 – root-file-spec
The root file specification of the database. The default file
extension is .rdb.
9.4 – Command Qualifiers
9.4.1 – Continuous
Continuous
Nocontinuous
Enables the database for the Continuous LogMiner feature
when used in conjunction with the Enable qualifier. Use the
NoContinuous qualifier with the Enable qualifier to disable use
of the Continuous LogMiner feature.
The RMU Set Logminer /Disable command explicitly disables
the Continuous LogMiner feature as well as the base LogMiner
functionality. To enable the Continuous LogMiner feature again,
the entire RMU Set Logminer /Enable /Continuous command must be
used.
9.4.2 – Disable
Specifies that LogMiner operations are to be disabled for the
database. When LogMiner is disabled, the Oracle Rdb software does
not journal information required for LogMiner operations. When
LogMiner is disabled for a database, the RMU Unload After_Journal
command is not functional on that database.
9.4.3 – Enable
Specifies that LogMiner operations are to be enabled for the
database. When LogMiner is enabled, the Oracle Rdb database
software logs additional information to the after-image journal
file. This information allows LogMiner to extract records. The
database must already have after-image journaling enabled.
9.4.4 – Log
Log
Nolog
Specifies that the setting of the LogMiner state for the database
be reported to SYS$OUTPUT. The default is the setting of the DCL
VERIFY flag, which is controlled by the DCL SET VERIFY command.
9.5 – Usage Notes
o To use the RMU Set Logminer command, you must have the
RMU$BACKUP, RMU$RESTORE, or RMU$ALTER privilege in the root
file access control list (ACL) for the database or the OpenVMS
SYSPRV or BYPASS privilege.
o The RMU Set Logminer command requires offline access to the
database. The database must be closed and no other users may
be accessing the database.
o Execute a full database backup operation after issuing an
RMU Set Logminer command that displays the RMU-W-DOFULLBCK
warning message. Immediately after enabling LogMiner, you
should perform a database after-image journal backup using the
RMU Backup After_Journal command.
9.6 – Examples
Example 1
The following example enables a database for LogMiner for Rdb
operation.
$ RMU /SET LOGMINER /ENABLE OLTPDB.RDB
10 – Privilege
Allows you to modify the root file access control list (ACL) for
a database.
A database's root file ACL determines the Oracle RMU commands
that users can execute for the associated database.
10.1 – Description
The RMU Set Privilege command allows you to manipulate an entire
root file ACL, or to create, modify, or delete access control
entries (ACEs) in a root file ACL. See the Oracle Rdb Guide to
Database Design and Definition for introductory information on
ACEs and ACLs.
Use the RMU Set Privilege command to add ACEs to a root file ACL
by specifying the ACEs with the Acl qualifier.
Privileges Required for Oracle RMU Commands shows the privileges
a user must have to access each Oracle RMU command.
If the database root file you specify with RMU Set Privilege
command does not have an ACL, Oracle RMU creates one.
The RMU Set Privilege command provides the following qualifiers
to manipulate ACEs and ACLs in various ways:
After
Delete
Like
New
Replace
By default, any ACEs you add to a root file ACL are placed at
the top of the ACL. Whenever Oracle RMU receives a request
for Oracle RMU access for a database that has a root file ACL,
it searches each entry in the ACL from the first to the last
for the first match it can find, and then stops searching. If
another match occurs further down in the root file ACL, it has no
effect. Because the position of an ACE in a root file ACL is so
important, you can use the After qualifier to correctly position
an ACE. When you use the After qualifier, any additional ACEs are
added after the specified ACE.
You can delete ACEs from an ACL by including the Delete qualifier
and specifying the ACEs with the Acl qualifier. To delete all the
ACEs, include the Delete qualifier and specify the Acl qualifier
without specifying any ACEs.
You can copy an ACL from one root file to another by using the
Like qualifier. The ACL of the root file specified with the Like
qualifier replaces the ACL of the root file specified with the
root-file-spec parameter.
Use the New qualifier to delete all ACEs before adding any ACEs
specified by the Acl, Like, or Replace qualifiers.
You can replace existing ACEs in a root file ACL by using the
Replace qualifier. Any ACEs specified with the Acl qualifier
are deleted and replaced by those specified with the Replace
qualifier.
The existing ACE can be abbreviated when you use the Delete,
Replace, or After qualifiers.
Use the RMU Set Privilege command with the Edit qualifier to
invoke the ACL editor. You can specify the following qualifiers
only when you specify the Edit qualifier also:
Journal
Keep
Mode
Recover
For more information on the ACL editor, see the OpenVMS
documentation set.
10.2 – Format
(B)0[mRMU/Set Privilege root-file-spec
[4mCommand[m [4mQualifiers[m x [4mDefaults[m
x
/Acl[=(ace[,...])] x See description
/Acl_File=filename x See description
/After=ace x See description
/Delete[=All] x See description
/Edit x No editor invoked
/[No]Journal[=file-spec] x /Journal
/Keep[=(Recovery_Journal)] x See description
/Like=source-root-file-spec x None
/[No]Log x /Nolog
/Mode=[No]Prompt x /Mode=Prompt
/New x None
/[No]Recover[=file-spec] x /Norecover
/Replace=(ace[,...]) x None
10.3 – Parameters
10.3.1 – root-file-spec
The root file for the database whose root file ACL you are
modifying.
10.4 – Command Qualifiers
10.4.1 – Acl
Acl[=(ace[,...])]
Specifies one or more ACEs to be modified. When no ACE is
specified, the entire ACL is affected. Separate multiple ACEs
with commas. When you include the Acl qualifier, the specified
ACEs are inserted at the top of the ACL unless you also specify
the After qualifier. You cannot specify the Acl qualifier and the
Acl_File qualifier on the same RMU command line.
The format of an ACE is as follows:
(Identifier=user-id, Access=access_mask)
The user-id must be one of the following types of identifier:
o A user identification code (UIC) in [group-name,member-name]
alphanumeric format
o A user identification code (UIC) in [group-number,member-
number] numeric format
o A general identifier, such as SECRETARIES
o A system-defined identifier, such as DIALUP
o Wildcard characters in [*,*] format
Names are not case sensitive. In addition, the Identifier and
Access keywords can be abbreviated to one character. For example,
the following ACE is valid:
(I=isteward, A=RMU$ALL)
The access_mask can be any of the following:
o One or more of the Oracle RMU privileges listed in the Oracle
Rdb7 Oracle RMU Reference Manual
If more than one privilege is specified, a plus sign (+) must
be placed between the privileges.
o The keyword RMU$ALL
These keywords indicate that you want the user to have all of
the RMU privileges. (This keyword has no effect on system file
privileges.)
o The keyword None
This keyword indicates that you do not want the user
to have any RMU or OpenVMS privileges. If you specify
Acl=(id=username, access=READ+NONE), the specified user will
have no RMU privileges and no READ privileges for the database
files.
10.4.2 – Acl File
Acl_File=filename
Specifies a file containing a list of ACEs, with one ACE
specified per line. You can use continuation characters to
continue an ACE on the next line, and you can include commented
lines within the file. Within this file, use the dash (-) as a
continuation character and the exclamation point (!) to indicate
a comment.
You cannot specify the Acl_File qualifier and the Acl qualifier
on the same RMU command line.
10.4.3 – After
After=ace
Indicates that all ACEs specified with the Acl qualifier are to
be added after the ACE specified with the After qualifier. By
default, any ACEs added to the ACL are always placed at the top
of the list.
You cannot use this qualifier with the Edit qualifier.
10.4.4 – Delete
Delete[=All]
Indicates that the ACEs specified with the Acl qualifier are
to be deleted. If no ACEs are specified with the Acl qualifier,
the entire ACL is deleted. If you specify an ACE that was not
specified with the Acl qualifier, you are notified that the ACE
does not exist, and the delete operation continues.
You cannot use this qualifier with the Edit qualifier.
10.4.5 – Edit
Edit
Invokes the ACL editor and allows you to use the Journal,
Keep, Mode, or Recover qualifiers. Oracle RMU ignores any other
qualifiers you specify with the Edit qualifier.
The RMU Set Privilege command with the Edit qualifier only
functions off line. If you attempt it on line, an error message
is generated. This restriction is necessary because the ACL
editor requests exclusive write access to the database.
To use the Edit qualifier, the SYS$SHARE:ACLEDTSHR.EXE image
must be installed at system startup time, or, be installed by
RMONSTART.COM. Contact your system manager if this image is not
installed as needed.
For more information on the ACL editor, see the OpenVMS
documentation set.
10.4.6 – Journal
Journal[=file-spec]
Nojournal
Controls whether a journal file is created from the editing
session. By default, a journal file is created if the editing
session ends abnormally.
If you omit the file specification, the journal file has the
same name as the root file and a file type of .tjl. You can use
the Journal qualifier to specify a journal file name that is
different from the default. No wildcard characters are allowed in
the Journal qualifier file-spec parameter.
You must specify the Edit qualifier to use this qualifier.
10.4.7 – Keep
Keep[=(Recovery,Journal)]
Determines whether the journal file, the recovery file, or both,
are deleted when the editing session ends. The options are:
o Recovery-Saves the journal file used for restoring the ACL.
o Journal-Saves the journal file for the current editing
session.
You can shorten the Journal and Recover options to J and R,
respectively. If you specify only one option, you can omit the
parentheses.
You must specify the Edit qualifier to use this qualifier. If you
specify the Edit qualifier but do not specify the Keep qualifier,
both the journal file for the current editing session and the
journal file used for restoring the ACL are deleted when the
editing session ends.
10.4.8 – Like
Like=source-root-file-spec
Indicates that the ACL of the root file specified with the Like
qualifier is to replace the ACL of the root file specified with
the root-file-spec parameter of the RMU Set Privilege command.
Any existing ACEs are deleted before the root file ACL specified
by the Like qualifier is copied.
You cannot use this qualifier with the Edit qualifier.
10.4.9 – Log
Log
Nolog
Directs the RMU Set Privilege command to return both the name of
the root file that has been modified by the command and the ACL
associated with the database. The default of Nolog suppresses
this output.
You cannot use this qualifier with the Edit qualifier.
10.4.10 – Mode
Mode=[No]Prompt
Determines whether the ACL editor prompts for field values. By
default, the ACL editor selects prompt mode.
You must specify the Edit qualifier to use this qualifier.
10.4.11 – New
New
Indicates that any existing ACE in the ACL of the root file
specified with RMU Set Privilege is to be deleted. To use the
New qualifier, you must specify a new ACL or ACE with the Acl,
Like, or Replace qualifiers.
You cannot use this qualifier with the Edit qualifier.
10.4.12 – Recover
Recover[=file-spec]
Norecover
Specifies the name of the journal file to be used in a recovery
operation. If the file specification is omitted with the Recover
qualifier, the journal is assumed to have the same name as the
root file and a file type of .tjl. No wildcard characters are
allowed with the Recover qualifier file-spec parameter.
The default is the Norecover qualifier, where no recovery is
attempted when you invoke the ACL editor to edit a root file ACL.
You must specify Edit to use this qualifier.
10.4.13 – Replace
Replace=(ace[,...])
Deletes the ACEs specified with the Acl qualifier and replaces
them with those specified with the Replace qualifier. Any ACEs
specified with the Acl qualifier must exist and must be specified
in the order in which they appear in the ACL.
This qualifier cannot be used with the Edit qualifier.
10.5 – Usage Notes
o You must have the RMU$SECURITY privilege in the root file ACL
for a database or the OpenVMS SECURITY or BYPASS privilege
to use the RMU Set Privilege command for the database. The
RMU$SECURITY access is VMS BIT_15 access in the ACE. You can
grant yourself BIT_15 access by using the DCL SET ACL command
if you have (READ+WRITE+CONTROL) access.
o By default, a root file ACL is created for every Oracle Rdb
database. In some cases, the root file ACL may not allow
the appropriate Oracle RMU access for the database to all
Oracle RMU users. In these situations, you must use the RMU
Set Privilege command to modify the root file ACL to give the
appropriate Oracle RMU access to Oracle RMU users. Privileges
Required for Oracle RMU Commands shows the privileges required
to access each Oracle RMU command.
o The root file ACL created by default on each Oracle Rdb
database controls only a user's Oracle RMU access to the
database (by specifying privileges that will allow a user or
group of users access to specific Oracle RMU commands). Root
file ACLs do not control a user's access to the database with
SQL statements.
A user's access to a database with SQL statements is governed
by the privileges granted to the user in the database ACL
(the ACL that is displayed using the SQL SHOW PROTECTION ON
DATABASE command).
o If you find that the root file ACL has changed, or is not
set as expected, it may be because a layered product has
manipulated the OpenVMS directory or file ACLs. This can
result in the unintentional alteration of an Oracle RMU access
right.
For example, Oracle CDD/Repository may use the following ACE:
(IDENTIFIER=[*,*],OPTIONS=DEFAULT+PROPAGATE,ACCESS=NONE)
If this ACE is propagated to an Oracle Rdb database, such
as CDD$DATABASE or CDD$TEMPLATE, OpenVMS privileges may be
required to manage that database. Or, you can use the RMU Set
Privilege command to change the ACL on the affected database.
o If you need to move a database from one system to another, you
should be aware that the identifiers used in the database's
root file ACL on the source system are not likely to be
valid identifiers on the destination system. Thus, if the
database root file ACL from the source system is moved to the
destination system without modification, only those users with
the same identifiers on both systems have the same Oracle RMU
access to the database on the destination system as they had
to the database on the source system.
For example, suppose that the mf_personnel database with the
following root file ACL is moved from its current system to
another node. If the database root file ACL is moved without
modification to the destination node, the users USER, USER2,
USER3, USER4, and USER5 will not have any Oracle RMU access to
the database on the destination node unless they have the same
identities on the destination node.
$ RMU/SHOW PRIVILEGE MF_PERSONNEL.RDB
Object type: file, Object name:SQL_USER:[USER]MF_PERSONNEL.RDB;1,
on 31-MAR-1992 15:48:36.24
(IDENTIFIER=[SQL,USER],ACCESS=READ+WRITE+CONTROL+RMU$ALTER+
RMU$ANALYZE+RMU$BACKUP+RMU$CONVERT+RMU$COPY+RMU$DUMP+RMU$LOAD+
RMU$MOVE+RMU$OPEN+RMU$RESTORE+RMU$SECURITY+RMU$SHOW+RMU$UNLOAD+
RMU$VERIFY)
(IDENTIFIER=[SQL,USER2],ACCESS=RMU$ANALYZE+RMU$OPEN+RMU$VERIFY)
(IDENTIFIER=[SQL,USER3],ACCESS=RMU$SECURITY)
(IDENTIFIER=[RDB,USER4],ACCESS=RMU$BACKUP+RMU$CONVERT+RMU$DUMP+
RMU$RESTORE)
(IDENTIFIER=[RDB,USER5],ACCESS=RMU$LOAD+RMU$SHOW)
(IDENTIFIER=[*,*],ACCESS=NONE)
o The following list describes some ways to move a database from
one node to another and explains what happens to the original
root file ACL in each scenario:
- RMU Restore command
First, use the RMU Backup command to back up the database
on the source node and to create an .rbf file. Then, copy
the .rbf file from the source node to the destination
node. When you use the RMU Restore command to re-create
the database from the source node on the destination node,
the database on the destination node will have the same
root file ACL as the database on the source node. If a
user with the RMU$SECURITY privilege in the root file
ACL on the source node has the same identifier on the
destination node, that user can modify the root file ACL
on the destination node to grant users the privileges they
need for Oracle RMU access to the database. Otherwise, a
user with one of the OpenVMS override privileges (SECURITY
or BYPASS) needs to modify the root file ACL.
- RMU Restore command with the Noacl qualifier
First, use the RMU Backup command to back up the database
on the source node and to create an .rbf file. Then, copy
the .rbf file from the source node to the destination
node. When you use the RMU Restore command with the Noacl
qualifier to re-create the database from the source node on
the destination node, the database on the destination node
is created with an empty root file ACL. A user with one of
the OpenVMS override privileges (SECURITY or BYPASS) needs
to modify the root file ACL to grant users the privileges
they need for Oracle RMU access to the database.
- SQL IMPORT statement
First, use the SQL EXPORT statement on the source node
to create an .rbr file. Then, copy the .rbr file from the
source node to the destination node. When you use the SQL
IMPORT statement on the destination node, the imported
database is created with the same root file ACL as existed
on the database on the source node. If a user with the
RMU$SECURITY privilege in the root file ACL on the source
node has the same identifier on the destination node, that
user can modify the root file ACL on the destination node
to grant users the privileges they need for Oracle RMU
access to the database. Otherwise, a user with one of the
OpenVMS override privileges (SECURITY or BYPASS) needs to
modify the root file ACL to grant users the privileges they
need for Oracle RMU access to the database.
- SQL IMPORT NO ACL statement
First, use the SQL EXPORT statement on the source node to
create an .rbr file. Then, copy the .rbr file from the
source node to the destination node. When you use the
SQL IMPORT NO ACL statement on the destination node, the
imported database is created with a root file ACL that
contains one ACE. The single ACE will grant the OpenVMS
READ, WRITE, and CONTROL privileges plus all the Oracle RMU
privileges to the user who performed the IMPORT operation.
The user who performed the IMPORT operation can modify the
root file ACL to grant users the privileges they need for
Oracle RMU access to the database.
10.6 – Examples
Example 1
The following example assumes that the user with a user
identification code (UIC) of [SQL,USER] has created the mf_
test_db database and is therefore the owner of the database.
After creating the mf_test_db database, the owner displays the
root file ACL for the database. Then the owner grants Oracle RMU
privileges to database users. The Oracle RMU privileges granted
to each type of user depend on the type of Oracle RMU access the
user needs to the database.
$! Note that by default the owner (the user with a UIC of [SQL,USER])
$! is granted all the Oracle RMU privileges in the root file
$! ACL and no other users are granted any Oracle RMU privileges.
$ RMU/SHOW PRIVILEGE MF_TEST_DB.RDB
Object type: file, Object name: SQL_USER:[USER]MF_TEST_DB.RDB;1,
on 30-MAR-1996 15:51:55.79
(IDENTIFIER=[SQL,USER],ACCESS=READ+WRITE+CONTROL+RMU$ALTER+
RMU$ANALYZE+RMU$BACKUP+RMU$CONVERT+RMU$COPY+RMU$DUMP+RMU$LOAD+
RMU$MOVE+RMU$OPEN+RMU$RESTORE+RMU$SECURITY+RMU$SHOW+RMU$UNLOAD+
RMU$VERIFY)
$!
$! The owner uses the RMU Set Privilege command and the After
$! qualifier to grant the RMU$ANALYZE, RMU$OPEN, and
$! RMU$VERIFY privileges to a user with a UIC of [SQL,USER2].
$! This user will serve as the database administrator for the
$! mf_test_db database.
$ RMU/SET PRIVILEGE/ACL=(IDENTIFIER=[SQL,USER2],ACCESS=RMU$ANALYZE -
_$ +RMU$OPEN+RMU$VERIFY) -
_$ /AFTER=(IDENTIFIER=[SQL,USER])/LOG MF_TEST_DB.RDB
%RMU-I-MODIFIED, SQL_USER:[USER]MF_TEST_DB.RDB;1 modified
$!
$! Next, the owner grants the RMU$SECURITY privilege to a user with a
$! UIC of [SQL,USER3]. This gives the user USER3 the ability
$! to grant other users the appropriate privileges they need for
$! accessing the database with Oracle RMU commands. Because both
$! the database creator and user USER3 have the RMU$SECURITY
$! privilege, both of them can modify the root file ACL for the
$! database.
$ RMU/SET PRIVILEGE/ACL=(IDENTIFIER=[SQL,USER3],ACCESS=RMU$SECURITY) -
_$ /AFTER=(IDENTIFIER=[SQL,USER2])/LOG MF_TEST_DB.RDB
%RMU-I-MODIFIED, SQL_USER:[USER]MF_TEST_DB.RDB;1 modified
$!
$! The user with a UIC of [RDB,USER4], who will serve as the database
$! operator, is granted the RMU$BACKUP, RMU$CONVERT, RMU$DUMP, and
$! RMU$RESTORE privileges:
$ RMU/SET PRIVILEGE/ACL=(IDENTIFIER=[RDB,USER4],ACCESS=RMU$BACKUP -
_$ +RMU$CONVERT+RMU$DUMP+RMU$RESTORE) -
_$ /AFTER=(IDENTIFIER=[SQL,USER3])/LOG MF_TEST_DB.RDB
%RMU-I-MODIFIED, SQL_USER:[USER]MF_TEST_DB.RDB;1 modified
$!
$! The RMU$LOAD and RMU$SHOW privileges are granted to the user
$! with a UIC of [RDB,USER5]. This user will be writing programs
$! that load data into the database.
$ RMU/SET PRIVILEGE/ACL=(IDENTIFIER=[RDB,USER5],ACCESS=RMU$LOAD -
_$ +RMU$SHOW) /AFTER=(IDENTIFIER=[RDB,USER4]) MF_TEST_DB.RDB
%RMU-I-MODIFIED, SQL_USER:[USER]MF_TEST_DB.RDB;1 modified
$!
$! No privileges are granted to all other users.
$ RMU/SET PRIVILEGE/ACL=(IDENTIFIER=[*,*],ACCESS=NONE) -
_$ /AFTER=(IDENTIFIER=[RDB,USER5])/LOG MF_TEST_DB.RDB
%RMU-I-MODIFIED, SQL_USER:[USER]MF_TEST_DB.RDB;1 modified
$!
$! The RMU/SHOW PRIVILEGE command displays the root file ACL for the
$! mf_test_db database.
$ RMU/SHOW PRIVILEGE MF_TEST_DB.RDB
Object type: file, Object name: SQL_USER:[USER]MF_TEST_DB.RDB;1,
on 30-MAR-1996 15:52:17.03
(IDENTIFIER=[SQL,USER],ACCESS=READ+WRITE+CONTROL+RMU$ALTER+
RMU$ANALYZE+RMU$BACKUP+RMU$CONVERT+RMU$COPY+RMU$DUMP+RMU$LOAD+
RMU$MOVE+RMU$OPEN+RMU$RESTORE+RMU$SECURITY+RMU$SHOW+RMU$UNLOAD+
RMU$VERIFY)
(IDENTIFIER=[SQL,USER2],ACCESS=RMU$ANALYZE+RMU$OPEN+RMU$VERIFY)
(IDENTIFIER=[SQL,USER3],ACCESS=RMU$SECURITY)
(IDENTIFIER=[RDB,USER4],ACCESS=RMU$BACKUP+RMU$CONVERT+RMU$DUMP+
RMU$RESTORE)
(IDENTIFIER=[RDB,USER5],ACCESS=RMU$LOAD+RMU$SHOW)
(IDENTIFIER=[*,*],ACCESS=NONE)
Example 2
The following command adds an ACE for the user with a UIC of
[RDB,USER1] to the root file ACL for the personnel database. This
ACE grants [RDB,USER1] the RMU$BACKUP privilege for the personnel
database. The RMU$BACKUP privilege allows user [RDB,USER1]
to access the RMU Backup, RMU Backup After_Journal, and RMU
Checkpoint commands for the personnel database.
$ RMU/SET PRIVILEGE/ACL=(IDENTIFIER=[RDB,USER1],ACCESS=RMU$BACKUP) -
_$ PERSONNEL.RDB
Example 3
The Replace qualifier in the following example causes the ACE
in the root file ACL for the user with a UIC of [RDB,USER4]
to be replaced by the ACE specified for the user with a UIC of
[SQL,USER6]:
$ RMU/SET PRIVILEGE/ACL=(IDENTIFIER=[RDB,USER4]) -
_$ /REPLACE=(IDENTIFIER=[SQL,USER6],ACCESS=RMU$BACKUP+RMU$CONVERT -
_$ +RMU$DUMP+RMU$RESTORE)/LOG MF_TEST_DB.RDB
%RMU-I-MODIFIED, SQL_USER:[USER]MF_TEST_DB.RDB;1 modified
$!
$ RMU/SHOW PRIVILEGE MF_TEST_DB.RDB
Object type: file, Object name: SQL_USER:[USER]MF_TEST_DB.RDB;1,
on 30-MAR-1996 15:52:23.92
(IDENTIFIER=[SQL,USER],ACCESS=READ+WRITE+CONTROL+RMU$ALTER+
RMU$ANALYZE+RMU$BACKUP+RMU$CONVERT+RMU$COPY+RMU$DUMP+RMU$LOAD+
RMU$MOVE+RMU$OPEN+RMU$RESTORE+RMU$SECURITY+RMU$SHOW+RMU$UNLOAD+
RMU$VERIFY)
(IDENTIFIER=[SQL,USER2],ACCESS=RMU$ANALYZE+RMU$OPEN+RMU$VERIFY)
(IDENTIFIER=[SQL,USER3],ACCESS=RMU$SECURITY)
(IDENTIFIER=[SQL,USER6],ACCESS=RMU$BACKUP+RMU$CONVERT+RMU$DUMP+
RMU$RESTORE)
(IDENTIFIER=[RDB,USER5],ACCESS=RMU$LOAD+RMU$SHOW)
(IDENTIFIER=[*,*],ACCESS=NONE)
Example 4
The Delete qualifier in the following example causes the ACE for
the user with a UIC of [RDB,USER5] to be deleted from the root
file ACL for the mf_test_db database:
$ RMU/SET PRIVILEGE/ACL=(IDENTIFIER=[RDB,USER5]) -
_$ /DELETE/LOG MF_TEST_DB.RDB
%RMU-I-MODIFIED, SQL_USER:[USER]MF_TEST_DB.RDB;1 modified
$!
$ RMU/SHOW PRIVILEGE MF_TEST_DB.RDB
Object type: file, Object name: SQL_USER:[USER]MF_TEST_DB.RDB;1,
on 30-MAR-1996 15:52:29.07
(IDENTIFIER=[SQL,USER],ACCESS=READ+WRITE+CONTROL+RMU$ALTER+
RMU$ANALYZE+RMU$BACKUP+RMU$CONVERT+RMU$COPY+RMU$DUMP+RMU$LOAD+
RMU$MOVE+RMU$OPEN+RMU$RESTORE+RMU$SECURITY+RMU$SHOW+RMU$UNLOAD+
RMU$VERIFY)
(IDENTIFIER=[SQL,USER2],ACCESS=RMU$ANALYZE+RMU$OPEN+RMU$VERIFY)
(IDENTIFIER=[SQL,USER3],ACCESS=RMU$SECURITY)
(IDENTIFIER=[SQL,USER6],ACCESS=RMU$BACKUP+RMU$CONVERT+RMU$DUMP+
RMU$RESTORE)
(IDENTIFIER=[*,*],ACCESS=NONE)
Example 5
In the following example, the Like qualifier copies the root file
ACL from the mf_test_db database to the test_db database. As part
of this operation, the original root file ACL for the test_db
database is deleted.
$ RMU/SHOW PRIVILEGE TEST_DB.RDB
Object type: file, Object name: SQL_USER:[USER]TEST_DB.RDB;1, on
30-MAR-1996 15:52:31.48
(IDENTIFIER=[SQL,USER],ACCESS=READ+WRITE+CONTROL+RMU$ALTER+
RMU$ANALYZE+RMU$BACKUP+RMU$CONVERT+RMU$COPY+RMU$DUMP+RMU$LOAD+
RMU$MOVE+RMU$OPEN+RMU$RESTORE+RMU$SECURITY+RMU$SHOW+RMU$UNLOAD+
RMU$VERIFY)
$ !
$ RMU/SHOW PRIVILEGE MF_TEST_DB.RDB
Object type: file, Object name: SQL_USER:[USER]MF_TEST_DB.RDB;1,
on 30-MAR-1996 15:52:33.86
(IDENTIFIER=[SQL,USER],ACCESS=READ+WRITE+CONTROL+RMU$ALTER+
RMU$ANALYZE+RMU$BACKUP+RMU$CONVERT+RMU$COPY+RMU$DUMP+RMU$LOAD+
RMU$MOVE+RMU$OPEN+RMU$RESTORE+RMU$SECURITY+RMU$SHOW+RMU$UNLOAD+
RMU$VERIFY)
(IDENTIFIER=[SQL,USER2],ACCESS=RMU$ANALYZE+RMU$OPEN+RMU$VERIFY)
(IDENTIFIER=[SQL,USER3],ACCESS=RMU$SECURITY)
(IDENTIFIER=[SQL,USER6],ACCESS=RMU$BACKUP+RMU$CONVERT+RMU$DUMP+
RMU$RESTORE)
(IDENTIFIER=[*,*],ACCESS=NONE)
$!
$ RMU/SET PRIVILEGE/LIKE=MF_TEST_DB.RDB/LOG TEST_DB.RDB
%RMU-I-MODIFIED, SQL_USER:[USER]TEST_DB.RDB;1 modified
$!
$ RMU/SHOW PRIVILEGE TEST_DB.RDB
Object type: file, Object name: SQL_USER:[USER]TEST_DB.RDB;1, on
30-MAR-1996 15:52:41.36
(IDENTIFIER=[SQL,USER],ACCESS=READ+WRITE+CONTROL+RMU$ALTER+
RMU$ANALYZE+RMU$BACKUP+RMU$CONVERT+RMU$COPY+RMU$DUMP+RMU$LOAD+
RMU$MOVE+RMU$OPEN+RMU$RESTORE+RMU$SECURITY+RMU$SHOW+RMU$UNLOAD+
RMU$VERIFY)
(IDENTIFIER=[SQL,USER2],ACCESS=RMU$ANALYZE+RMU$OPEN+RMU$VERIFY)
(IDENTIFIER=[SQL,USER3],ACCESS=RMU$SECURITY)
(IDENTIFIER=[SQL,USER6],ACCESS=RMU$BACKUP+RMU$CONVERT+RMU$DUMP+
RMU$RESTORE)
(IDENTIFIER=[*,*],ACCESS=NONE)
Example 6
The New qualifier in the following example deletes all the
existing ACEs and the Acl qualifier specifies a new ACE for the
root file ACL for the mf_test_db database. Note that after the
RMU Set Privilege command in this example is issued, only the
user with a UIC of [SQL,USER2] or a user with an OpenVMS override
privilege would be able to display the root file ACL for the mf_
test_db database.
$ RMU/SHOW PRIVILEGE MF_TEST_DB.RDB
Object type: file, Object name: SQL_USER:[USER]MF_TEST_DB.RDB;1,
on 30-MAR-1996 15:52:44.50
(IDENTIFIER=[SQL,USER],ACCESS=READ+WRITE+CONTROL+RMU$ALTER+
RMU$ANALYZE+RMU$BACKUP+RMU$CONVERT+RMU$COPY+RMU$DUMP+RMU$LOAD+
RMU$MOVE+RMU$OPEN+RMU$RESTORE+RMU$SECURITY+RMU$SHOW+RMU$UNLOAD+
RMU$VERIFY)
(IDENTIFIER=[SQL,USER2],ACCESS=RMU$ANALYZE+RMU$OPEN+RMU$VERIFY)
(IDENTIFIER=[SQL,USER3],ACCESS=RMU$SECURITY)
(IDENTIFIER=[SQL,USER6],ACCESS=RMU$BACKUP+RMU$CONVERT+RMU$DUMP+
RMU$RESTORE)
(IDENTIFIER=[*,*],ACCESS=NONE)
$!
$ RMU/SET PRIVILEGE/NEW -
_$ /ACL=(IDENTIFIER=[SQL,USER2],ACCESS=READ+WRITE+CONTROL+ -
_$ RMU$ALTER+RMU$ANALYZE+RMU$BACKUP+RMU$CONVERT+RMU$COPY+ -
_$ RMU$DUMP+RMU$LOAD+RMU$MOVE+RMU$OPEN+RMU$RESTORE+RMU$SHOW+ -
_$ RMU$UNLOAD+RMU$VERIFY)/LOG MF_TEST_DB.RDB
%RMU-I-MODIFIED, SQL_USER:[USER]MF_TEST_DB.RDB;1 modified
11 – Row Cache
Allows you to enable or disable the database Row Cache feature
and to modify certain parameters on a per-cache basis.
11.1 – Description
You can use the RMU Set Row_Cache command to allow the database
Row Cache feature to be enabled or disabled without requiring
that the database be opened.
You can also use the Alter parameter to make modifications to one
cache at a time.
11.2 – Format
(B)0[mRMU/Set Row_Cache root-file-spec
[4mCommand[m [4mQualifiers[m x [4mDefaults[m
x
/Alter=(Name=cache-name,option(,...)) x See Description
/Backing_Store_Location=devdir x See Description
/NoBacking_Store_Location x See Description
/Disable x None
/Enable x None
/[No]Log x Current DCL verify value
/Sweep_Interval=n x See Description
/[No]Sweep_Interval x See Description
11.3 – Parameters
11.3.1 – root-file-spec
Specifies the database root file for which you want to modify the
Row Cache feature.
11.4 – Command Qualifiers
11.4.1 – Alter
Alter=(Name=cachename,option(, ...))
Specifies the action to take on the named cache. You must
specify the cache name and at least one other option. The /Alter
qualifier may be specified multiple times on the command line.
Each /Alter qualifier specified operates on one unique cache
if no wildcard character (% or *) is specified. Otherwise, each
/Alter operates on all matching cache names.
o Name=cachename
Name of the cache to be modified. The cache must already be
defined in the database. You must specify the cache name
if you use the Alter qualifier. This parameter accepts the
wildcard characters asterisk (*) and percent sign (%).
o Backing_Store_Location=devdir
Specifies the name of the cache-specific default directory to
which row cache backing file information is written for the
specified cache. The database system generates a file name
(row-cache-name.rdc) automatically for each row cache backing
file it creates when the RCS process starts. Specify a device
name and directory name; do not include a file specification.
By default, the location is the directory of the database
root file unless a database-specific default directory or a
cache-specific default directory has been set.
o NoBacking_Store_Location
Specifies that there is no cache-specific default directory
to which row cache backing file information is written for the
specified cache.
o Drop
Specifies that the indicated row cache is to be dropped
(deleted) from the database.
o Shared_Memory=keyword
Specifies the shared memory type and parameters for the cache.
Valid keywords are:
- Type=option
Specify one of the following options:
* Process
Specifies traditional shared memory global section,
which means that the database global section is located
in process (P0) address space and may be paged from the
process working set as needed.
* Resident
Specifies that the database global section is memory
resident in process (P0) address space using shared
page tables. This means that the global section is fully
resident, or pinned, in memory, and uses less physical
and virtual memory (for process page tables) than a
traditional shared memory global section.
- Rad_Hint=n
NoRad_Hint
Indicates a request that memory should be allocated from
the specified OpenVMS Resource Affinity Domain (RAD). This
keyword specifies a hint to Oracle Rdb and OpenVMS about
where memory should be physically allocated. It is possible
that if the requested memory is not available, it will be
allocated from other RADs in the system. For systems that
do not support RADs, no Rad_Hint specification is valid.
The Rad_Hint keyword is valid only when the shared memory
type is set to Resident. If you set the shared memory type
to System or Process, you disable any previously defined
RAD hint.
Use Norad_Hint to disable the RAD hint.
o Slot_Count=n
Specifies the number of slots in the cache.
o Slot_Size=n
Specifies the size (in bytes) of each slot in the cache.
o Snapshot_Slot_Count=n
Specifies the number of snapshot slots in the cache. A value
of zero disables the snapshot portion for the specified cache.
o Sweep_Interval=n
Specifies the periodic cache sweep timer interval in seconds.
Valid values are from 1 to 3600.
o NoSweep_Interval
Disables the periodic cache sweep timer interval.
o Working_Set_Count=n
Specifies the number of working set entries for the cache.
Valid values are from 1 to 100.
11.4.2 – Backing Store Location=devdir
Specifies the name of the database-specific default directory to
which row cache backing file information is written. The database
system generates a file name (row-cache-name.rdc) automatically
for each row cache backing file it creates when the RCS process
starts up. Specify a device name and directory name; do not
include a file specification. The file name is the row-cache-name
specified when creating the row cache. By default, the location
is the directory of the database root file unless a database-
specific default directory or a cache-specific default directory
has been set.
11.4.3 – Disable
Disables row caching. Do not use with the Enable qualifier.
11.4.4 – Enable
Enables row caching. Do not use with the Disable qualifier.
11.4.5 – Log
Log
Nolog
Specifies whether the processing of the command is reported to
SYS$OUTPUT. Specify the Log qualifier to request log output and
the Nolog qualifier to prevent it. If you specify neither, the
default is the current setting of the DCL verify switch.
11.4.6 – NoBacking Store Location
Specifies that there is no database-specific default directory to
which row cache backing file information is written.
11.5 – Usage Notes
o This command requires exclusive database access (the database
cannot be open or accessed by other users).
o The Alter qualifier can be specified multiple times on the
command line. Each use of the qualifier operates on a unique
cache.
o Only one value can be supplied with the Rad_Hint keyword. The
indicated RAD must contain memory.
o When shared memory is set to System (with Galaxy enabled) or
to Resident, then the process that opens the database must be
granted the VMS$MEM_RESIDENT_USER identifier.
o For applications that can be partitioned into one or more
RADs, the Rad_Hint qualifier allows additional control
over exactly where memory for caches and global sections
is allocated. This control can permit increased performance
if all application processes run in the same RAD, and the
database and row cache global sections also reside in that
same RAD.
o When Resident shared memory is specified, the global demand-
zero pages are always resident in memory and are not backed
up by any file on any disk. The pages are not placed into the
process's working set list when the process maps to the global
section and the virtual memory is referenced by the process.
The pages are also not charged against the process's working
set quota or against any page-file quota.
o To save physical memory, Oracle Rdb generally attempts to
create and use shared page tables when creating large resident
global sections.
o The total number of rows for any individual cache (the
combination of live rows and snapshot rows) is limited to
2,147,483,647.
11.6 – Examples
Example 1
The following example sets the slot count on cache "mycache".
$ RMU/SET ROW_CACHE/ALTER=(NAME=mycache, SLOT_COUNT=8888)
Example 2
This command disables all caches.
$ RMU/SET ROW_CACHE/DISABLE
Example 3
The following sample specifies that cache "cache2" should use RAD
2.
$ RMU/SET ROW_CACHE/ALTER=(NAME=cache2, SHARED_MEM=(TYPE=RESIDENT, -
_$ RAD_HINT=2)
Example 4
This example drops cache "seacache".
$ RMU/SET ROW_CACHE/ALTER=(NAME=seacache, DROP)
Example 5
This example shows multiple uses of the Alter qualifier.
$ RMU /SET ROW_CACHE MF_PERSONNEL/ALTER=(NAME = RDB$SYS_CACHE, -
_$ SLOT_COUNT = 800, WINDOW_COUNT = 25) -
_$ /ALTER= (NAME = RESUMES,SLOT_SIZE=500,WORKING_SET_COUNT = 15)
Example 6
The following example modifies the database MYDB to set the
snapshot slot count for the cache EMPL_IDX to 25000 slots and
disables snapshots in cache for the SALES cache.
$ RMU /SET ROW_CACHE DGA0:[DB]MYDB.RDB -
_$ /ALTER=(NAME=EMPL_IDX, SNAPSHOT_SLOT_COUNT=25000) -
_$ /ALTER=(NAME=SALES, SNAPSHOT_SLOT_COUNT=0)
Example 7
The following example alters two caches:
$ RMU /SET ROW_CACHE MF_PERSONNEL -
/ALTER= ( NAME = RDB$SYS_CACHE,
SLOT_COUNT = 800) -
/ALTER= ( NAME = RESUMES, -
SLOT_SIZE=500, -
WORKING_SET_COUNT = 15)
Example 8
The following command alters caches named FOOD and FOOT (and
any other cache with a 4 character name with the first three
characters of "FOO" defined in the database):
$ RMU /SET ROW_CACHE MF_PERSONNEL -
/ALTER= ( NAME = FOO%,
BACKING_STORE_LOCATION=DISK$RDC:[RDC])
12 – Server
Allows you to identify output files for several database server
processes.
12.1 – Description
You can use the Set Server/Output command to identify output log
file names and locations for various database server processes.
The following table shows valid values for the server-type
parameter and the corresponding logical name.
Table 15 Server Types and Logical Names
Server-
Server type Logical Name
AIJ Backup Server ABS RDM$BIND_BIND_ABS_OUTPUT_FILE
AIJ Log Server ALS RDM$BIND_BIND_ALS_OUTPUT_FILE
AIJ Log Roll- LRS RDM$BIND_LRS_OUTPUT_FILE
Forward Server
AIJ Log Catch-Up LCS RDM$BIND_LCS_OUTPUT_FILE
Server
Database Recovery DBR RDM$BIND_DBR_LOG_FILE
Server
Row Cache Server RCS RDM$BIND_RCS_LOG_FILE
If the output file specification is empty (Output=""), the
log file information for that server will be deleted from the
database.
If an existing logical name specifies an output file name for the
specified server process, it takes precedence over the file name
designated in the Set Server/Output command.
12.2 – Format
(B)0[m RMU/Set Server server-type root-file-spec
[4mCommand[m [4mQualifiers[m x [4mDefaults[m
x
/Log x None
/Output=file-name x None
12.3 – Parameters
12.3.1 – server-type
Identifies the server process for which you want to log output.
Refer to the Server Types and Logical Names table in the
Description topic for a list of valid server types and their
corresponding logical names.
12.3.2 – root-file-spec
Specifies the database root file for which you want to specify
the server process output file.
12.4 – Command Qualifiers
12.4.1 – Log
Displays a log message at the completion of the RMU Set command.
12.4.2 – Output
Identifies the output log file for several database server
processes.
12.5 – Examples
Example 1
This example specifies the output file for the row cache server
and displays a log message when the procedure finishes.
$ RMU /SET SERVER RCS /OUTPUT=RCS_PID.LOG /LOG DUA0:[DB]MYDB.RDB
Example 2
This example specifies the output file for the AIJ log server.
$ RMU /SET SERVER ALS /OUTPUT=ALS$LOGS:ALS_DB1.LOG DUA0:[DB1]MFP.RDB
Example 3
This example deletes the log file information in the database for
the AIJ log roll-forward server.
$ RMU /SET SERVER LRS /OUTPUT="" DUA0:[ZDB]ZDB.RDB
Example 4
This example specifies the output file for the database recovery
server.
$ RMU /SET SERVER DBR /OUTPUT=DBR$LOGS:DBR.LOG DUA0:[ADB]ADB.RDB
13 – Shared Memory
Allows you to alter the database shared memory configuration
without requiring that the database be open.
13.1 – Description
You can use the RMU Set Shared_Memory command to alter the
database shared memory configuration without requiring that the
database be open.
13.2 – Format
(B)0[mRMU/Set Shared_Memory root-file-spec
[4mCommand[m [4mQualifiers[m x [4mDefaults[m
x
/[No]Log x Current DCL verify value
/[No]Rad_Hint=n x None
/Type={Process|Resident|System} x None
13.3 – Parameters
13.3.1 – root-file-spec
Specifies the database root file for which you want to modify the
shared memory configuration.
13.4 – Command Qualifiers
13.4.1 – Log
Log
Nolog
Specifies whether the processing of the command is reported to
SYS$OUTPUT. Specify the Log qualifier to request log output and
the Nolog qualifier to prevent it. If you specify neither, the
default is the current setting of the DCL verify switch.
13.4.2 – Rad Hint
Rad_Hint=n
Norad_Hint
Indicates a request that memory should be allocated from the
specified OpenVMS Alpha Resource Affinity Domain (RAD). This
qualifier specifies a hint to Oracle Rdb and OpenVMS about where
memory should be physically allocated. It is possible that if
the requested memory is not available, it will be allocated from
other RADs in the system. For systems that do not support RADs, a
Rad_Hint value of zero is valid.
The Rad_Hint qualifier is only valid when the shared memory type
is set to Resident. If you set the shared memory type to System
or Process, you disable any previously defined RAD hint.
Use the Norad_Hint qualifier to disable the RAD hint.
NOTE
OpenVMS support for RADs is available only on the
AlphaServer GS series systems. For more information about
using RADs, refer to the OpenVMS Alpha Partitioning and
Galaxy Guide.
13.4.3 – Type
Type=option
If you use the Type qualifier, you must specify one of the
following options:
o Process
Specifies traditional shared memory global section, which
means that the database global section is located in process
(P0) address space and may be paged from the process working
set as needed.
o Resident
Specifies that the database global section is memory resident
in process (P0) address space using OpenVMS Alpha shared page
tables. This means that the global section is fully resident,
or pinned, in memory, and uses less physical and virtual
memory (for process page tables) than a traditional shared
memory global section.
o System
Specifies that the database global section is located in
OpenVMS Alpha system space, which means that the section is
fully resident, or pinned, in memory, does not use process
(P0) address space, and does not affect the quotas of the
working set of a process.
13.5 – Usage Notes
o This command requires exclusive database access (the database
cannot be open or accessed by other users).
o Only one value can be supplied to the Rad_Hint qualifier. The
indicated RAD must contain memory.
o When shared memory is set to System (with Galaxy enabled) or
to Resident, then the process that opens the database must be
granted the VMS$MEM_RESIDENT_USER identifier.
o For applications that can be partitioned into one or more
RADs, the Rad_Hint qualifier allows additional control
over exactly where memory for caches and global sections
is allocated. This control can permit increased performance
if all application processes run in the same RAD, and the
database and row cache global sections also reside in that
same RAD.
o When Resident shared memory is specified, the global demand-
zero pages are always resident in memory and are not backed
up by any file on any disk. The pages are not placed into the
process's working set list when the process maps to the global
section and the virtual memory is referenced by the process.
The pages are also not charged against the process's working
set quota or against any page-file quota.
o To save physical memory, Oracle Rdb generally attempts to
create and use shared page tables when creating large resident
global sections.
13.6 – Examples
Example 1
The following example sets the memory type to Resident and
requests that it be put in RAD 4.
$ RMU/SET SHARED_MEMORY/TYPE=RESIDENT/RAD_HINT=4
Example 2
This example specifies that system space buffers are to be used.
$ RMU/SET SHARED_MEMORY/TYPE=SYSTEM
Example 3
The following example specifies that process address space shared
memory is to be used.
$ RMU/SET SHARED_MEMORY/TYPE=PROCESS/LOG