Can the BACKUP command produce a smaller RMS indexed file?

[da1nonly1]

Hi,

I have a very big indexed file that I need to store and almost never add new records to it. I suspect that the size of the file is the result of it’s FDL with which he was created and not the actual volume of records in it. If I use the BACKUP command to move this file to a different location (not for the purpose of a backup set), will the output will be a smaller size? Currently after a year of adding records the size is (note the allocation):

Size: 1974552/1974552
Created: 31-JAN-2006 08:50:23.33
Revised: 18-DEC-2006 16:27:02.22 (842)
Expires:
Backup: 18-DEC-2006 23:41:27.97
File organization: Indexed, Prolog: 3, Using 3 keys
In 3 areas
File attributes: Allocation: 1974552, Extend: 65535, Maximum bucket size: 9

Here are parts from the FDL:

AREA 0
ALLOCATION 1700003
BEST_TRY_CONTIGUOUS yes
BUCKET_SIZE 9
EXTENSION 65535

AREA 1
ALLOCATION 31041
BEST_TRY_CONTIGUOUS yes
BUCKET_SIZE 9
EXTENSION 7767

AREA 2
ALLOCATION 243504
BEST_TRY_CONTIGUOUS yes
BUCKET_SIZE 6

If you know a better way to move the file and saving space please propose.

Thanks to everybody.

[Volker Halle · Accepted solution]

Hi,

no - BACKUP will not reduce the size of this indexed file.

You can use ANAL/RMS/FDL/STAT to analyze the RMS attributes of this file, then EDIT/FDL to create a more approrpiate FDL and then use CONVERT/FDL to create a new file.

For more details, let's wait for Hein ;-)

Volker.

[Kris Clippeleyr]

Hi,

BACKUP cannot make a file smaller.
An indexed file can be made smaller (or larger) by using the CONVERT command.
For a good explanation of how to optimize (tune) your indexed files have a look at the section
10.3 Optimizing and Redesigning File Characteristics
from the
Guide to OpenVMS File Applications
manual.

Hope this helps,
Kris (aka Qkcl)

[Hein van den Heuvel]

Volker and Kris are correct. Read their replies carefully and award point accordingly.

http://forums1.itrc.hp.com/service/forums/helptips.do?#28

Attach the output from ANA/RMS/FDL as .txt if further help is needed.

The sum of the indicated RMS area initial allocations match the file allocation. If the FDL shown is the one used for the file, then this means the file has not grown.

What problem are you trying to solve?
The file is only 1 GB big.
Don't waste too many resources (your time) trying to trim it!

If the you need a backup copy, to be as small as possible, then do the ANAL/RMS thing to get a good estimate and change the FDL to have a single AREA with bucket size of 63, allocation reduced by 20%, and extent set to a lowish 6300. In the key sections set all compression on. Convert/nosort/fast/secon=3/stat=full (for grins).

The max bucket size of 63 increases data key compression, decreases end-of-bucket record fill gap, decreases bucket overhead.

For smaller production versions do NOT increase the bucket size to the max, as this may cause too much contention and time wasted scanning through the buckets for the rigth record instead of using the indexes to the max.

hth,
Hein van den Heuvel
HvdH Performance Consulting.

[Wim Van den Wyngaert]

Backup can alter the size of files when /truncate is used as a qualifier.
But this won't help in your case because the file is 1974552/1974552 (always x=x for indexed files, I think).

Wim

[John Gillings]

It depends on what you mean by "make it smaller". Some tape drives will compress data, and I think very recent versions of BACKUP can also do compression. That will make the *backup copy* smaller than the original, but of course it will be restored to full size.

If you want to "archive" the indexed file, and really won't be adding any new records, you could optimise the FDL to minimise space at the expense of cost of adding records. Make the buckets as large as possible, with a fill factor of 100%, turn on key and data compression.

Be aware that adding records will be expensive, and will rapidly degrade the performance of the file.

re: Wim,

>(always x=x for indexed files, I think).

Not true. Indexed files can have allocation beyond EOF, which can be safely truncated. The question is if the space recovered is worthwhile. Truncating the file will make any future extends slightly more expensive, and potentially increase the fragmentation index of the disk.

[Wim Van den Wyngaert]

John is right.

Extension allocation is defined on file level (e.g. 1000).
Each area can however specify its own extention size and I guess when this is e.g. 100, then 1000 will be added and 900 will will not be used until needed.

Wim

[Robert Gezelter]

Wim,

I beg to differ on the point of file extension. WADU, there are several different levels of settings that have an impact on the extension of a file, to wit:
- the volume setting specified by INITIALIZE (or SET VOLUME)
- the setting specified when the volume was mounted
- the setting contained in the SYSTEM default for the RMS Extend Size
- the RMS Extend Size setting in the individual process' RMS profile (Controlled by SET RMS)
- the values specified to RMS (on a file or area basis)

Also, things are rounded up to the next highest whole cluster (ODS-2 cluster).

I would concur with Hein's comments, except to add that if insertions are rare, and reorganizing the file is not a problem, I would consider checking the fill percentage in the various areas.

- Bob Gezelter, http://www.rlgsc.com