For synchronous operations there is additional overhead for every
write. Several factors can affect the overall performance of write
operations, especially for synchronous copy operations. The following
work load characteristics can affect synchronous write performance:
- Write content — There is an inherent performance penalty
on synchronous operations that are associated with write operations.
As a result, work loads with high read-to-write ratios experience
much less impact than those that are write intensive. As more writes
occur to the primary site storage control, there is a corresponding
effect on performance.
Some examples of extremely write-intensive
work loads are SPOOL volumes and database logging volumes, which can
affect I/O response times dramatically in any synchronous copy operation.
A possible solution to this high write-intensive work load is to spread
the SPOOL volumes across multiple volumes to minimize queueing.
- Blocksize — Work loads with small blocksizes experience
better performance than do work loads with large blocksizes. As the
write blocksize increases, the affect on work load performance also
increases. One example of a work load that has this impact is DB2® deferred writes. A possible
solution is to spread the work load across several volumes.
- Overall channel demand — As the demand increases on the
host channel that services the primary application’s storage control,
the impact to overall performance also increases. Spread the work
load across several storage controls if possible.
- Sequential write operations — Batch processing operations
typically exhibit high sequential write operations. Synchronous copy
operations can result in longer batch windows.
Evaluate dump restore
activities to PPRC-managed volumes. PPRC uses a data flow algorithm
to copy data from primary volumes to secondary volumes during initialization.
To best optimize this algorithm, avoid restoring data sets or volumes
to PPRC-managed volumes. Although PPRC supports restore operations,
doing so increases the amount of data that PPRC must copy from the
primary to the secondary volumes. You may choose to allocate a scratch
volume on the primary system, and then restore data to that volume.
Establish the PPRC session, and allow normal primary-to-secondary
volume processing to continue.