How to speed up a shadow copy on an idle system?

[Clark Powell]

I'm doing a shadow copy between two (eva5000) disks on an idle OpenVMS 8.3 system, (ES45.) The copy is going very slowly. I am happy that this process is not fast on a busy system but this system has only to do this shadow copy and nothing else. The disk IO is about 1/4 of what I see during a backup. Is there a way to speed this up?

[Jim_McKinney]

The system logical name

SHAD$COPY_BUFFER_SIZE

controls the amount of data that can be written in a single IO by the server during a copy operation. I once read that 112 was the optimal value for EVAs though I have not done any testing with this. Values from 31 to 127 are valid. My understanding is that the default is 127 when the logical is not defined.

$ DEFINE/SYSTEM SHAD$COPY_BUFFER_SIZE 112

[Robert Walker_8]

Gday,

Dont have experience with EVAs but wouldnt they have some mirroring capability between them then using OpenVMS to shadow copy the array.

Wouldnt a snapshot and a copy be faster in a quiet period or do you have to ensure updates are passed on? We sometimes killed shadow merges as they were woeful compared with shadow copies - but this was on HSJ based equip - many years ago.

Basically shadowing is a background task - unlike Smart Arrays and likely EVAs which one can set rebuild priorities to high. I dont believe there is any priority stuff with Host Based Shadowing - certainly not in sysgen anyway.

Check out http://www2.openvms.org/kparris/s2003_volshad_perf.ppt#950,18,Speeding Shadow Copies it indicates a backup/physical and shadow is faster than shadow copy.

Robert.

[Volker Halle]

Clark,

if you look at page 17 of the Keith Parris presentation (see link above), you'll find that a full shadow-copy with different data on the 2 disks needs to do lots of IOs - muc more than a BACKUP/PHYSICAL.

Volker.

[Paul Beaudoin]

Clark

We have used these logicals in the past to control exactly this:

SHAD$MERGE_DELAY_FACTOR ! Specifies the relative delay in shadow merges from 100 (slow merge) - 1000 (fast merge) (200 default)

SHAD$MERGE_DELAY_FACTOR_DSA* ! Sets SHAD$MERGE_DELAY_FACTOR for a specific disk

Full disclosure: I've not used this in some years so canot guarantee they work now as in VMS 7.x.

Paul

[Volker Halle]

Paul,

as the logical name says, this logical only affects MERGEs, not COPIEs.

The SHADOW_COPY operation is believed to have a higher priority than merges, so these logicals were invented to somehow limit the performance impact of merges.

Volker.

[Paul Beaudoin]

Volker,

I wasn't aware of that ...
Thanks - I am now a bit better educated!

Paul

[Andy Bustamante]

See $HELP INIT/SHADOW for one option you might consider if this is a new shadow set.

As Volker points out, you can also use $BACKUP/PHYSICAL to cut down the first shadow copy time. Be sure to mount the target disk /over=shadow after the backup to avoid problems.

Andy Bustamante