|
HP OpenVMS Systemsask the wizard |
|
The Question is:
We have a corrupted file (We don4t konw how) and it can be repaired using
analyze/disk/repair (It just says that some bad blocks there may be in that
file). Is there another tool to repair this?. The output of analyze/rms is the
following:
Check RMS File Integrity 19-JAN-2004 10:10:01.95 Page 2
$FILES:[FILES_JOL]JUGMAL.IDX;1
Current Extent Start: 1003465, Blocks: 250008, Used: 61356, Next: 106482
Default Extend Quantity: 63744
Total Allocation: 250008
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: 12, Data Bucket Size: 12
Root VBN: 1003381
Key Flags:
(0) KEY$V_DUPKEYS 0
(3) KEY$V_IDX_COMPR 0
(4) KEY$V_INITIDX 0
(6) KEY$V_KEY_COMPR 1
(7) KEY$V_REC_COMPR 1
Key Segments: 2
Key Size: 19
Minimum Record Size: 36
Index Fill Quantity: 6144, Data Fill Quantity: 6144
Segment Positions: 12 26
Segment Sizes: 9 10
Data Type: string
Name: "juego+juegovta+sorteo+ticket"
First Data Bucket VBN: 4
*** Attempt to read block with invalid VBN 796360.
Unrecoverable error encountered in structure of file.
The Answer is : All disks are subject to these errors, and as stated over in topic (6926), you must maintain disk BACKUPs, or utilize disk shadowing (mirroring), or other data archival procedures to recover from cases of block-level disk failures, or from catastrophic disk failures. You will typically want to replace the disk, and restore the BACKUP -- disk block errors were traditionally survivable, but bad blocks now do tend to be harbingers of impending disk failures. For information on the bad block handling available within OpenVMS, please see topic (6926) -- you can attempt to rewrite the entire disk to trigger bad block revectoring, but this may or may not resolve the underlying problem. If this is not an isolated disk block failure, rewriting the entire volume will not likely be the appropriate approach. Replace the disk. In all likelyhood, the RMS file with the reported bad block error is an innocent victim of the underlying bad block. For desperate cases (eg: BACKUP, what BACKUP?), you may be able to restore the data from the unaffected portions of the current file. This effort can be very time consuming, the outcome is unpredictable, and the effort involved can prove expensive. If you choose to attempt local restoration, create a small application which reads the file seqeuntially, writing out each record read into a new file. Once the error is encountered, attempt reading by higher and higher key values until records are retrieved. Write the record retrieved, and resume the sequential read and write processing. You might be able to locate potential key values for the intermediate processing from an older copy of the file, or from other parallel data stored on this or on another disk. You might also be able to use Record File Address (RFA) processing, using RFA operations within the damaged range to try to recover the data. You might also be able to use knowledge of the existing data records, for instance, to simply copy the records from the older (archived) version of file if it is known that the records affected by the disk corruption have not changed. There is an RMS_TUNING presentation available in the RMS_TOOLS area of the OpenVMS Freeware, and you can find an overview of an RMS Indexed file and its organization, and some ideas on patching the file back into operation. You will want to make a BACKUP/PHYSICAL of the disk before attempting recovery, of course. You can also choose to utilize HP Services to assist you in an attempt to recover the contents of this or other corrupted files -- if such recovery is possible, of course.
|