- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Can the BACKUP command produce a smaller RMS index...
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Forums
Discussions
Discussions
Discussions
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-18-2006 11:25 PM
12-18-2006 11:25 PM
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.
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-18-2006 11:37 PM
12-18-2006 11:37 PM
Solutionno - 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-18-2006 11:39 PM
12-18-2006 11:39 PM
Re: Can the BACKUP command produce a smaller RMS indexed file?
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)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-18-2006 11:58 PM
12-18-2006 11:58 PM
Re: Can the BACKUP command produce a smaller RMS indexed file?
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-19-2006 01:22 AM
12-19-2006 01:22 AM
Re: Can the BACKUP command produce a smaller RMS indexed file?
But this won't help in your case because the file is 1974552/1974552 (always x=x for indexed files, I think).
Wim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-19-2006 09:38 AM
12-19-2006 09:38 AM
Re: Can the BACKUP command produce a smaller RMS indexed file?
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-19-2006 06:10 PM
12-19-2006 06:10 PM
Re: Can the BACKUP command produce a smaller RMS indexed file?
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-19-2006 08:16 PM
12-19-2006 08:16 PM
Re: Can the BACKUP command produce a smaller RMS indexed file?
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