There are multiple common
questions to which our support staff are exposed. We
want to make this information readily accessible for
you, to save as much time as possible. Therefore, the
following is a list of Frequently Asked Questions
(FAQs) and their associated answers.
GENERAL Rdb CONTROLLER QUESTIONS:
Q. What platforms do the products run on?
A. Rdb Controller - The components of Rdb Controller (
DBAnalyzer, DBXact, and DBTune) run on OpenVMS (Version 5.5 or
greater) with an Oracle Rdb database server (Version 4.2 or
greater). Support for both Vax, Itanium, and Alpha platforms is
available.
Q. What are the system requirements of Rdb Controller?
A. Please consult the following table:
| Rdb CONTROLLER |
| OPERATING
SYSTEM |
OpenVMS 5.5 or
greater |
| PROCESSOR |
Vax or AXP or
Itanium |
| DISK SPACE |
The
entire Controller suite
installation requires approximately 218,000 blocks of disc
space for AXP & Itanium. Vax installations requires
approximately 134,000 blocks.
|
| NETWORK |
Not mandatory |
| ACCESS to Rdb |
OpenVMS cluster
software and the ability to open the database from the
"installation" node, is required to access an
Rdb database residing on "another" node in the
same cluster. DBXact must be installed on each
"node" which it is to profile because Rdb does not
share node information across the cluster. |
| ORACLE Rdb |
4.2 or greater
(with some exceptions where API library files are no
longer available from Oracle). Standard or multi-version
is supported. Both developer and run-time Rdb are supported. |
Q.
Why does DBTune recommend so many 'additional' storage
areas?
A. DBTune has no way of knowing which areas are "related" from the application standpoint. It therefore can not recommend which
tables should be 'clustered' together to share a single area
(Clustering places two or more related tables in a single area such
that upon retrieving one record, related records from the second
table have a higher probability of being "pulled"
into memory in a single I/O operation).
Clustering requires a detailed knowledge of
the database application, the indexes, and the data retrieval
patterns. Excellent results can often be obtained without the use of
clustering. However, the modpad file has a "cluster" section for the DBA to specify these interdependencies (which only the DBA or the developers would
know) if he/she wishes. DBTune will perform all the sizing
calculations taking this input into account. Existing
"placed via" tables/indexes are preserved by default.
Clustering aside, placing each significant table/index in its own
area means each storage area can be "tuned" for a specific table or
a specific index. The storage area page size can be adjusted to accommodate the record/index size, taking into account whether or not compression is enabled for that
specific entity. Database buffer size can then be made to match the range of storage area pages for optimal storage and retrieval.
This "package" of tailoring the
various database parameters to each other typically yields excellent
results. Any 'perceived' overhead associated with the additional
storage area files is typically far less than the 'actual' gains
achieved.
Similarly, "hot" areas can be easily identified and those areas
more easily distributed on available drives to reduce I/O contention.
If the additional storage areas are a problem
for whatever reason, then the DBA can always tune with the
'Existing" area option. DBTune will adjust the existing areas
to the best of its ability without creating new ones.
