- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- A question about secondary keys in RMS indexed fil...
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
Discussions
Discussions
Forums
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
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
тАО06-22-2010 05:02 PM
тАО06-22-2010 05:02 PM
I'm working on a procedure which uses the CONVERT utility to cleanup some RMS indexed files on a regular basis.
Some of the files are quite small so I probably won't bother with them, but I thought I would do a trial run anyway.
I have Hein's RMS_TUNE_CHECK utility which is very handy for quanitifying the CONVERT benefits, but the output from one of my small files has me slightly confused.
Here's what it tells me about the file before it is CONVERTed:
$ sidr -t prod_data:iasf001.dat
- RRVS: 128 moved records in 308 record sample. 41.0%. Convert! Smaller fill?
Key 1
Found 314 sidr records in 1 buckets
There were 308 user data record pointers.
There were 17 deleted, 0 RU_delete and 0 RU_update pointers.
Top Ten Table of Sidrs with more than 1 duplicate
Duplicate count, Buckets, Key value
--------------------------------------------------------
2 1 25
2 1 40
2 1 61
2 1 68
2 1 76
2 1 117
2 1 139
2 1 149
2 1 155
2 1 157
$
OK, nothing strange about that. I then CONVERT the file and have another look:
$ convert/share prod_dat:iasf001.dat sys$login: /stat
CONVERT Statistics
Number of Files Processed: 1
Total Records Processed: 308 Buffered I/O Count: 35
Total Exception Records: 0 Direct I/O Count: 140
Total Valid Records: 308 Page Faults: 351
Elapsed Time: 0 00:00:00.10 CPU Time: 0 00:00:00.07
$ sidr -t iasf001.dat
Key 1
Found 308 sidr records in 2 buckets
There were 308 user data record pointers.
There were 0 deleted, 0 RU_delete and 0 RU_update pointers.
No duplicate key values found.
What puzzles me is the CONVERTed file appears to have lost a lot of duplicate keys. Or is it the case that those duplicate keys would have been pointing to deleted records?
Thanks,
Jeremy Begg
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-22-2010 07:11 PM
тАО06-22-2010 07:11 PM
Re: A question about secondary keys in RMS indexed files
In case you have not already read this, you may find this helpful -
http://h71000.www7.hp.com/openvms/journal/v2/articles/rms.html
This is a well written technical journal article on
"RMS Performance: Duplicate key chains" by Hein.
Hope this helps.
Regards,
Murali
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-22-2010 07:13 PM
тАО06-22-2010 07:13 PM
SolutionFirst of all, like you said, there is little or no point to worry about converting/tuning a file like you describe.
You are correct in questioning the output for those simple cases to be able to deal with more complex/problematic cases should they arise.
Anyway, there are two effects that may play a role here.
1) When record with duplicate alternate key is deleted, or the alternate key is change and thus effectively deleted, RMS leaves a stub flag byte behind to help concurrent streams retain their position for '$GET NEXT' operations.
These are the "17 deleted" tune check referred to in your example.
2) RMS can do 'fast deletes' on indexed files. In that case, RMS only deletes the main record during a $DELETE and does not bother to try deleted the corresponding alternate key pointers to the deleted records. When a subsequent access is done using such alternate key, then it will find the record deleted upon de-reference and at that time the alternate key will be deleted while the structures to get there are already/still in the buffer cache. This is a great optimization.
Hope this helps,
Hein van den Heuvel
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-22-2010 09:29 PM
тАО06-22-2010 09:29 PM
Re: A question about secondary keys in RMS indexed files
Hein, thanks for the detailed reply (which confirms what I suspected what is going on).
I was about to ask "how do I enable 'fast delete' but then I remembered I have the RMS reference manual close at hand, and found this listed as the RAB$V_FDL option in the RAB$L_ROP field. Is there a way to have this occur automatically for all programs which might access the file (i.e. without having to modify all calls to $DELETE or their high-level language equivalents)?
Thanks,
Jeremy Begg
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-22-2010 10:29 PM
тАО06-22-2010 10:29 PM
Re: A question about secondary keys in RMS indexed files
>> how do I enable 'fast delete'
>> RAB$V_FDL option in the RAB$L_ROP field
Yes thats right. The Fast delete performance option of RMS is controlled by the
RAB$V_FDL option in the RAB's RAB$L_ROP field.
>> Is there a way to have this occur automatically for all programs which might
>> access the file
By default, the fast delete option would be off. You need to enable it using the
RAB$V_FDL option. I dont think there is any other "automatic" way to trigger the
fast delete option to get enabled automatically without using the RAB$V_FDL option.
(i.e. you have to modify the program using the $DELETE to get the fast delete feature)
Regards,
Murali
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-22-2010 11:20 PM
тАО06-22-2010 11:20 PM
Re: A question about secondary keys in RMS indexed files
I presume the only way to use that information in a program would be for it to call FDL$PARSE() as part of the process of opening the file.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-22-2010 11:39 PM
тАО06-22-2010 11:39 PM
Re: A question about secondary keys in RMS indexed files
>> I noticed that File Definition Language has a "CONNECT" clause allowing
>> the file designer to specify various run-time options.
Yes, thats correct. Using the CONNECT attribute you can specify run time
options to your program.
>>I presume the only way to use that information in a program would be for it to
>>call FDL$PARSE() as part of the process of opening the file.
Yes again.
You use the EDIT/FDL utility to specify the run time option using the CONNECT
attribute. The program has to use the FDL$PARSE and FDL$RELEASE
routines in order to get the run time values.
Check the following link which talks more about the run time options -
http://www.openvms.compaq.com/doc/73final/4506/4506pro_025.html
-> Chapter 9 Run-Time Options
Regards,
Murali
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-22-2010 11:50 PM
тАО06-22-2010 11:50 PM
Re: A question about secondary keys in RMS indexed files
Thanks for confirming my suspicions.
Regards,
Jeremy Begg