Corruption on RMS Files

[Berney]

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

[Volker Halle]

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]

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]

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]

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]

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

[Hein van den Heuvel]

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]

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]

Any progress / resolution on this?
Regards,
Hein.

[comarow]

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.