First shadow copy

[Uwe Zessin]

It's the old "doctor it hurts - then don't do that"...

I would not bother with INITIALIZE/SHADOW and do it the old-fashioned way. That has always worked, will hopefully continue to work properly [;-)] and you have to spend the I/Os to make the members look the same anyway.

[Jan van den Ende]

Wim,


But if I now initialize a sybase file, the disks of the shadow sets do not contain the same info because they were not erased. So, depending on which disk you use, you get other data.


I have some trouble understanding that.
After initialising a Sybase database, you read data from some area in it before that was written to? How would you expect to read anything with any meaning?

Oh, wait.
Are you
1. Initting a shadowSET /noerase
2. Mount ONE member
3. Init your database one the 1-member set
4. Only NOW add the other member(s)
5. Then getting strange results?
Is this your action sequence?

Hmmm. Would be a stupid way of doing things, but nevertheless, the shadow driver SHOULD recognise the existing 1-member set to have been written to, and so requiring COPY.

Jan

[Uwe Zessin]

Step 4. should cause a shadow copy, because the members will have different generation numbers.

Any change to a shadow set will cause an increase of the generation number - well, it is a datetime to be precise and there is something more involved to cover cases where the clock has been set back.

[Wim Van den Wyngaert]

Jan,

1. Initting a shadowSET /noerase
2. Mount 2 members
-> no merge or copy
3. Init your database
-> big file is taken without init of info in it
4. Then getting strange results

Just stupid madness but :
I allocate 1 GB for the db. DB-x read the uninitialized file from disk1 and calculates a checksum. This is written to disk1 and disk2 of the shadow set. Then it reads the info again but from disk2 (due to change in prefered path). This will not be OK because the garbage is different and thus the checksum is not correct.

A bug. The mount command should result in a merge.

Wim

[Jan van den Ende]

Wim,

yes, a bug.

But for me, the bug is in Sybase:
It READs data that is purely random (it never WROTE it), but it still uses it for conclusions. THERE is the hole in the logic!

Jan

[Wim Van den Wyngaert]

Jan,

Yes it would be a bug in Sybase but more certainly it is a bug in VMS. At no moment should 2 members of a shadow set return different data.

Help should say "only use /noerase when you are sure the applications using the disk is not using uninitalized disk fragments".

Wim