IBM System storage DS6000 Series Redbook page 484

Figure 30-2 Sample Rolling Disaster
So, the issue is that the disk subsystem can't do it all and we must avoid this Rolling Disaster
system problem.
For this reason, it is strongly recommended that, at a minimum, Consistency Groups be put in
place for any mirroring solution. Consistency Groups are an implementation of technology
that assists with the consistency of application data capable of dependent writes. To
guarantee a fully consistent remote copy, multiple volumes require a Consistency Group
functionality. ESS and DS6000/DS8000 Remote Copy microcode already has the
Consistency Group function for both z/OS and open systems. SAN Volume Controller Metro
Mirror's and DS4000 Remote Mirror's microcode has a Consistency Group function for open
systems.
If any volume within a Consistency Group is unable to complete a write to its counterpart in
the Remote Copy relationship, an Extended Long Busy (ELB) for mainframe environments or
a SCSI Queue Full condition for open systems will be issued, preventing further writes to any
of the volumes within the Consistency Group. This wait period is the perfect time to issue a
freeze to all volumes involved to maintain consistency.
Figure 30-3 illustrates this mechanism. If a write is unable to complete, the storage
subsystem will not back out incomplete transactions on its own. Instead the application will
need to recognize that the transaction was incomplete and take the appropriate actions. Once
the storage subsystem holds application I/O to the affected primary volumes, the write
dependent mechanism of the application prevents the Remote Copy secondaries from
becoming inconsistent.
460
IBM System Storage DS6000 Series: Copy Services with IBM System z
OK
OK
OK
Primary
Primary Secondary
Secondary
B C
L M
X Y
B C
L M
X Y
Left side disk data
does not match right
side. Is this the
problem?
Yes
1. Log Update
3. Mark Log
Complete
2. Database Update