 |
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.
|
|
|
|
|
