I found something today that may be of interest:

Q: What can customers do to tune for performance?
A: Please consult MetaLink as your starting point for researching tuning tips for Oracle8i. Oracle also recommends that customers stay current with all software maintenance, both from Compaq and from Oracle, to ensure that your applications continue to run smoothly.
Oracle Worldwide Support maintains a document, accessible from MetaLink, which lists all Oracle patches and Compaq ECOs (please see Note 154427.1 - List of patches for Oracle 8.1.7.1.0/8.1.7.1b on Alpha OpenVMS, Note 174247.1 - List of patches for Oracle 8.1.7.3, and Note162502.1 - List of patches for Oracle 9.0.1.0.0 on Alpha OpenVMS).

Also, there are some basic tuning steps known to benefit overall OpenVMS system and Oracle performance:

Distribute Oracle datafiles and redolog files across all available disks; the document at http://technet.oracle.com/deploy/ava...w2000_sane.pdf contains useful tips and guidelines.
Ensure those files are not fragmented.
Ensure tables and indexes have as few extents as possible.
Ensure table rows have no or little block chaining.
Ensure proper Working Set quota settings for both the Bequeath and the TNS listener slave processes. Files are BEQLSNR.COM and TNSLNR.COM, both residing in ORA_ROOT:[NETWORK]. We suggest ORA_LSNR_WSDEFAULT be set to 4096 and ORA_LSNR_WSQUOTA and ORA_LSNR_WSEXTENT each be set to 102400.
Ensure Automatic Working Set Adjustment is enabled.
Ensure proper tuning of the various components within the SGA, keeping in mind that "bigger = better" is not true per definition. Too large can in fact have an adverse effect on overall performance! For example, having a buffer cache that is too large incurs overhead that can be more than the benefits of having more data blocks in memory. Similarly, a SQL pool that is larger than the sum of all unique statements is a waste of memory that is better used elsewhere.

This was found on HP's site under open VMS. I am going to attempt to make the changes on the BEQLSNR.COM file.


Thanks,
Mike