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. To overcome the issue of dependent writes across volumes and to create a consistent image  of the client data, a FlashCopy operation must be performed on multiple volumes as an  atomic operation. To accomplish this method, the IBM Spectrum Virtualize supports the  concept of  Consistency Groups . FlashCopy commands can then be issued to the FlashCopy Consistency Group and,  therefore, simultaneously for all of the FlashCopy mappings that are defined in the  Consistency Group. For example, when a FlashCopy  start  command is issued to the Consistency Group, all of  the FlashCopy mappings in the Consistency Group are started at the same time. This  simultaneous start results in a point-in-time copy that is consistent across all of the FlashCopy  mappings that are contained in the Consistency Group. A Consistency Group aggregates FlashCopy mappings, not volumes. Therefore, 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. Table 10-1 lists the FlashCopy properties and maximum configurations. FlashCopy property Maximum Comment FlashCopy targets per source 256 This maximum is the number of FlashCopy  mappings that can exist with the same source  volume. FlashCopy mappings per system 4096 The number of mappings is no longer limited by  the number of volumes in the system, so the  FlashCopy component limit applies. FlashCopy Consistency Groups  per system 255 This maximum is an arbitrary limit that is policed  by the software. Table 10-1 FlashCopy properties and maximum configurations Maximum configurations Consistency Group with Multiple Target FlashCopy Chapter 10. Copy Services  475