![]() |
![]() HP OpenVMS Systemsask the wizard |
![]() |
The Question is: I am working on an application which uses RMS files. A number of the files have in excess of 5 keys. All our FDL's for these files seem to contain up to 3 areas ie area 0, 1 and 2. I have recently spoken to someone from Compaq who indicated that there may be a performance benefit by increasing the number of areas specified in the FDL (one area for each key perhaps ?). Is this correct ? If this would provide an increase in performance can you give some info on how to go about this since tuning the files us ing analyze never suggests more than 3 areas. I would also appreciate it if you could point me in the direction of any web sites which may exist with detailed info on how to get the best performance from RMS files. On a similar matter I believe there is a write behind parameter which can be specified within an FDL. I have been told that this may give a performance benefit especially where large sequential write operations are taking place. Is this independant of the application sitting on top of RMS. We use a product called Gembase which has RMS files as its database engine. Within Gembase there are options to use deferred writes. Is there any gain to be had by switching this on exclusively in the FDL ? What would h appen if the node crashed during a deffered write operation ? Would it be true to say that the contents of the cache would be lost and therefore the status of the writes to the file/disk would not be guaranteed causing us problems with our recovery proces ses. Thanks, Colin. The Answer is : A simple increase in the number of areas will NOT change performance. More areas are an enabler which allow you to choose more specialized bucket sizes for the various regions in the file, as well as placement for those regions. You can easily make EDIT/FDL generate more areas through the /GRAN switch. However, as EDIT/FDL does not really help you tune with those areas, you might choose to just manually add a few more areas for those (alternate key) areas for which you determined that a special bucketsize / placement is appropriate. DEFERRED WRITE is NOT a permanent file attibute option and thus only available through FDL, if FDL$PARSE is used to construct the FAB to open the file. Normally the DFW option must be set through a language extension or 'user open' function. Indeed, DFW must be used with some consideration for the reduced file updates which may leave a file in an inconsistent state. For general RMS tuning information, the OpenVMS Guide to Files is a good starting manual. to start. An RMS tuning presentation was made available for the Spring 1999 DECUS Symposium and should appear on the symposium CD. The OpenVMS Wizard expects to be able to make this presentation available through the OpenVMS Freeware. Also, please check with Gembase to see which options they make available to the RMS end users.
|