I don't think it's correct to say there is no way to throttle a Copy operation. (I had hoped you would supply answers to the questions I posed in my first post so that additional suggestions could be made.)
Re: Why can we throttle Merges but not Copies?
A Volume Shadowing Copy operation is designed to restore redundancy, and it is initiated under the direct control of the system manager (by doing a MOUNT command). So Shadowing tries to do its best to restore complete redundancy as soon as possible. If redundancy isn't as important as performance, one could defer the start of the Copy operation.
A Merge, on the other hand, will be initiated by events beyond the control of the system manager (a system crash or failure on a node which has a shadowset mounted), and may occur at times which may be inconvenient, so the initial design, as well as later additions like the SHAD$MERGE* logical names, were intended to minimize the impact of the Merge on user application I/Os.
Re: What can we do to throttle Copy work?
SHADOW_MAX_COPY is one control knob, but since you have the Sybase data on only a single disk unit, this has limited control.
If you used host-based RAID software to form a stripeset of shadowsets (RAID 0+1 array), you could leave SHADOW_MAX_COPY set to 1 and only one of the "n" shadowsets within that array would be doing a Copy at once, and also, as each of them completed in turn, that fraction of the total disk area would then become available for Sybase reads. This means performance would increase over time during the Copies. With only a single disk unit, the target unit only becomes available to service read operatoins once the entire area has been copied.
There are also a number of optimizations noted in my presentation from Amsterdam on Volume Shadowing Performance cited earlier in this thread. You can "undo" (or do the "opposite" of) some of those optimizations if they tend to favor Copy operations over Sybase reads. For example, if most of the Sybase reads are randon, controller read-ahead caching would benefit Copy operations more than Sybase reads, so you might want to turn read-ahead caching off, at least during the Copy. Reads seem to be what Sybase needs most here, so turning off write-back caching on the Copy target unit might slow the Copy. Similarly, if Sybase reads tend to be very small (we know that Shadowing Copy operations will be large: 127 blocks in size), then using a smaller value for NISCS_MAX_PKTSZ might slow down the Copy.
If the data tends to be very different at the time you re-introduce the target disk, then one optimization is to do a BACKUP/PHYSICAL operation beforehand to make the data (mostly) identical, which changes the target disk operations from a combination of reads and writes to a sequential stream of reads, but that would tend to run faster and have higher impact on Sybase reads. So in your case, where it is the source volume where performance is more critical, it might tend to throttle the Copy operation and have a lower impact on the source volume if you instead did an $INITIALIZE/ERASE on the target volume before adding it to the shadowset.
If the data tends to be very similar at the time you re-introduce the target disk, then it would be best to use a Mini-Copy if possible.
