440 Implementing the IBM Storwize V7000 with IBM Spectrum Virtualize V8.2.1
FlashCopy mappings can be part of a Consistency Group, even if there is only one mapping 
in the Consistency Group. If a FlashCopy mapping is not part of any Consistency Group, it is 
referred as stand-alone.
Dependent writes
It is crucial to use Consistency Groups when a data set spans multiple volumes. Consider the 
following typical sequence of writes for a database update transaction:
1. A write is run to update the database log, which indicates that a database update is about 
to be performed.
2. A second write is run to perform the actual update to the database.
3. A third write is run to update the database log, which indicates that the database update 
completed successfully.
The database ensures the correct ordering of these writes by waiting for each step to 
complete before the next step is started. However, if the database log (updates 1 and 3) and 
the database (update 2) are on separate volumes, it is possible for the FlashCopy of the 
database volume to occur before the FlashCopy of the database log. This sequence 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 case, if the database was restarted by using the backup that was made from the 
FlashCopy target volumes, the database log indicates that the transaction completed 
successfully. In fact, it did not complete successfully because the FlashCopy of the volume 
with the database file was started (the bitmap was created) before the write completed to the 
volume. Therefore, the transaction is lost and the integrity of the database is in question.
Most of the actions that the user can perform on a FlashCopy mapping are the same for 
Consistency Groups.
11.1.5  Crash consistent copy and hosts considerations
FlashCopy Consistency Groups do not provide application consistency. It only ensures 
volume points-in-time are consistent between them. 
Because FlashCopy is at the block level, it is necessary to understand the interaction 
between your application and the host operating system. From a logical standpoint, it is 
easiest to think of these objects as “layers” that sit on top of one another. The application is 
the topmost layer, and beneath it is the operating system layer. 
Both of these layers have various levels and methods of caching data to provide better speed. 
Because the Storwize V7000 and therefore, FlashCopy sit below these layers, they are 
unaware of the cache at the application or operating system layers. 
To ensure the integrity of the copy that is made, it is necessary to flush the host operating 
system and application cache for any outstanding reads or writes before the FlashCopy 
operation is performed. Failing to flush the host operating system and application cache 
produces what is referred to as a crash consistent copy. 
The resulting copy requires the same type of recovery procedure, such as log replay and file 
system checks, that is required following a host crash. FlashCopies that are crash consistent 
often can be used after file system and application recovery procedures.