Saturday, February 25, 2012

queued updatable subscribers

I'm using transactional replication with queued updatable
subscribers.
My reason for doing this is that I want to be able to
update the subscribers in case they lose network
connection to the publisher.
Everything worked fine in the begining but as our product
has evolved the publication has grown to more than 520
articles. My problem is that the time it takes to update
a table at the subscriber has increased and I see a
relationship with the nuber of articles in the
publication.
Does anyone know if Microsoft has addressed this problem
in SQL server 2005 or is there a different way to solve
the problem. Logshipping doesn't help me and database
mirroring only handles one subscriber as far as I can
tell.
Peter,
queued updating subscribers is optimised only for few updates at the
subscriber. Where this is not the case you might want to consider using
merge replication which will also allow you the autonomy you require. I
agree that log shipping is not suitable as the subscriber database is
recovered in NORECOVERY or STANDBY mode which won't allow users to change
the data.
Regards,
Paul Ibison
(ps when you talk about database mirroring presumably you are referring to a
third party tool, or are you currently using SQL Server 2005 beta 1.)
|||Thanks for the answer Paul!
I made some tests with merge replication and it works better in the
failover scenario but the overhead I get in the normal scenario is maybe
to big. I'm going to study merge replication a bit more to see if there
is anything I can do to speed it up when I make updates at the
publisher.
(Yes database mirroring is the new feature in SQL 2005)
*** Sent via Developersdex http://www.codecomments.com ***
Don't just participate in USENET...get rewarded for it!
|||Peter,
these links may help you to optimize the merge agent for your needs:
Replication merge gaent parameters (esp pollinginterval)
http://msdn.microsoft.com/library/de...lmerg_4y2h.asp
Merge Replication: Performance Tuning and Optimization
http://www.microsoft.com/technet/pro.../mergperf.mspx
HTH,
Paul Ibison

No comments:

Post a Comment