Filter
Top Products
118 IBM System Storage DS6000 Series: Copy Services with IBM System z
type of workload. This topic has been discussed in 10.4, “FlashCopy impact on applications”
on page 115.
Still, in general, NOCOPY is the preferred method, but you should also think about the
following considerations when choosing either COPY or NOCOPY:
Using NOCOPY - The argument here is that the impact caused by the I/O resulting from
the COPY option is more significant than that of the NOCOPY option, where less I/O
activity resulting from collisions occur. Still, since the background copy only occurs when
the writes are destaged from nonvolatile cache, there is typically negligible impact. If the
workload is cache friendly, then potentially all of the operations will be served from cache,
and there will be no impact from collisions at all.
Using COPY - The goal of using COPY is to quickly complete the background copy and
hence the overlapping situations between FlashCopy and application processing end
sooner. If COPY is used, then all I/Os experience some degradation because they
compete for resources with the background copy activity. However, this impact may be
somewhat less than the impact to the individual writes that a collision causes.
If FlashCopy NOCOPY is active during a period of high application activity, there could be
a high rate of collisions, that is, destages being delayed so that the track image can be
read and then written to the FlashCopy target track to preserve the point-in-time copy. The
destage delay could cause degradation of the performance for all writes that occur during
the delay destage periods. Note that it is only the first write to a track that would cause a
collision, and only when that write gets destaged. The reads do not suffer the
collision
degradation
.
If using the COPY option, consider also these tips:
Examine the application environment for the highest activity volumes and the most
performance-sensitive volumes.
Consider arranging the FlashCopy order such that the highest activity and most
performance-sensitive volumes are copied early and the least active and least
performance-sensitive volumes are copied last.
The intent here is to minimize the potential for collisions.
If a background copy is the desired end result and FlashCopy is to be started just before or
during a high-activity period, consider the possibility of starting with NOCOPY and converting
to COPY after the high-activity period has completed.
One might also want to examine the use of incremental FlashCopy in a high performance
sensitive-activity period. Incremental FlashCopy automatically uses the COPY option, so if
the NOCOPY option was previously selected, using incremental FlashCopy may impact
performance by causing a full background copy.
If the incremental FlashCopy approach is chosen, it might be best to create a FlashCopy
COPY relationship during a quiet time. To minimize the amount of data to be copied when
taking the desired point-in-time copy, schedule an incremental refresh sufficiently in advance
Tip: One approach to achieve a specified FlashCopy order would be to partition the vol-
umes into priority groups. Issue the appropriate FlashCopy commands for all volumes, but
use COPY on only the highest priority group and NOCOPY on all other groups. After a
specified period of time or after some observable event, issue FlashCopy commands to
the next highest priority group from NOCOPY to COPY. Continue in this manner until all
volumes are fully copied.