RMS datafile analyze and convert

[Robert Srdoch]

In an environment where filesizes are not changing much but hte data is changing (ie. adds and deletes) is it necessary to do an analyze to create a new fdl before every convert or could the fdl be saved and re-used for a time (possibly doing an analyze every quarter to half year?).

My gut is telling me that since the filesizes are relatively constant, we are not gaining anything by re-creating the fdl every time and that we should just focus on doing the converts on the files that are experiencing the data changing.

what are your opinions and experiences?

Thanks in advance !!

[Phillip Thayer]

Robert,

We have a similar situation and have found that a weekly optimize of the file structure helps the RMS performance of the files termendously. We are running a VAX 4701 so any performance increase we can get is a boost for us.

I have attached the DCL procedures that were written to do our file optimizations.

Phil

[Hein van den Heuvel]

In you situation you can safely re-use the already optimized FDL file.

In such a stable situation, you also want to consider to manually fine-tune the FDL maybe using the interative version of EDIT/FDL as a helper, or use an excellspreadsheet or such like the the one I posted in the freeware: http://h71000.www7.hp.com/freeware/freeware60/rms_tools/rms_fdl.xls

For sure you can skip the ANAL/RMS in the main processing window and optionally just run the EDIT/FDL/NOINTER after having tweaked the 'real' variables in there: record count, cluster size, average record size.

You may still want to run ANAL/RMS 'leisurly', after the convert, on the old file to make sure that no hidden corruption occured, or to verify alternate key behaviour. Note however that CONVERT already reads all databauckets, so that critical sanity check already happened.

I would encourage you to try my RMS_TUNE_CHECK from the freeware, or as attached in:
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1013023
It looks for tuning 'stuff' that ANAL/RMS might not call out.

hth,
Hein.

[John Gillings]

Robert,

Not intending to criticise Phil's procedure, but I think it's important to point out that EDIT/FDL/NOINTER does not really "optimize" the FDL. Indeed, it actually does the exact opposite!

Consider, to "optimize" you use your knowledge of the way the file is used, and apply preferences (usually speed vs space) to tune the file so that the operations that are most important to you perform optimally.

EDIT/FDL/NOINTER chooses middle-of-the-road tuning so that no specific operations are favoured and we strike a balance between speed and space.

To truly optimize a file, you need to decide what you want to perform best, create an FDL that favours those operations the use CONVERT to apply them. Once created, the FDL can (should!) be reused on every CONVERT. It will only need changing if the use of the file changes.

For example, an indexed file which is strictly READONLY might have a bucket fill factor of 100% and fairly flat bucket tree, but one which will have many updates might have only 40% fill factor and a taller structure. EDIT/FDL can't know your intentions, so can't make those decisions.