Dependent write operations

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

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.