IBM System storage DS6000 Series, Redbook

Page: 140 / 578

116
IBM System Storage DS6000 Series: Copy Services with IBM System z
typically the preferred option. However, some workloads that contain a large number of
random writes and are not cache friendly might benefit from using the COPY option, which is
typically the preferred option.
Another important performance consideration is whether or not to use
incremental
FlashCopy. Under the right circumstances, incremental FlashCopy should have no impact on
the critical online write updates and should significantly shorten the period of time needed to
complete the periodic background copy.
10.5 FlashCopy options - considerations
Incremental
FlashCopy is only supported at the volume level. That is,
incremental
FlashCopy
does not support z/OS data set level FlashCopy. Though incremental may be used with
FlashCopy relationships established with either the COPY or the NOCOPY option, there are
some differences in how the COPY and NOCOPY relationships affect the application write
updates.
The COPY approach causes an initial copy of all source volumes, but then will only copy
changed tracks when the incremental resync command is invoked. The NOCOPY approach
does not perform an initial copy of the source volumes when the incremental resync
command is invoked, but does copy on all first updates to source tracks since the preceding
FlashCopy. Again, this copy only occurs when that track is destaged, so in many cases there
is no impact to application performance.
The designer needs to consider the consequences of bursts of background copy, initially and
following each resync (COPY option), which might impact the application, versus continuous
impact, when there are collisions that require a source to target copy before the write update
can complete (NOCOPY option).
If running incremental FlashCopy for an extended period of time, the COPY option could very
well be the proper choice.
10.6 FlashCopy scenarios
This section describes four scenarios. These scenario discussions assume that the primary
concern is to minimize the FlashCopy impact on application performance.
10.6.1 Scenario #1: Backup to disk
In environments where Recovery Time Objective (that is, how quickly you can return to
production after a failure) is of utmost importance, a FlashCopy backup to disk can help to
achieve an extremely fast restore time. As soon as the logical FlashCopy is complete, it is
possible to perform a reverse FlashCopy and restore your production data in seconds,
instead of the several hours it would normally take to retrieve the data from tape.
Note: The incremental FlashCopy resyncflash command does not have a NOCOPY
option. Using resyncflash will automatically use the COPY option, regardless of whether
the original FlashCopy was COPY or NOCOPY.