Business Copy and Track Changes and shared memory

[Paul Hawkins]

I am planning on having a number of business copies from a set of primaries.
The possibility is that the BC' volumes would not be sync'd back to the primaries for perhaps weeks, even months (they are going to be used for production testing & development).
My worry is that, the track-changes on the primary disks (that is recorded in shared memory) would actually exceed the amount of shared memory available. In this case the amount of shared memory is 1.5 GB.
The amount of primary is approx 1TB and there are 5 BC's of this.
Thanks in advance.

[Jordan Bean]

No sync for over a week? Why worry about track changes? Just disassociate the BCVs from the primaries to vaporize the track tables and free up the cache.

[Peter Mattei]

First thing you have to understand is, that you do not keep data in Shared Memory (SM), only control information. In your case track maps. So while BC pairs are active SM just keeps a flag of any updated track that has to be copied. Data itself is copied asynchronously via the Cache.
When using the BCs volume for test etc. you have the choice of either suspending a pair or split it permanently.
Please read the BC manual on http://www.hp.com/cposupport/manual_set/lpg28386.pdf for further information.
Cheers
Peter

[Keith Clark]

I just wanted to add to Peter's reply.

As Peter stated and is described in detail in the manual, it is simply a "track map" or bitmap that is kept in shared memory. There is one for the P-Vol and one for each S-Vol. When a track on a PVOL or S-Vol is changed (write), the bitmap in shared memory for that track is flipped (0 to 1 or 1 to 0) or marked dirty.

When you resync, it merges the two maps to determine what is "dirty" on both sides and syncs up the data.

You could I guess try to calculate the amount of memory based upon the Open Emulation tables. (15 tracks per cylinder * number of cylnders per Emulation type)* number of pairs ~= bytes. So for a single pairing of an Open 3 = (15*3338)*2 = 100140 bytes.

I wouldn't worry to much about the calculations though, the XP is smart enough to limit the number of pairs that you are able to create based upon the amount of shared memory available. That's why they always list a range of pairs you are able to create in the glossy brochures.

Keith

[Vincent Fleming · Accepted solution]

The bitmaps you are talking about are fixed in size (by nature). Keith is correct in that the XP will not allow you to run out of shared memory by creating too many pairs (and, therefore, too many bitmaps).

Good luck!