Re: Snapshots, Validation, Resynchronization with Merge Replicatio

Excellent answers Gopal! I would like to point out that with merge
replication the location of the distribution database is not so critical as
with transactional. You should have your distribution database on your
publisher.

You should also have no problem with all 50 subscribers running on your
publisher. If you get a lot of locking use the limit the number of
concurrent merge agents option (right click on your publication, select
properties, click the subscriptions tab, and check this option at the
bottom. Note further that you will have to add the StartQueueTimeout switch
to all of your merge agents. Give it a value of 60 to 120 s or a value which
exceeds your longest sync times.

Also it is not clear to me how many publications you have. Is it 1 or 50?

--
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html

Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com

"gopal" <gopal@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:3293427B-A813-404B-83B5-5A58B1283420@xxxxxxxxxxxxxxxx
I meant to say "copies it down to the distributor machine"

"gopal" wrote:

My first question is why are you reinitializing the database once every
week? This is not necessary unless the subscription requires to be
reinitialized.

In your topology when you run the snapshot agent, it runs on the
distributor, it makes a connection over the network to the publisher and
bcp's out the data and copies it down to the publisher machine, thats the
reason you see so much traffic,

Here is my suggestion.

1: Check you publication retention period (in the main tab of publication
properties), it is normally set to 14 days by default
What this means is that a subscriber has 14 days to sync at least
once
before it is marked as expired (which is one of the main reasons you need
to
reinitialize)

2: If you can gurantee that the subscriber can sync once every 14 days
then
you dont have to worry about reinitializing (at least for this reason)

NOw the question is how often do you have to run the snapshot. The
snapshot
need to be run only ONCE every retention period, that is once every 14
days,
if the snapshot is not run once every retention period then you can get
an
error in the agent saying the snapshot is obsolete, at which time you can
just run the snapshot agent and then start the merge agent and it will
pick
up from where it left off.

To answer your question about snapshot, running the snapshot DOES NOT
mean
that you are reinitializing, we are just generating schema and data files
along with updating some metadata. This does not result in the data being
refreshed on the subscriber.

HTH

"Hugh" wrote:

Hi,

We are running continuous merge replication on about 50 databases (sql
server 2000). Each database has only one subscriber, and that
subscriber is
located across the internet and available via a VPN tunnel.

Since the publisher server is our "live" server, I set up the
distributor on
our subscriber server. The thought was that we didn't want to have 50
replmerge.exe's running on the live server.

Originally, we set up the databases to resynchronize every weekend.
The
problem is that the snapshot agents run on the distributor, so there is
a lot
of bandwidth being used to create the snapshots. Then i read in this
newsgroup that resynchronizing of merge replications is only needed if
the
databases don't pass validation.

That said, here are my questions:

Why is there so much bandwidth going from the distributor to the
publisher
when a snapshot agent is running?

I know I can set the snapshot agents to run on a monthly schedule, but
is
that the same thing as resynchronizing on a monthly schedule?

Is there a way I can get the server to alert me if a subscription is
invalid? I have seen the message once or twice, but it always seems to
be a
connection issue (i.e. restarting the merge agent makes it go away).

Sorry for being so long-winded. Thanks for the help.

Hugh.


.

Relevant Pages

  • Re: Replicate 600G db
    ... > replicating 600 G is more complex than replicating a smaller amount. ... > making sure that this local database has the name of the database you want ... > to use on the subscriber. ... > 3) create your snapshot as always, but this time when you are creating ...
    (microsoft.public.sqlserver.replication)
  • Re: Snapshots, Validation, Resynchronization with Merge Replicatio
    ... within the published and subscribed database to store schema info and other ... publisher. ... What this means is that a subscriber has 14 days to sync at least ... NOw the question is how often do you have to run the snapshot. ...
    (microsoft.public.sqlserver.replication)
  • Re: Replicate 600G db
    ... replicating 600 G is more complex than replicating a smaller amount. ... To do this you replicate to a local database ... test on your subscriber, make the local subscriber database name test. ... Snapshot delivery section, select the use snapshot files from the following ...
    (microsoft.public.sqlserver.replication)
  • Re: SQL 2005 and Replication
    ... can you check the history of snapshot agent? ... why the snapshot agent thinks certain fulltext indexes cannot be scripted ... subscriber database is unpleasant, but the initial thinking behind not doing ...
    (microsoft.public.sqlserver.replication)
  • Re: Restore published database
    ... since the subscriber already has replicated ... > bet is to drop your subscriptions and then resubscribe and send the snapshot ... > and cobble together a consistent database. ... > Looking for a SQL Server replication book? ...
    (microsoft.public.sqlserver.replication)
Loading