Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

Corruption on RMS Files

Berney
Occasional Contributor

Corruption on RMS Files

Hello,

Since few month, we experience a corruption on a database file.

Here's the result of a ANAL /RMS [file.dat] command :
----------------------------
Check RMS File Integrity 24-OCT-2006 12:52:42.86 Page 2
DKA100:[APP.DATA]FIPIEC.DAT;13


Current Extent Start: 420400, Blocks: 1800, Used: 630, Next: 421030
Default Extend Quantity: 1800
Total Allocation: 32340

KEY DESCRIPTOR #0 (VBN 1, offset %X'0000')

Next Key Descriptor VBN: 2, Offset: %X'0000'
Index Area: 1, Level 1 Index Area: 1, Data Area: 0
Root Level: 3
Index Bucket Size: 3, Data Bucket Size: 3
Root VBN: 60133
Key Flags:
(0) KEY$V_DUPKEYS 0
(3) KEY$V_IDX_COMPR 1
(4) KEY$V_INITIDX 0
(6) KEY$V_KEY_COMPR 1
(7) KEY$V_REC_COMPR 1
Key Segments: 1
Key Size: 26
Minimum Record Size: 26
Index Fill Quantity: 1536, Data Fill Quantity: 1536
Segment Positions: 0
Segment Sizes: 26
Data Type: string
Name: "PIECE_ID"
First Data Bucket VBN: 4
*** VBN 419275: Bucket check byte is out of phase.
*** VBN 419275: Record at offset %X'01C3' has invalid data record compression.
*** VBN 419275: Record id at offset %X'029A' is duplicate or too large.
*** VBN 419275: Reserved flag bit 7 is set.
*** VBN 419275: Invalid combination of primary data record flags.
Unrecoverable error encountered in structure of file.


The analysis uncovered 5 errors.
----------------------------

We try a lot of things, but none of them are working. If anybody can help me !! I really don't know how can I do to repair this...

Thanks a lot
9 REPLIES
Volker Halle
Honored Contributor

Re: Corruption on RMS Files

Hi,

welcome to the OpenVMS ITRC forum.

First start with an ANAL/DISK to make sure, that your disk structure is o.k. and you don't have dual allocated blocks on that disk. Just to prevent possible future corruptions.

Then DUMP/BL=(COUNT=1;START:419275) DKA100:[APP.DATA]FIPIEC.DAT;13 to look at the binary data on disk, to try to spot any particular data corruption pattern.

The error seems to be in the index structure, so you may be able to use CONVERT/FDL to recover/reconstruct the contents of the file.

Volker.
Berney
Occasional Contributor

Re: Corruption on RMS Files

Hi Volker,

Thanks for your interest, I'm not sure I can use CONVERT /FDL.
My FDL file contain this error :

ANALYSIS_OF_AREA 2
RECLAIMED_SPACE 0
*** VBN 419275: Bucket check byte is out of phase.
*** VBN 419275: Record at offset %X'01C3' has invalid data record compression.
*** VBN 419275: Record id at offset %X'029A' is duplicate or too large.
*** VBN 419275: Reserved flag bit 7 is set.
*** VBN 419275: Invalid combination of primary data record flags.
Unrecoverable error encountered in structure of file.

What do you think about that ?
Thanks
Volker Halle
Honored Contributor

Re: Corruption on RMS Files

Don't you have the original FDL from creating that file ? Or an old one without errors ? Maybe this error output does not even confuse CONVERT/FDL. It's worth a try...

Volker.

Berney
Occasional Contributor

Re: Corruption on RMS Files

I tried but not working and I don't have any old FDL file... :-(
I'll search one or create an empty DAT file to create the FDL file...

I'll let u know
Jan van den Ende
Honored Contributor

Re: Corruption on RMS Files

Berney,

I am with Volker on that last one.
AFAIK, the ANALYSIS part of a generated FDL file will not be used in building a file using that FDL.

But, let's invite Hein van den Heuvel.
Berney: He is _THE_ RMS authority! He spent many years in Engeneering maintaining, supporting, and extending RMS.
If anyone knows anything of RMS, that's Hein!

Proost.

Have one on me.

jpe
Don't rust yours pelled jacker to fine doll missed aches.
Hein van den Heuvel
Honored Contributor

Re: Corruption on RMS Files

I have helped with several of these cases and frequently posted replies. For example check out:
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=886747

But more specifically check out slides 39-50 in:
http://h71000.www7.hp.com/freeware/freeware60/rms_tools/rms_tuning.ppt

Since the corruption exists for a long time already one apparently does not care too much for the actual lost data, but more about ongoing access. In that case, the most likely solution is to 'patch around' VBN 419275.
Here is a basic outline:

DUMP /BLOC=(STAR=419272,COUNT=9) FIPIEC.DAT


$ANAL/RMS/INT FIPIEC.DAT
>POS/BUCK 419275
---> is NEXT BUCKET indicated as 419278? Good!
>POS/BUCK 419272
---> is NEXT BUCKET indicated as 419275? Great!

Now just get out your bit chissel (my ZAP tool from that freeware directory) and change the next pointer in 419272 to become 419278 write to the file, and convert the file.

There MIGHT be further corruption of course.
You can possibly readily recover abotu 400 bytes of userdata from the remain of bucket 419275, but that is probably not worth it.

As alternative to patching you can convert until it breaks, and then read teh rest of the file with a program where you get a reasonable start key value from bucket 419275 or 419278 (if that is the next one).

Doe the file have non-null alternate keys?
You can try reading it by alternate key (CONVER/KEY=n) and then re-convert to the original.

For mere money I can help you work through this in detail. Send me an Email @gmail.com
with my whole name as username (16 characters)

Good luck,

Hein van den Heuvel
HvdH Performance Consulting



Phil.Howell
Honored Contributor

Re: Corruption on RMS Files

Sometimes this works (if you are lucky)
First sort on primary key creating a sequential file, then convert back to indexed using original fdl.
Phil
Hein van den Heuvel
Honored Contributor

Re: Corruption on RMS Files

Any progress / resolution on this?
Regards,
Hein.
comarow
Trusted Contributor

Re: Corruption on RMS Files

If you must have that file, and you can't go back to an earlier version of the file and add the updated data, HP Support does have a few people that can data recovery. It is not part of Remedial and Advisory, so don't expect the service to be free.