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).
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 the storage controllers attached to your system support
minimerge, 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.
HSC and HSJ controllers support minimerge. Minimerge
support is planned for HSG controllers.
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.
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
to SDA.
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.
Accessing the dump file with the SDA command COPY or
the SDA command ANALYZE/CRASH on a merging system disk will significantly
degrade I/O performance on the volume. Accessing the dump file with
the DCL command COPY on a merging system disk will have the same
effect.