Frequently Asked Questions

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.