topic Re: Shadow sets merge after system reboot in Operating System - OpenVMS

Shadow sets merge after system reboot

Andrew Rycroft — Wed, 21 Jul 2004 02:31:36 GMT

Hi,

I am using Volume Shadowing on my OpenVMS system. I find that after a system reboot the shadowsets go into a shadowset merge state. This takes a long time to complete.

Are there any ways this can be avoided ?

Thanks
Andrew

Re: Shadow sets merge after system reboot

Bojan Nemec — Wed, 21 Jul 2004 02:57:11 GMT

Hi,

I remember that there was a work arround about merging shadowsets. The work arround says that you must open a dummy file on each shadow set before rebooting. So you put an open/close in your SYSHUTDWN.COM. But I dont remember where I read this. I never try, because reboots are so rare on VMS ;)

Bojan

Re: Shadow sets merge after system reboot

Volker Halle — Wed, 21 Jul 2004 03:13:08 GMT

Andrew,

a shadowset only enters a merge state, if it has not been cleanly dismounted. During shutdown, this can happen due to open files preventing the dismount (look for appropriate %DISM-W- messages during shutdown). If this is the case, add SHOW DEV/FILES DSAx: commands into SYSHUTDWN.COM and make sure you close all open files.

Volker.

Re: Shadow sets merge after system reboot

labadie_1 — Wed, 21 Jul 2004 05:11:21 GMT

Hello Volker !

Happy to see you here.

:-)

Gerard

Re: Shadow sets merge after system reboot

Ian Miller. — Wed, 21 Jul 2004 05:32:41 GMT

as has already been said its due to disk not being properly dismounted due to open files. The suggestion of doing SHOW DEV/FILES for each disk in SYSHUTDWN is a good one as it allows you to discover what is still open and then yu can add commands to close the files. This will minimise the occurance of this problem.

Re: Shadow sets merge after system reboot

Martin P.J. Zinser — Wed, 21 Jul 2004 21:18:47 GMT

Hi Andrew,

one reason for this can be installed images residing on the disk or server processes (e.g. HTTP) having files open. As others pointed out,
a show dev/files in the shutdown procedure should give you some clues.

Greetings, Martin

Re: Shadow sets merge after system reboot

Wim Van den Wyngaert — Thu, 22 Jul 2004 09:30:57 GMT

Stop all users, batch jobs and applications properly (e.g. stop/id).

Also check for spool files and other system things. As long as reference count in show dev/full is not zero, something is open (non system disk).

Also, if some station/server is doing MSCP IO to the disk you may have a shadow merge.

Wim

Re: Shadow sets merge after system reboot

Volker Halle — Thu, 22 Jul 2004 10:43:58 GMT

Wim,

if another node in the cluster does have this shadowset mounted (required to do MSCP IO), the same principles apply to that node: if it leaves the cluster without properly dismounting that shadowset, it will cause a merge on that shadow set (on one of the remaining nodes in the cluster, if SHADOW_MAX_COPY allows)

Volker.

Re: Shadow sets merge after system reboot

Richard W Hunt — Thu, 22 Jul 2004 14:15:14 GMT

If the reason for the reboot was predictable, you can do most of what you need by remembering to include the REBOOT and REMOVE options in your answers to the last question of the SHUTDOWN script.

But if the reboot was spontaneous, I don't think there is a way to prevent the merge. Nor do I think you WANT to, despite what you might think you want to do. That merge is going to prevent your systems from having inconsistent disk data on the two members of the shadow set. Which is, after all, the whole point of having a shadow set anyway. If they ain't consistent, they ain't shadows, either.