Replication Problem

Hi,
Please see this link
and help me
http://www.sqlservercentral.com/forums/shwmessage.aspx?forumid=7&messageid=220975&post=true
from
Dollerdoller wrote:
> Hi,
> Please see this link
> and help me
> http://www.sqlservercentral.com/forums/shwmessage.aspx?forumid=7&messageid=220975&post=true
Access denied on that link without signing up first. If you want help in
this newsgroup, please post your question here.
wadester|||Hi,
In configuring the merge replication i faced many poroblems and errors
but the last error i am facing is as follows.
pls let me know what to do to get rid of it
error :21007 Cannot add the remote Distributor. Make sure that the
local server is configured as a Publisher at the Distributor.
from
Doller

Replication performance question

Hello to all,

I have a performance question: we have a cluster with 2 SQL instances on 1 node (another instance is on another node, but no link with my current problem!). Let's call them C1SQL1 and C1SQL2.

This node is a Hyperthreaded Xeon 2.8Ghz with 1 gig of memory.

These 2 instances are using transactionnal replication and are configured as the distributor and publisher. C1SQL1 is not using much power, it's a small replication with around 10 agents. C1SQL2 is a bit heavier, with around 100 distribution agents. C1SQL2 has around 50 subscribers in 12 publications, but not all subscribers are used in each publications.

Once in a while, this cluster node impacts our production environment (since it's also a production server) and we're wondering if performance wise, it's really not powerfull enough to be the distributor?

I've isolated C1SQL2 on it's own logical CPU, and in idle mode, the replication workload (history, checking if new transactions are made) peaks at around 15-50% each 4-10 seconds.

Can I have any input on this?

Thanks!

Can you give some more detail, I'm not clear on what the problem/symptoms are. Regardless, have you been monitoring disk, memory and CPU to rule out hardware bottleneck? The replication workload you mention in the last sentence, are you talking about logreader agent or distribution agent? Is this SQL 2000 or 2005? Are you running Repl MOnitor in the background?

Replication on 130GB db

Is there anyone with some expirience in replicating such large database?
Maybe some good link or something like that. I would need trans replication
instructions.
regards,
DaliborIf you have a fast link between your publisher/distributor/subscriber,
replicating 130GB is still managble, especially when the amount of data
changes is relatively small in comparison with the total database size. We
are replicating bigger database than that with transactional replication.
With 130GB of data, it could be a major headache to re-snapshot your
publication, which may take a while in most environments. It can become a
major problem when you don't have a large maintenance window. For us, the
most common reason for requiring a new snapshot is new releases of the
application that introduce database schema changes. Once we have reined in
the developers and cut down the frequency of releases, we have been able to
support replicating 200~300GB databases.
--
Linchi Shea
linchi_shea@.NOSPAMml.com
"Dalibor Cvijetinovic" <dalibor@.ice.si> wrote in message
news:OC8DqnatDHA.2340@.TK2MSFTNGP12.phx.gbl...
> Is there anyone with some expirience in replicating such large database?
> Maybe some good link or something like that. I would need trans
replication
> instructions.
> regards,
> Dalibor
>|||Our amount of data that needs to be replicated is around 20-30GB. That is
the reason why I would like to change replication type.Currently I am using
snapshot/push replication. Our maintenance window is around 12 hours. But in
that time i must import some data which takes about 2 hours and then i do
snapshot/push replication of 130GB. That replication is lasting forever!!
After that i must replicate another db with 25GB.
I need to make trans replication or I will simply get ...
Furthere more this large scaled replication are not stable.
Can you give me some pointers on how to resolve this problem.
Dalibor
"Linchi Shea" <linchi_shea@.NOSPAMml.com> wrote in message
news:Ol$yrMbtDHA.424@.TK2MSFTNGP11.phx.gbl...
> If you have a fast link between your publisher/distributor/subscriber,
> replicating 130GB is still managble, especially when the amount of data
> changes is relatively small in comparison with the total database size. We
> are replicating bigger database than that with transactional replication.
> With 130GB of data, it could be a major headache to re-snapshot your
> publication, which may take a while in most environments. It can become a
> major problem when you don't have a large maintenance window. For us, the
> most common reason for requiring a new snapshot is new releases of the
> application that introduce database schema changes. Once we have reined in
> the developers and cut down the frequency of releases, we have been able
to
> support replicating 200~300GB databases.
> --
> Linchi Shea
> linchi_shea@.NOSPAMml.com
>
> "Dalibor Cvijetinovic" <dalibor@.ice.si> wrote in message
> news:OC8DqnatDHA.2340@.TK2MSFTNGP12.phx.gbl...
> > Is there anyone with some expirience in replicating such large database?
> > Maybe some good link or something like that. I would need trans
> replication
> > instructions.
> >
> > regards,
> > Dalibor
> >
> >
>

Replication Montor 2005

Is there any way to configure repl. monitor in 2005 to view all the publications that go
via a distributor in one place? (as opposed to having to link to each publisher to see the replictaion status).

we have 7 publishers going throigh one distributor and in 2000 could see them all on the distributor...now have to connect to each publisher & look on each...

Thanks

DesX

This is a design change in SQL 2005 (largely based on customer feedback), and there's no way to accomplish what you want with the given tools.

However if you want to build your own tool, you can. SQL Monitor is built around proc sp_replmonitorpublication, which has parameter @.publisher. If NULL, you get everything back for the given distributor.