Dependent write operations

To preserve the integrity of data that is being written, ensure that dependent writes are run in the intended sequence of the application.

Protection against incomplete write operations and the extended database recovery that might result is provided by the system.

The following list is a typical sequence of write operations for a database update transaction.
  1. A write operation updates the database log so that it indicates that a database update is about to take place.
  2. A second write operation updates the database.
  3. A third write operation updates the database log so that it indicates that the database update completed successfully.

The database ensures correct ordering of these writes by waiting for each step to complete before the next step starts. The database log is often placed on a different volume than the database. In this case, ensure that FlashCopy operations are performed without changing the order of these write operations. For example, consider the possibility that the database (update 2) is copied slightly earlier than the database log (update 1 and 3). In this scenario, the copy on the target volume contains updates (1) and (3) but not (2). If the database is restarted from a backup that was made from the FlashCopy target disks, the database log indicates that the transaction successfully completed. However, the transaction did not complete successfully; the transaction is lost and the integrity of the database is compromised.

You can process a FlashCopy operation on multiple volumes as an atomic operation to create a consistent image of user data. To use FlashCopy this way, the system supports the concept of a consistency group. A consistency group can contain an arbitrary number of FlashCopy mappings, up to the maximum number of FlashCopy mappings that are supported by the system . You can use the command-line interface (CLI) startfcconsistgrp command to start the point-in-time copy for the entire consistency group. All FlashCopy mappings in the consistency group start at the same time, resulting in a point-in-time copy that is consistent across all of the FlashCopy mappings contained in the consistency group.

For more information about the maximum configuration support, see the following website.