MiniCopy

[Carl Bennett]

Has there been anything new released about MiniCopy and the stale bitmap issue? All I can find is an alert from about 6 months ago saying that there was a potential problem.

I am trying to work some DCL to compensate for it, but I've hit a complete roadblock in trying to deal with three disk shadow sets, and wanted to know if there even still was a problem before I went any further...

[Kris Clippeleyr]

Carl,

On our "newer" systems (the ones with V7.3-2 on them) we use MiniCopy, and haven't seen a problem with it. The only thing you have to think about is when dismounting a member of the shadowset to use DISMOUNT/POLICY=MINICOPY=OPTIONAL.

Greetz,

Kris (aka Qkcl)

[Ian Miller.]

Carl,
I hope you are up to date with VMS732_SHADOWING-V0200 (from Sept 2004). You may also want to look at the HBMM kit as there is some new functionality which may be of interest.

[Carl Bennett]

Unfortunately, we are generally not working with clusters, which makes HBMM not of real value for us...

However, all of the sites that we are supporting have volume shadowing on the production database, so minicopy makes a lot of sense...

The problem is with the three deep shadow sets, where you could have 2 shadows dismounted (not a good idea, i know, but I have to deal with the fact that it happens)

If shadow A dismounts, backs up, and then remounts, it deletes it's bitmap when done, but if the copy aborts for any reason, then the bitmap stays out there...

If shadow B is then used for something else, it creates a bitmap, which could then be orphaned, etc until you have a large amount of memory tied up into bitmaps that (hopefully) won't be used...

I can clean all bitmaps before dismounting the shadow disks, but I don't want to do that if I am aborting a minicopy, and I don't want to not do it if I run the risk of using a stale bitmap...

Unfortunately, I can't come up with a real great way to tie in what bitmap goes with what drive at a given instant. The bitmaps don't reveal anything usefull untill after the disks are remounted and the minicopy is in progress...

[Volker Halle]

Carl,

you seem to be referring to Customer Advisory document VO030527_CW01 (released 2-JUN-2003). Unfortunately, this document has never been updated with resolution information.

Searching through previous SHADOWING patches, it looks like this problem has been solved under CLD reference CFS.100146 in the following patches (or any higher versions of these SHADOWING kits):

VMS722_SHADOWING-V0200 (released 15-OCT-2003)
VMS73_SHADOWING-V0300 (released 24-SEP-2003)
VMS731_SHADOWING-V0100 (released 18-SEP-2003)

The problem mentioned does not seem to affect V7.3-2.

Volker.

[Carl Bennett]

Unfortunately, the release notes from the v2 kit don't address the issue at all, the release notes that I have from the Shad v1 kit look like this:

carl$ ty VMS732_SHADOWING-V0100.RELEASE_NOTES

=======================================================================
Hewlett-Packard OpenVMS ECO Release Notes
=======================================================================

ECO NUMBER: VMS732_SHADOWING-V0100
PRODUCT: OpenVMS Alpha OPERATING SYSTEM V7.3-2
UPDATE PRODUCT: OpenVMS Alpha OPERATING SYSTEM V7.3-2

carl$

I tried to pull the old patches off the website for a little more information, but wasn't able to find them.

Although I believe you that steps have been taken to prevent old bitmaps from being used, I am still faced with the possibility of them lingering, as in this case, in which I dismounted a shadow disk, mounted it /over = (id,shad) and then remounted as a shadow set member in order to see whether the bitmaps remained. In this case, I have a completed full copy, plus a bitmap retained in memory that will never be used...


carl$ SHOW DEV DSA5

Device Device Error Volume Free Trans Mnt
Name Status Count Label Blocks Count Cnt
DSA5: Mounted 0 CARL$WORK 1332960 1 2
$1$DKB300: (JKL) ShadowSetMember 0 (member of DSA5:)
$1$DKB400: (JKL) ShadowSetMember 0 (member of DSA5:)
carl$ SHOW DEV DSA5 /BITMAP
Device BitMap Size Percent Type of Master Active
Name ID (Bytes) Populated Bitmap Node
DSA5: 00060019 2020 0.04% Mini Copy JKL Yes
carl$

I would agreed that in this case, deleting them is easy enough to do, but what I am trying to do is to create a function that tends to this sort of thing automatically. You see, while all of our clients own at least one of these servers, very few of them have a management staff with any kind of real VMS knowledge whatsoever, and the people that they leave to run their backups have almost none at all.

[Volker Halle]

Carl,

I have kept copies of most of the older patch .TXT files, so I was able to find the reference to the solution of this problem.
Most of thoses patches have been superseeded by newer ones, which don't list old problems solved...

The HP CSC Sidney pages still have some of the older patches online:

http://ftp.hp.com.au/pub/ecoinfo/ecoinfo/992.htm

The solution is listed under:

o Host Based Volume Shadowing (HBVS) Mini Copy Problem

You may find a reference to the solution in the OpenVMS Alpha V7.3-2 release notes, but I doubt that all 'old problem solutions' will be referenced. I'm sure that this problem is solved in V7.3-2, at least if you make sure to run with a more recent SHADOWING patch.

If you plan to override a disk after removing it from the shadowset, don't use DISM/POL=MINICOPY, otherwise you'll keep adding bitmaps to the system, which will never be used. There is an absolute limit on the number of bitmaps in the system, so after some time, you can't create any more.

If you wnat to 'clean up', then - after all BACKUPs have been run and all disks been remounted into their respective shadowsets again - just delete all remaining bitmaps.

Volker.

[Jan van den Ende]

Carl,

so, if I read Volker:

If you wnat to 'clean up', then - after all BACKUPs have been run and all disks been remounted into their respective shadowsets again - just delete all remaining bitmaps.

and I read your wish:

deleting them is easy enough to do, but what I am trying to do is to create a function that tends to this sort of thing automatically


Combine the two, and all that remains is writing it!

You need a procedure that runs periodically, or triggered by an event like Backup-finished.
The procedure will have to know somehow what the "steady state" for a shadow set looks like (2 member / 3 member). It will check for steady state, and all members being full members (no merging, no copy target). If all these conditions are met, find the associated bitmap, and delete it.

In view of your 'many' maintained sites, it better be a generic routine, with necessary variables acquired from system scan and/or parameter table.

All the rest is the coding.

hth.

P.S.
If you get it all done, consider posting in dcl.openvms.org
If you do, set up a thread here to tell about it.

TIA.

Proost.

Have one on me.

Jan

[Carl Bennett]

If I could just pull the disk drive name out of an unstarted minicopy, I'd have something for you this afternoon... that's the one piece I'm missing...

[Jan van den Ende]

Carl,

to get to the occurrence of Minicopy, one memeber has to be withdrawn from a steady-state shadowset.
Using policy=minicopy creates the bitmap, and triggers it being populated.
Thereafter, the ONLY wat to get to a steady-state shadowset is by re-mounting that member, and going trough eigther a Merge or a (mini-)Copy phase. During those phases NOT ALL members are full members, but either the set is merging or one member is copy-target.
All members being ful member means any associated bitmap can be deleted.

Proost.

Have one on me.

Jan

[John Gillings]

Carl,

Not sure I understand why you say this: "Unfortunately, we are generally not working with clusters, which makes HBMM not of real value for us..."

MiniMerge isn't dependent on clusters. There are conditions which can trigger a merge on standalone nodes, all of which will benefit from HBMM - potentially greatly reducing your merge times.

As far as I'm aware there are no outstanding issues on systems with the latest related patch kits (any of UPDATE, FIBRE_SCSI, SHADOWING, SYS & HBMM)