Using analyze to repair sys$sysdevice

[Patrick_42]

Hi all,

I find that there is some data inconsistency in my VMS system disk.

Is it safe if i just do a "ANAYZE /DISK/REPAIR SYS$SYSDEVICE" to my sys$sysdevice ?

Regards,
Patrick.

[Huc_1]

Hello

It depend if you have a good backup prior to the inconsistency ? and if this is a critical system you are the only juge of that, but why dont you attach the analyze/disk sys$sysdevice output onto a reply to this message perhaps with a littel more informations some could tell you if it is harmless or not...

Also what do you mean by inconsitency ?

What ever I would take a system disk backup now !
just to be sure.

Jean-Pierre

[Stanley F Quayle]

If you're going to send us the output from ANALYZE/DISK, please don't have /REPAIR on it this time. That makes changes -- best to save /REPAIR until we've looked at it.

[Richard W Hunt]

First, be aware that because of caching, and particularly in a clustered environment, you will sometimes get errors with a mounted disk that you would not get if users were off. The one I recall is most common is something like an error where the index bitmap says something is allocated but the header itself says it is not allocated (or maybe I got that vice-versa.)

But unfortunately, the system disk is the oddball of the lot. (You can't dismount it and still analyze it.)

One of the factors you have to look at is whether the count of index bitmaps that are in error is the same as the size of the SYSGEN parameter ACP_FIDCACHE (I think). Also, I don't know if this potential for disagreement has been fixed. But I know that if you look at the stuff already written to the disk, it does not ALWAYS match the content reported through the F11ACP calls. This is because some data structures have been cached and are not yet written to the disk.

[Martin Johnson]

Your safest bet is to boot off another disk, then do the ANALYZE/DISK/REPAIR with the disk offline.

HTH
Marty

[Henk Boot]

Patrick,

another possibility is to use Ton Dorland's DFU Verify. You find this on the OpenVMS freeware CD. DFU verify is safe, very fast, has very handy features and it does not lock the disk as Analyze does (with repair option). The /Rebuild has been very useful to me. Here's the help text:

" The Verify option provides a function equivalent to ANALYZE/DISK, but many times faster. Verify will report files with invalid backlinks, lost files, and blocks which are allocated by more than 1 file. Also the BITMAP and QUOTA files are checked. The /FIX qualifier allows some basic repair actions without locking the disk. The /REBUILD qualifier will rebuild INDEXF.SYS, BITMAP.SYS and QUOTA.SYS if necessary. Note that /REBUILD will lock teh disk for a short period of time.

"

Just give it a try!

Cheers,

Henk

[Stanley F Quayle]

How about assigning some points to the responses?

Pointer to help on points:
http://forums1.itrc.hp.com/service/forums/helptips.do?#33

Thanks in advance.

[Mike Reznak]

Hi,

as Martin Johnson have sugested, boot from another disk before dooing analyze. This command will cause system to hang, while doing analysis. Not suitable behavior for mission critical system ;o).

Michal