text: 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.*