IBM V7000 Introduction And Implementation Manual page 391

The database ensures the correct ordering of these writes by waiting for each step to
complete before starting the next step. However, if the database log (updates 1 and 3) and the
database itself (update 2) are on separate volumes, when creating FlashCopy images it is
possible for the FlashCopy of the database volume to occur before the FlashCopy of the
database log. This situation can result in the target volumes seeing writes (1) and (3) but not
(2), because the FlashCopy of the database volume occurred before the write was
completed.
In this scenario, if the database was restarted using the backup that was made from the
FlashCopy target volumes, the database log indicates that the transaction had completed
successfully when in fact it had not. This situation occurs because the FlashCopy of the
volume with the database file was started (bitmap was created) and the write updates (1 and
3) to the logs completed before the write to the database (2) had completed to it's volume in
turn. Therefore, the transaction is lost and the integrity of the database is in question.
To overcome the issue of dependent writes across volumes and to create a consistent image
of the client data, it is necessary to perform a FlashCopy operation on multiple volumes in
order of operation using consistency groups.
With the use of consistency groups the action of stopping and flushing the database volumes
would all occur simultaneously so that all three of the write operations would be flushed to
their volumes as required to make the database transaction complete and the FlashCopy
image across all the volumes would be consistent.
A FlashCopy consistency group can contain up to 512 FlashCopy mappings. The more
mappings you have, the more time it takes to prepare the consistency group. FlashCopy
commands can then be issued to the FlashCopy consistency group and simultaneously for all
of the FlashCopy mappings that are defined in the consistency group. For example, when
starting the FlashCopy for the consistency group, all FlashCopy mappings in the consistency
group are started at the same time, resulting in a point-in-time copy that is consistent across
all FlashCopy mappings that are contained in the consistency group.
A consistency group aggregates FlashCopy mappings, not volumes. Thus, where a source
volume has multiple FlashCopy mappings, they can be in the same or separate consistency
groups. If a particular volume is the source volume for multiple FlashCopy mappings, you
might want to create separate consistency groups to separate each mapping of the same
source volume. Regardless of whether the source volume with multiple target volumes is in
the same consistency group or in separate consistency groups, the resulting FlashCopy
produces multiple identical copies of the source data.
The consistency group can be specified when the mapping is created. You can also add the
FlashCopy mapping to a consistency group or change the consistency group of a FlashCopy
mapping later. Do not place stand-alone mappings into a consistency group, because they
become controlled as part of that consistency group.
FlashCopy consistency group states
At any point in time, a FlashCopy consistency group is in one of the following states:
Idle or Copied:
All FlashCopy Mappings in this consistency group are in the Idle or Copied state.
Preparing:
At least one FlashCopy mapping in this consistency group is in the Preparing state.
Chapter 9. IBM Flex System V7000 Storage Node Copy Services
371