any pros/ cons to having multiple Publications

sql2k sp3
Im going to start Replicating 40 or so tables. Is there
any good/ bad to each table going into its own Publication?
TIA, ChrisR
ideally you will want to group your publications into logical units for
administrative, functional, and performance reasons.
To make life simpler for yourself you should have a single publication. This
eases the administrative burden. However sometimes you will want to
replicate different tables on different schedules, ie some transactions are
required to be replicated real time, others must only be replicated once per
day.
You will get better performance if you group your articles that have dri
relationships into the same publications, and then create multiple
publications and use the independent_agent option on each publication. This
will create multiple distribution agents replicating to the same subscriber
db.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"ChrisR" <anonymous@.discussions.microsoft.com> wrote in message
news:01ef01c496a0$ed8c86c0$a401280a@.phx.gbl...
> sql2k sp3
> Im going to start Replicating 40 or so tables. Is there
> any good/ bad to each table going into its own Publication?
> TIA, ChrisR
|||> You will get better performance if you group your articles that have dri
> relationships into the same publications, and then create multiple
> publications and use the independent_agent option on each publication.
This
> will create multiple distribution agents replicating to the same
subscriber
> db.
Im going to be replicating to a denormalized db for reporting purposes only.
(Thanks to you ;-) ) Therefore, Im not going to include the dri as it will
be enforced on the Publisher. That being the case, theres really no logical
grouping I can use. What about just putting the really big tables into
they're own Publications and using the independent_agent option you
mentioned?
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:OvJMuQtlEHA.896@.TK2MSFTNGP12.phx.gbl...
> ideally you will want to group your publications into logical units for
> administrative, functional, and performance reasons.
> To make life simpler for yourself you should have a single publication.
This
> eases the administrative burden. However sometimes you will want to
> replicate different tables on different schedules, ie some transactions
are
> required to be replicated real time, others must only be replicated once
per
> day.
> You will get better performance if you group your articles that have dri
> relationships into the same publications, and then create multiple
> publications and use the independent_agent option on each publication.
This
> will create multiple distribution agents replicating to the same
subscriber
> db.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
>
> "ChrisR" <anonymous@.discussions.microsoft.com> wrote in message
> news:01ef01c496a0$ed8c86c0$a401280a@.phx.gbl...
>
|||separate them according to activity. I.e. if you have 10 really volatile
tables you are publisher 20 ones that are modified a couple of time an hour,
and 50 tables which are fairly static you could do 5 or 10 separate
publications, each with one or two of the volatile tables, 4 to 2 of the
less volatile tables, and 1 to 2 of the static tables.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"ChrisR" <chris@.noemail.com> wrote in message
news:uj$UMhulEHA.2020@.TK2MSFTNGP09.phx.gbl...
> This
> subscriber
> Im going to be replicating to a denormalized db for reporting purposes
only.
> (Thanks to you ;-) ) Therefore, Im not going to include the dri as it
will
> be enforced on the Publisher. That being the case, theres really no
logical
> grouping I can use. What about just putting the really big tables into
> they're own Publications and using the independent_agent option you
> mentioned?
>
> "Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
> news:OvJMuQtlEHA.896@.TK2MSFTNGP12.phx.gbl...
> This
> are
> per
> This
> subscriber
>