IBM System storage DS6000 Series, Redbook

Page: 483 / 578

Chapter 30. IIBM TotalStorage Rapid Data Recovery
459
solution. However, in a real disaster (fire, explosion, or earthquake) you can never expect the
components of your complex to fail all at the same moment. Failures will be intermittent and
gradual, and the disaster will occur over many seconds or even minutes. This is known as a
Rolling Disaster.
The architecture of a viable disk mirroring disaster recovery solution must
avoid data corruption caused during a Rolling Disaster.
In any operating system, the sequence in which updates are being made is what maintains
the integrity of the data. If that sequence is changed, data corruption will occur. The correct
sequence must be maintained within a volume, across volumes, and across multiple storage
devices. For instance, in Figure 30-1, we show the relationship between a database and its
log, which demonstrates the requirement for maintaining I/O integrity. Data consistency
across the storage enterprise must be maintained to insure data integrity.
Figure 30-1 Sample update sequence in a database
The order of Dependent Writes across volumes must be maintained at remote locations.
Failure to do so results in data corruption. The data consistency is lost.
In Figure 30-2 we illustrate this concept with an example. When a database update is about to
take place, the change is first logged in the database log files at both the primary and
secondary volumes (step 1). Assume the database data file is updated at the primary volume,
but the update does not reach the remote volume that contains the mirrored data file. The
primary location is not aware of the write failure to the secondary volume (step 2). The
database update is marked complete in the log files at both the primary and remote locations
(step 3). The result is that the secondary site log files say the update was done, but the
updated data is not in the database at the secondary location. There is no way to know that
the data was corrupted.
Primary
Primary
Log
Volume
1. Log Update
3. Mark Log Complete
Database
Volume
2. Update Database
Secondary
Secondary