Hello Sean,

On Tue, 20 Jan 2004 13:08:21 -0500,
Leyne, Sean wrote :

> > How does this differ from mirroring?
>
> I believe you meant to say "How does this differ from shadowing?"
>
> Most significantly, it differs as follows:
>
> - Shadowing works by applying page changes, in sync with the live
> database, which means that shadow I/O performance, can significantly
> affect the live database performance, due to operation latency. This
> means that shadowing to any other computer than the master server is
> 'problematic' with respect to performance.
>
> Mirroring works by building a list of page which have changed since a
> point in time and then build an incremental update package to be applied
> to the slave database, accordingly normal database performance is not
> significantly/measurably affected.
>
> - Shadowing requires full-time/online access to the slave database. In
> fact, if a shadowing connection is lost, the shadow 'set' is broken.
>
> Mirroring the slave database can be updated in a 'batch' mode, without a
> full-time connection to the master database. Further, mirroring will
> support multiple slave databases, each with its own database 'state'
> information.
>
> Sean

This is more or less a kind of journalling where the journal is sent
over to another server where it is used to bring another copy of the
DB up to date, asynchronously instead of synchronously as the
current shadowing feature works.

Except that I suppose there would not really be a journal but you
would rely on some page versioning like with nbackup (there are many
details in this proposal common to nbackup btw - but I guess this was
part of your discussions).

Will it be easy to send set of pages to the remotes such as only
committed transactions are reflected in the remotes ?

--
Best Regards,
Olivier Mascia