andrew.rycroft@[EMAIL PROTECTED]
wrote:
> Hi,
>
> Currently we are running Oracle/Rdb on OpenVMS. Rdb creates a lot of
> RUJ and log files in SYS$SYSTEM. Is there a way to get Oracle Rdb to
> create them on a different disk ? Is there a logical for this ?
>
> Thank
> Andrew
>
From the "Oracle Rdb7 Guide to Database Performance and Tuning"
(Copyright © 1984, 1996, Oracle Corporation.)
http://download-uk.oracle.com/otn_hosted_doc/rdb/pdf/dbpt.pdf
See especially Appendix A for a list of Rdb Logical Names.
-------------------------------
RDMS$RUJ and RDB_RUJ (from appendix A.97)
You can use the RDMS$RUJ logical name or the RDB_RUJ configuration
parameter to locate the .ruj file on a different disk and directory from
the default directory. This can help to reduce contention in that
directory.
Include the RDB_RUJ configuration parameter in the configuration file to
specify the location you want to use, as shown in Example A–36.
Example A–36 Using the RDB_RUJ Configuration Parameter
RDB_RUJ /usr/clients/journal
¨
See Section 3.2.1.7 and Section 8.1.2 for more information.
.. . .
The following guidelines can help you decide where to place the database
files:
• Database root (.rdb), storage area (.rda), and snapshot (.snp) files
In a single-node environment, Oracle Rdb maps the root portion of the
database file, or root header, as a global section of memory. Because
VMScluster configurations do not allow memory to be shared between
nodes, Oracle Rdb in a VMScluster environment maintains copies of the
root header in a page-file section on each node that uses a database.
The root file itself remains on the disk where you created it.
Therefore, this disk must be accessible from all nodes in the VMScluster
system that will access the database. If the root file of a database is
not available to a node, that database cannot be used by that node.
The OpenVMS lock manager ensures that all root file copies are
identical. The root, storage area, and snapshot files must be accessible
from every node that intends to access the database. Oracle Rdb must be
able to create and maintain VMScluster distributed root file access.
• Recovery-unit journal (.ruj) files
Oracle Rdb must be able to complete its automatic recovery procedure
should a node fail. Recovery can complete only if all .ruj files are
accessible from every node that accesses the database. To ensure that
all .ruj files are accessible, follow these rules:
Define the RDMS$RUJ logical name in the system table to refer to a
common directory. Define the RDMS$RUJ logical name for each process to
refer to a common directory. If you permit .ruj files to reside on the
user’s default directory, that directory’s device must be on a
cluster-accessible disk.
• After-image journal (.aij) files
The .aij files must be accessible from every node that accesses the
database. This ensures that all processes that access the database will
be able to write to the .aij files.
To learn about reducing I/O contention in multiuser database access,
read Section 3.2 and Section 8.1.1, which describe disk I/O operations
and the corresponding effects on database performance. Placing the .aij
files on different devices than the database files is one way to
minimize I/O contention on the database disks.
.. . .
Example 6–8 Defining the RDMS$RUJ Logical Name for the Directory for the
..ruj Files
$ DEFINE/SYSTEM RDMS$RUJ RUJ_DISK:[PERS.RUJ]
If you plan to use a systemwide directory for your .ruj files, include
this command in your SYSTARTUP_V5.COM or SYSTARTUP_VMS.COM file.
Define this directory on a device other than the database files. You can
also use the default, SYS$LOGIN, to place .ruj files per process in each
user’s default directory. If you do not define the logical name,
RDMS$RUJ, to refer to a common directory, make sure that all database
users log in to accounts whose default directories are on
cluster-accessible disks.
--------------------------
ALSO...
RDM$BIND_ABS_LOG_FILE and RDB_BIND_ABS_LOG_FILE
You can use the RDM$BIND_ABS_LOG_FILE logical name or the RDB_
BIND_ABS_LOG_FILE configuration parameter to
-----------------------------
RDM$BUGCHECK_DIR and RDB_BUGCHECK_DIR
You can use the RDM$BUGCHECK_DIR logical name or the RDB_BUGCHECK_DIR
configuration parameter to redirect the location of bugcheck files from
the default directory to another location. This can be useful when the
default directory does not have enough space for bugcheck files.
On OpenVMS, when the bugcheck directory is defined, bugcheck dump files
are written to the device and directory pointed to by the
RDM$BUGCHECK_DIR logical name, rather than to the user’s top-level
directory, which is the default behavior on OpenVMS.
When users have reached their disk quotas in their default directory due
to a bugcheck dump, and if the RDM$BUGCHECK_DIR logical name or the
RDB_BUGCHECK_DIR configuration parameter is not specified to another
device, the bugcheck dump overflows to the KOD$TT file. In this case, a
DBR process is created with an output device of KOD$TT. Also, note that
bugcheck dump files are written to the system disk and if the system
disk becomes full, the overflow might also end up in KOD$TT. Generally,
nothing is written to KOD$TT and an examination of the KOD$TT file will
show that it is empty.
DBR bugcheck dump files by default are written to the SYS$SYSTEM
directory; however, when you define the RDM$BUGCHECK_DIR logical name,
DBR bugchecks will also be written to the new location specified by this
logical name. As with any file creation, the user must have read and
write access to the bugcheck directory for the bugcheck dump file to be
written successfully.
--------------------------
User Logfiles usually go to the directory defined in the logical
SYS$SCRATCH. This is by default the same as the SYS$LOGIN directory of
the user.
The variuos Rdb Manuals are available here...
http://www.oracle.com/technology/products/rdb/rdb_doc_index.html
Appendix E of the SQL Reference Manual provide Logical Names used by SQL.
Cheers!
Keith Cayemberg
|
