IBM DS6000 Manual Do Utilizador

Página de 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.