latency on transaction repl problem again

Well it only took a few days before the latency bounced back up again. I
don't understand why this is happening. There is another server that has the
same subscription that is operating over a WAN, and it doesn't have the same
problems. Neither do any of the other subscriptions.
Please help if can. Will post the original email below.
Thx,
Kristy[vbcol=seagreen]
I am using transactional replication for a 100GB database that has 2 nosync
subscribers. The pull subscriptions are segmented into like table groups.
They all use a custom profile for the distribution agents that I tweaked
over time to minimize latecy. In the last month I have noticed that 1 of the
subscriptions always has a higher latency in EM then the others. After
looking into several things, we also found out that there was a
hardware/firmware problem with Dell, so we ahve applied that patch and it
has fixed a number of other problems in the DB, but still not the latency
problem on this one subscription. Some of the other subscriptions have much
bigger tables and data changes, so I am at a loss of why this one is causing
me so many problems. I frequently will have to apply a snapshot of this
subscription because it will get so far behind, and then will slwly build
back up again until another snapshot is required.
Can anyone help?
Here are some of the current configs of the custom profile:
BcpBatchsize: 100000
CommitBatchSize: 1000
CommitBatchThreshold: 5000
PollingInterval:1
Thanks,
Kristy
Kristy. Sorry but I write to you for your help, probably not as you expected.
You mentioned in you have 2 nosync subscribers and that is where I am having
problems. Questions for you are: 1) do you create subscription prior to
restoring or another way around? 2) If you create suscription first, what is
the database for the subscription? This is where I am having problems. I use
the instructions of 'How to manually synchronize replication subscriptions by
using backup or restore', article id 320499. Thanks for your helps and sorry
I am not able to help you out.
"Kristy" wrote:

> Well it only took a few days before the latency bounced back up again. I
> don't understand why this is happening. There is another server that has the
> same subscription that is operating over a WAN, and it doesn't have the same
> problems. Neither do any of the other subscriptions.
> Please help if can. Will post the original email below.
> Thx,
> Kristy
> I am using transactional replication for a 100GB database that has 2 nosync
> subscribers. The pull subscriptions are segmented into like table groups.
> They all use a custom profile for the distribution agents that I tweaked
> over time to minimize latecy. In the last month I have noticed that 1 of the
> subscriptions always has a higher latency in EM then the others. After
> looking into several things, we also found out that there was a
> hardware/firmware problem with Dell, so we ahve applied that patch and it
> has fixed a number of other problems in the DB, but still not the latency
> problem on this one subscription. Some of the other subscriptions have much
> bigger tables and data changes, so I am at a loss of why this one is causing
> me so many problems. I frequently will have to apply a snapshot of this
> subscription because it will get so far behind, and then will slwly build
> back up again until another snapshot is required.
> Can anyone help?
> Here are some of the current configs of the custom profile:
> BcpBatchsize: 100000
> CommitBatchSize: 1000
> CommitBatchThreshold: 5000
> PollingInterval:1
> Thanks,
> Kristy
>
>
>
|||Check the history/errors tables for this subscription to try to find out
what is wrong. The tables are in the distribution database and are
msrepl_errors, and msdistribution_history.
Hilary Cotter
Director of Text Mining and Database Strategy
RelevantNOISE.Com - Dedicated to mining blogs for business intelligence.
This posting is my own and doesn't necessarily represent RelevantNoise's
positions, strategies or opinions.
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
"Kristy" <pleasereplyby@.posting.com> wrote in message
news:OFVpZbRTGHA.5104@.TK2MSFTNGP10.phx.gbl...
> Well it only took a few days before the latency bounced back up again. I
> don't understand why this is happening. There is another server that has
> the
> same subscription that is operating over a WAN, and it doesn't have the
> same
> problems. Neither do any of the other subscriptions.
> Please help if can. Will post the original email below.
> Thx,
> Kristy
> I am using transactional replication for a 100GB database that has 2
> nosync
> subscribers. The pull subscriptions are segmented into like table groups.
> They all use a custom profile for the distribution agents that I tweaked
> over time to minimize latecy. In the last month I have noticed that 1 of
> the
> subscriptions always has a higher latency in EM then the others. After
> looking into several things, we also found out that there was a
> hardware/firmware problem with Dell, so we ahve applied that patch and it
> has fixed a number of other problems in the DB, but still not the latency
> problem on this one subscription. Some of the other subscriptions have
> much
> bigger tables and data changes, so I am at a loss of why this one is
> causing
> me so many problems. I frequently will have to apply a snapshot of this
> subscription because it will get so far behind, and then will slwly build
> back up again until another snapshot is required.
> Can anyone help?
> Here are some of the current configs of the custom profile:
> BcpBatchsize: 100000
> CommitBatchSize: 1000
> CommitBatchThreshold: 5000
> PollingInterval:1
> Thanks,
> Kristy
>
>
|||Kathy,
I have to actually create the pull subscriptions twice on the subscriber.
Once for the publisher to see it initially and then when I restore the
database it removes the pull subscriptions from the subscription DB (because
you are overwriting the tables with the new DB that contains the info.) I
then do the pull subscription again on the subscriber and everything works
fine. Publisher does not seem to get confused or think it is a new
subscription.
HTH
Kristy
"Kathy" <Kathy@.discussions.microsoft.com> wrote in message
news:59B2F52B-7ED1-4111-BA18-02C0DA61722E@.microsoft.com...
> Kristy. Sorry but I write to you for your help, probably not as you
expected.
> You mentioned in you have 2 nosync subscribers and that is where I am
having
> problems. Questions for you are: 1) do you create subscription prior to
> restoring or another way around? 2) If you create suscription first, what
is
> the database for the subscription? This is where I am having problems. I
use
> the instructions of 'How to manually synchronize replication subscriptions
by
> using backup or restore', article id 320499. Thanks for your helps and
sorry[vbcol=seagreen]
> I am not able to help you out.
> "Kristy" wrote:
the[vbcol=seagreen]
same[vbcol=seagreen]
nosync[vbcol=seagreen]
groups.[vbcol=seagreen]
the[vbcol=seagreen]
it[vbcol=seagreen]
latency[vbcol=seagreen]
much[vbcol=seagreen]
causing[vbcol=seagreen]
build[vbcol=seagreen]