The Oracle RMU Monitor controls the Oracle Rdb Monitor Process.
An Oracle Rdb Monitor Process must be running on each system on
which you use Oracle Rdb, including each node in a VAXcluster
or VMScluster. An RMU Monitor command controls only the monitor
process running on the system from which the command is issued.
The Oracle Rdb Monitor Process controls all database access and
initiates the automatic recovery procedure when necessary.
1 – Reopen Log
Closes the current Oracle Rdb monitor log file, compresses it,
and opens another one without stopping the monitor.
1.1 – Description
The RMU Monitor Reopen_Log command closes the current Oracle
Rdb monitor log file, compresses it, and opens another log file
without stopping the monitor. The new log has the same name as,
but a new version number of, the monitor log file you opened with
the RMU Monitor Start command. Use the RMU Show Users command to
determine the current name and location of the monitor log file
before issuing the RMU Monitor Reopen_Log command. You should use
the RMU Monitor Reopen_Log command if the monitor log file gets
too large. For example, if you are running out of space on your
disk or if database performance slows, you might want to open
another log file.
If the disk that contains the Oracle Rdb monitor log file
becomes full, you must acquire space on the disk. Once there
is sufficient space on this disk, use the RMU Monitor Reopen_Log
command and consider backing up (using the DCL COPY command or
the OpenVMS Backup utility) the old monitor log file.
When the disk that contains the monitor log becomes full, Oracle
Rdb stops writing to the log file, but the Oracle Rdb system
does not stop operating. A message is sent to the cluster system
operator when this occurs.
1.2 – Format
(B)0[m RMU/Monitor Reopen_Log
1.3 – Usage Notes
o To use the RMU Monitor Reopen_Log command, either you must
have the OpenVMS SETPRV privilege or the OpenVMS WORLD,
CMKRNL, DETACH, PSWAPM, ALTPRI, SYSGBL, SYSNAM, SYSPRV, and
BYPASS privileges.
1.4 – Examples
Example 1
The following example closes the existing monitor log file,
compresses it, and creates a new one without stopping the Oracle
Rdb monitor:
$ RMU/MONITOR REOPEN_LOG
See the Oracle Rdb Guide to Database Maintenance for more
examples that show the RMU Monitor commands.
2 – Start
Activates the Oracle Rdb monitor process.
2.1 – Description
The RMU Monitor Start command activates the Oracle Rdb monitor
process (RDMS_MONITORnn, where nn represents the version Oracle
Rdb), sets the priority of this process, and specifies a device,
directory and file name in which to create the monitor log
file. If the monitor process is active already, you receive the
following error message:
%RMU-F-MONMBXOPN, monitor is already running
An Oracle Rdb monitor process must be running on a node for
users logged in to that node to use any Oracle Rdb database.
In a VMScluster environment, a monitor process must be running on
each node in the cluster from which databases are accessed.
The Oracle Rdb monitor process controls all database access and
initiates the automatic database recovery procedure following a
system failure or other abnormal termination of a database user
process.
See the Oracle Rdb Installation and Configuration Guide for
information on support for multiple versions of Oracle Rdb.
2.2 – Format
(B)0[m RMU/Monitor Start
[4mCommand[m [4mQualifiers[m x [4mDefaults[m
x
/Output = file-name x /Output=SYS$SYSTEM:RDMMON.LOG
/Priority = integer x /Priority = 15
/[No]Swap x /Noswap
2.3 – Command Qualifiers
2.3.1 – Output
Output=file-name
Specifies the device, directory, and file name that receives the
monitor log. You can use this qualifier to redirect the placement
of your monitor log file. The default device and directory is the
SYS$SYSTEM directory. The default log file name is RDMMON.LOG.
The RMU Monitor Start command causes a new version of the log
file to be created for each database session.
2.3.2 – Priority
Priority=integer
Specifies the base priority of the monitor process. This priority
should always be higher than the highest database user process
priority.
By default, the monitor runs at the highest interactive priority
possible, 15. You should not normally have to lower the monitor
process priority. If you change this to a lower priority, an
attach operation can cause a deadlock. Deadlock occurs when
multiple processes with higher priority than the monitor attempt
to attach at the same time. In this case, the monitor must
contend for CPU time with multiple higher-priority processes
and is perpetually locked out. As a result, no one can use the
database.
2.3.3 – Swap
Swap
Noswap
Enables or disables swapping of the monitor process. The default
is Noswap. The Swap qualifier is not recommended for time-
critical applications, because no one can use the database while
the monitor process is being swapped.
2.4 – Usage Notes
o To use the RMU Monitor Start command, you must have either the
OpenVMS SETPRV privilege or the OpenVMS WORLD, CMKRNL, DETACH,
PSWAPM, ALTPRI, PRMMBX, SYSGBL, SYSNAM, SYSPRV, and BYPASS
privileges.
o If the monitor has not been started on the system previously,
use the RMONSTART.COM command file (which, by default, is
located in the SYS$STARTUP directory) instead of the RMU
Monitor Start command.
o Start the monitor from the SYSTEM account, which has the
SETPRV privilege. The process starting the monitor attempts
to give RDMS_MONITOR all privileges. In particular, the
privileges required are ALTPRI, CMKRNL, DETACH, PSWAPM,
PRMMBX, SETPRV, SYSGBL, SYSNAM, and WORLD.
o The monitor process inherits some quotas, such as MAXDETACH,
and the user name of the user who starts it. This can result
in severe restrictions on user access. For example, if the
user who starts the monitor has a MAXDETACH quota of two, then
the monitor can only start two recovery processes at one time.
However, the system defines most of the quotas needed by the
monitor.
o If the LNM$PERMANENT_MAILBOX table is not defined in the
LNM$SYSTEM_TABLE logical name table, either of the following
might occur:
- The RMU Start Monitor command hangs
- You receive the error, "monitor is not running", when you
know it is.
By default, the LNM$PERMANENT_MAILBOX table is defined in the
LNM$SYSTEM_TABLE logical name table. However, sometimes a user
or third-party application redefines the LNM$PERMANENT_MAILBOX
table in another logical name table (such as the LNM$GROUP
table). To recover from this situation, follow these steps:
1. Define the LNM$PERMANENT_MAILBOX table in the
LNM$SYSTEM_TABLE:
$ DEFINE/TABLE=LNM$PROCESS_DIRECTORY LNM$PERMANENT_MAILBOX -
_$ LNM$SYSTEM
2. Start the database monitor:
RMU/MONITOR START
3. Start the application
Or, change the application that redefines the LNM$PERMANENT_
MAILBOX table so that LNM$PERMANENT_MAILBOX is defined as a
search list that includes the LNM$SYSTEM_TABLE table, as shown
in the following example:
$ DEFINE/TABLE=LNM$PROCESS_DIRECTORY LNM$PERMANENT_MAILBOX -
_$ LNM$GROUP, LNM$SYSTEM
o Use the RMU Show System command to determine the location of
the monitor log file if it is not in the default location. The
monitor log file may not be in the default location if someone
has issued the RMU Monitor Start command and specified a
location different from the default with the Output qualifier.
o The monitor process should only be started by a user whose
account has adequate quotas. Ideally, the monitor process
should be started from the SYSTEM account.
o To view the contents of monitor log file online (even
when disk-based logging is disabled because of disk space
problems), use the Performance Monitor and select the Monitor
Log screen from the Per-Process menu. See the Oracle Rdb7
Guide to Database Performance and Tuning or the Performance
Monitor Help for information about using the Performance
Monitor.
2.5 – Examples
Example 1
The following command activates the Oracle Rdb monitor process:
$ RMU/MONITOR START
See the Oracle Rdb Guide to Database Maintenance for more
examples that show the RMU Monitor commands.
3 – Stop
Stops the Oracle Rdb monitor process.
3.1 – Description
The RMU Monitor Stop command stops the Oracle Rdb monitor process
(RDMS_MONITORnn, where nn represents the version Oracle Rdb)
normally, either with a shutdown and rollback of the databases or
an immediate abort. You can use the RMU Monitor Stop command
to shut down all database activity on your node, optionally
aborting user processes by forcing an image exit or deleting
their processes.
The RMU Monitor Stop command closes the monitor log file also.
An Oracle Rdb monitor process must be running on a node for
users logged in to that node to use any Oracle Rdb database.
In a VMScluster environment, a monitor process must be running on
each node in the cluster from which databases is accessed.
The Oracle Rdb monitor process controls all database access and
initiates the automatic database recovery procedure following a
system failure or other abnormal termination of a database user
process. The monitor log file automatically tracks all access to
the database.
3.2 – Format
(B)0[m RMU/Monitor Stop
[4mCommand[m [4mQualifiers[m x [4mDefaults[m
x
/[No]Abort[={Forcex | Delprc}] x /NOABORT
/[No]Wait x /NOWAIT
3.3 – Command Qualifiers
3.3.1 – Abort
Abort=Forcex
Abort=Delprc
Noabort
The Abort=Forcex qualifier stops the monitor immediately without
allowing current Oracle Rdb users to complete active transactions
or detach from their databases. However, the user processes are
not deleted. Active transactions are rolled back. If a process
using a database is waiting for a subprocess to complete, the
transaction is not rolled back until the subprocess completes.
Using the Abort qualifier with no option is equivalent to
specifying the Abort=Forcex qualifier.
The Abort=Delprc qualifier stops the monitor immediately without
allowing current Oracle Rdb users to complete active transactions
or detach from their databases. Each user process that was
attached to an Oracle Rdb database is deleted immediately.
The Noabort qualifier allows current user processes to continue
and complete before stopping. New users on the node are not
allowed to attach to any database, but existing database users
can complete their sessions normally. Once existing database user
processes terminate, the database monitor shuts down.
The Noabort qualifier is the default.
3.3.2 – Wait
Wait
Nowait
Specifies whether the Oracle RMU operation completes when the
monitor acknowledges the stop request (Nowait), or whether RMU
waits until the monitor finishes shutting down (Wait).
The default is Nowait.
3.4 – Usage Notes
o To use the RMU Monitor Stop command, you must have either the
OpenVMS SETPRV privilege or the OpenVMS WORLD, CMKRNL, DETACH,
PSWAPM, PRMMBX, ALTPRI, SYSGBL, SYSNAM, SYSPRV, and BYPASS
privileges.
NOTE
If Oracle Trace is installed on your system, you stall
the Oracle Rdb monitor process with the RMU Monitor Stop
command unless you do one of the following:
- Shut down Oracle Trace, then shut down the Oracle Rdb
monitor (in that order).
- Use the RMU Monitor Stop command with the Abort=Delprc
qualifier to shut down Oracle Rdb and force the
monitor out of the Oracle Trace database.
3.5 – Examples
Example 1
The following command causes the Oracle Rdb monitor process to
shut down after existing database users end their access to the
database. New users on this node are unable to attach to any
Oracle Rdb database.
$ RMU/MONITOR STOP
Example 2
The following command causes the Oracle Rdb monitor to stop
immediately without allowing current Oracle Rdb users to
complete active transactions (they are rolled back) or detach
(DISCONNECT) from their databases. However, the user processes
are not deleted. Because the monitor is shut down, all Oracle Rdb
activity on this node is terminated.
$ RMU/MONITOR STOP /ABORT=FORCEX
Example 3
The following command causes the Oracle Rdb monitor to stop
immediately without allowing current Oracle Rdb users to
complete active transactions (they are not rolled back) or
detach (DISCONNECT) from their databases. Each user process that
was attached to a Oracle Rdb database on this node is deleted
immediately.
$ RMU/MONITOR STOP /ABORT=DELPRC