If a multiple-member
system disk shadow set is mounted and the system fails, the resulting
crash dump information is initially written to the dump file on only
one of the shadow set members. Once the dump operation has successfully
completed, the unit number of the member with the written dump file
is printed on the console device. Error messages display if the dump
cannot be written (for example, because the path to the dump unit
is unavailable or is unsuitable).
|NOTE: The crash dump file is normally written to the
original boot device, provided that it is available and on line. If
that device has been removed from the shadow set, the dump file is
written to the current master member of the shadow set, provided that
it is available and on line.|
If you are using either HBMM or HSC or HSJ storage
controllers, you can enable a minimerge on a shadowed system disk
and write a dump to a nonshadowed, nonsystem disk of your choice by
doing the following:
Set the SHADOW_SYS_DISK
system parameter to 4097
Set the DUMPSTYLE system
parameter to the appropriate setting for your system for a nonshadowed,
nonsystem disk of your choice.
Configure a disk for dump
off system disk (DOSD), as described in the HP OpenVMS System
Manager's Manual, Volume 2: Tuning, Monitoring, and Complex Systems.
|NOTE: HSC and HSJ controllers support minimerge.|
If you accidentally enable a minimerge to a system
disk that receives a crash dump and you have not set up DOSD, you
may be able to recover if you know which disk contains the valid dump.
Remove that member, remount it, and remove the dump from that member.
Once the system is rebooted, the shadowing software
automatically begins a merge operation. This merge operation automatically
propagates the dump file to all of the other members and also corrects
any other inconsistencies caused by the system failure.
You can reboot the system from either the original
boot device or the current master member device. At boot time, if
the paths to all of the members of the shadow set are on the same
type of adapter, the shadowing software correctly designates the current
master and dump device on all of the booting nodes. At boot time,
several OPCOM messages display information about the status of the
dump device and the reboot condition of the system.
You cannot reboot the system unless the boot device
is a current member of the shadow set. When a multiple member system
disk shadow set loses its boot device, a warning is printed on the
console device, and an OPCOM message is displayed.
|CAUTION: Do not add shadow set members to an existing system
disk shadow set in any startup command procedure. Upon system reboot,
all of the data, including the dump file, can be overwritten and therefore
lost if volume shadowing automatically performs a copy operation.
For more information, see the Caution in “Booting from a System Disk Shadow Set”.|
On some systems, you can stipulate that multiple
devices be members of the same system disk shadow set. Please refer
to the system-specific manual for further details.
If you use the System Dump Analyzer (SDA) to access
the dump file on the virtual unit during the merge operation, you
can enter the SDA command ANALYZE/CRASH to examine the dump while
the shadow set is undergoing a merge operation. If SDA accesses portions
of the dump file that have not yet been merged, shadowing resolves
inconsistent data across the shadow set before the read is returned
You can also use the Crash Log Utility Extractor
(CLUE) commands to access the dump file on the virtual unit during
a merge operation. CLUE commands can automatically create a footprint
of the crash to a .LIS file and store it for future reference.
|NOTE: Accessing the dump file with the SDA command COPY
or the SDA command ANALYZE/CRASH on a merging system disk significantly
degrades I/O performance on the volume. Accessing the dump file with
the DCL command COPY on a merging system disk has the same effect.|