"combfilter" <asdf@asdf.com> wrote in message
news:MPG.1c59aed886b1220598968e@news.newsreader.com...
> Hilary/Paul.
>
> I have a couple of questions:
>
> 1. Does the log reader start to read once you have setup a
> table for publication? Or does it' wait till you have
> actually "pushed" the subscription out. For example. I setup
> a publication for a subscriber who is not online yet. They
> should be up by friday. I obviously have not pushed their
> subscription out yet. Is their log reader already working?
> Is my distributon db log growing?
>
> 2. What is no sync replication exactally? I am guessing that
> is just doesn't care about the snapshot or what is on the
> other side, it just starts pushing any transaction from that
> point on. Is this correct. The reason I ask, is that I have
> some very large tables I need to push over. I was wanting to
> just back up the entire db, send it to the subscriber, have
> them restore the tables I am going to replicate, and then do
> a "no sync" push to them. I am wondering though, what
> happens to all of the transactions that are coming in new
> from the time I sent the drive , to the restore, to the
> replication no sync push. Does the log reader just hold it,
> and once they are online, i just push it over?
>
> tia.

> 1) It waits for a subscription for named subscriptions, and if you have
> anonymous it starts reading when the publication is created. The log reader
> writes to the subscription database, so the distribution db and its log are
> growing.
>
> 2) a no sync subscription is a subscription where no sync is done. The
> moment your publication is created transactions start flowing or queuing in
> the distribution database. You must either use SQL statements to apply these
> transactions (not recommended if you are under appreciable load), or create
> the replication stored procedures yourself. You are responsible for putting
> the schema and data in the subscription database yourself.
>
> If you have large tables, I'd create my publication and subscription using a
> no-sync. I'd stop the distribution agent. Then I'd put the schema in place,
> and bcp the data over and then run a validation to see how out of sync I am
> and which tables are out of sync. Then it is a matter of cobbling a
> consistent state between the two databases. This can be a moving target and
> it can take some time to achieve consistency/convergence.
>
>
>