| Hi Alain:
if your have index corruption the attached example will show
you the procedure (this was a response in a recent case).
If you have some other corruption you should file an IPMT
case.
From your printout it look like you have the recent version
of the surgeon.
regards,
Bob Wheater
--------------------------- only an example --------------------------
You don't need to worry about the NONAME-E-NOMSG messages as it
is normal.
The scanrx.out indicates that you have index corruption. The
surgeon tool can be used to repair this.
First make a current checkpoint file by shutting down the
server (normal shutdown: @sys$startup:dns$server_shutdown.com).
Keep the server down during the repair so that no updates occur.
Next make a copy of the checkpoint file and make the modifications
to the copy (keep the original file in case something
goes wrong).
Below is the extract of the corruption from the scanrx.out:
VBN 4794 (DataEntry) 16 blocks, N: 429e3c P: 42523c Free: 2150 Recs: 3
16 2 1 - 1 6 DG48X4
16 2 1 - 1 6 DG49X4
16 2 1 - 1 6 DG50X4
VBN 4810 (DataEntry) 16 blocks, N: 42c03c P: 427c3c Free: 2528 Recs: 3
20 2 1 - 1 9 DG50X4-IP
16 2 1 - 1 6 DG51X4
20 2 1 - 1 9 DG51X4-IP
VBN 4826 (DataEntry) 16 blocks, N: 42e23c P: 429e3c Free: 1604 Recs: 2
CORRUPTION DETECTED: Key 1 out of sequence.
20 2 1 - 1 9 DG51X4_CH
20 2 1 - 1 9 DG50X4-IP
VBN 4842 (DataEntry) 16 blocks, N: 43043c P: 42c03c Free: 3064 Recs: 3
16 2 1 - 1 6 DG51X4
20 2 1 - 1 9 DG51X4-IP
20 2 1 - 1 8 DG51X4IP
VBN 4858 (DataEntry) 16 blocks, N: 43263c P: 42e23c Free: 2468 Recs: 2
20 2 1 - 1 9 DG51X4_CH
16 2 1 - 1 6 DG52X4
VBN 4874 (DataEntry) 16 blocks, N: 43483c P: 43043c Free: 236 Recs: 3
20 2 1 - 1 9 DG52X4-IP
20 2 1 - 1 9 DG53X4-IP
20 2 1 - 1 9 DGB1EM-IP
In this case several keys are out of sequence. The actual sequence
should be:
DG50X-IP
DG51X4
DG51X4-IP
DG51X4IP
DG51X4_CH
DG52X4
The surgeon allows to remove blocks or records with the block.
In this case I chose to do the fix in two commands:
surgeon -exciser 4810 1 2 checkpoint_file_name
surgeon -exciseb 4826 4841 checkpoint_file_name_in checkpoint_file_out
The first command removes 2 records from block 4810 (note: records
are numbered starting with zero). this does an in place modification.
When it asks for "confirm" answer with "Y" and the blocks written
should be greater than zero.
The second command removes a group of blocks that contain bad keys and
creates a new checkpoint file. When you use excise block you specify
a starting and ending blocks. The starting block is labeled VBN #
for the DataEntry. Then ending block for the entry is one less
then the VBN # of the next DataEntry.
I have chosen this method of fixing to preserve all the unique keys
that are present.
after the modifications the file looks like:
VBN 4794 (DataEntry) 16 blocks, N: 429e3c P: 42523c Free: 2150 Recs: 3
16 2 1 - 1 6 DG48X4
16 2 1 - 1 6 DG49X4
16 2 1 - 1 6 DG50X4
VBN 4810 (DataEntry) 16 blocks, N: 42c03c P: 427c3c Free: 5416 Recs: 1
20 2 1 - 1 9 DG50X4-IP
VBN 4826 (DataEntry) 16 blocks, N: 43043c P: 42c03c Free: 3064 Recs: 3
16 2 1 - 1 6 DG51X4
20 2 1 - 1 9 DG51X4-IP
20 2 1 - 1 8 DG51X4IP
VBN 4842 (DataEntry) 16 blocks, N: 43263c P: 42e23c Free: 2468 Recs: 2
20 2 1 - 1 9 DG51X4_CH
16 2 1 - 1 6 DG52X4
VBN 4858 (DataEntry) 16 blocks, N: 43483c P: 43043c Free: 236 Recs: 3
20 2 1 - 1 9 DG52X4-IP
20 2 1 - 1 9 DG53X4-IP
20 2 1 - 1 9 DGB1EM-IP
VBN 4874 (DataEntry) 16 blocks, N: 436a3c P: 43263c Free: 44 Recs: 3
and -scanrx no longer gives the "CORRUPTION DETECTED: " message.
Finally you should rename the new checkpoint file back to the
original name and place in the directory that it was found in.
Then you can restart the server and try skulking the directory.
Note: if updates have occurred in the checkpoint file since you
ran the surgeon for your last update you may have to
make some adjustments in the commands that you use
to make sure the keys are in a valid sequence.
You can use the above description as an example.
Regards,
Bob Wheater
|