> Alan, Steffen,
>
> > > I think you are also talking about the db engine shadow mechanism
> - not
> > the Win2003 Disk Shadow Setup for shared volumes to which I was first
> > referring in answer to a question about Win2003 suitability.
> > > Am I right?
> >
> > I don't know, but I suggest: No. What he writes is just true for volume
> > shadow copies.
>
> I intended to talk about a shadowing on the file system level.
> Which Win2003 may or may not implement correctly.
>
> Regards,
> Peter Jacobi

OK - here's my take on this now:
Shadow by the OS may be the same as mirroring the disk (or maybe not) I
don't know. It may also be different to system restore(XP) - in fact I think
it is quite different.

System Restore(XP) actually copies the file when it's accessed and does this
to pre-registered file type (by extension) and that's why it need to
disabled for FB or FB files need their extension changed to avoid it. It's
effect, as we know, is to stall initial connections to a DB while the copy
is done.

People using WInServer2003 have experienced that same slow connection effect
and we have (assumed?) that shadowing is the cause. Perhaps it is - maybe it
isn't.

Now WinServer2003 Shadow according to the documentation effects shares only.
i.e. you need to share a volume of folder to have shadow take on the task of
shadowing. Assuming that the shadowing is implemented as we would like, this
still means that your db is in a share. This is not really recommended in a
production environment. I, for one, like my DBs in a place which is not
visible to just anyone with share viewing permissions. There are other ways
around this - perhaps the share can be visible only to admins and still have
shadowing work - don't know, haven't tested it.

Finally WinServer2003 shadowing has to be compared with FB Server shadowing.
The latter (FB) runs a shadow of the database and all writes to the DB are
carried out twice, to two differnt locations. It's done by the server which
manages it's own file space and data storage. The OS shadowing would need to
be "listening" to disk writes and then interrupt the disk to ask it to write
what it just wrote again in a location under it's control. Logically and
physically these 2 operations are different. I think I would rather have FB
do the mirroring and not the OS but these things may prove equal in final
roundup. Both these methods have a performance price to pay. Both methods,
as we have already discussed, a best considered as a hardware failure
safeguard. Both methods will instantly propogate DB curruptions if indeed
they occur in the source DB.

Alan