push or pull, local or remote

sql2k sp3
Transactial, 1 way replication to 1 Subscriber. I want to offload as much
processing to the Subscriber as possible. I was thinking to use a Remote
Distributor (Subscriber) with Push Subscriptions would be good. (Push for
Security/ Firewall reasons.) Is this correct thinking?
TIA, ChrisR
I normally only migrate to a remote distributor when circumstances warrant.
For instance when my publisher is under load and I start to experience
locking especially in the distribution database.
There is an added point of failure if you move to a remote distributor when
you don't really need to.
Pull is best when you have large numbers of subscribers. You do lose the
central point of administration.
You might want to think about remote activation. This will offload your
agent processing to your subscriber. Its like a push subscription but with
less overhead on the publisher, and more on the subscriber.
For firewall issues you would use pull with FTP. Push doesn't work welll
over a firewall.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"ChrisR" <chris@.noemail.com> wrote in message
news:uWARPlqoEHA.1992@.TK2MSFTNGP09.phx.gbl...
> sql2k sp3
> Transactial, 1 way replication to 1 Subscriber. I want to offload as much
> processing to the Subscriber as possible. I was thinking to use a Remote
> Distributor (Subscriber) with Push Subscriptions would be good. (Push for
> Security/ Firewall reasons.) Is this correct thinking?
> TIA, ChrisR
>
|||> You might want to think about remote activation. This will offload your
> agent processing to your subscriber. Its like a push subscription but with
> less overhead on the publisher, and more on the subscriber.
I had always thought this is what a Remote Distributor would do? Is this
incorrect? Also, Push/ Pull doesnt have anything to do with where the load
is placed, right?
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:%23mFVPNvoEHA.516@.TK2MSFTNGP09.phx.gbl...
> I normally only migrate to a remote distributor when circumstances
warrant.
> For instance when my publisher is under load and I start to experience
> locking especially in the distribution database.
> There is an added point of failure if you move to a remote distributor
when[vbcol=seagreen]
> you don't really need to.
> Pull is best when you have large numbers of subscribers. You do lose the
> central point of administration.
> You might want to think about remote activation. This will offload your
> agent processing to your subscriber. Its like a push subscription but with
> less overhead on the publisher, and more on the subscriber.
> For firewall issues you would use pull with FTP. Push doesn't work welll
> over a firewall.
>
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
>
> "ChrisR" <chris@.noemail.com> wrote in message
> news:uWARPlqoEHA.1992@.TK2MSFTNGP09.phx.gbl...
much[vbcol=seagreen]
for
>
|||No, a remote distributor contains all the commands to be replicated and the
history if you are using a push subscription.
If you are using a pull subscription your remote distributor only contains
all the commands to be replicated. This history is on the subscriber. If
your remote distributor is on your subscriber, and your pull subscription
agents are there as well then the commands and history are there.
With remote activiation your agent exe will run wherever you specify -
publisher, subcsriber or distributor. So you can run a pull subscription and
have the agent run on your publisher or a push subscription and have your
agent run on your publisher.
HTH
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"ChrisR" <chris@.noemail.com> wrote in message
news:%234ZdwMxoEHA.3460@.tk2msftngp13.phx.gbl...[vbcol=seagreen]
with[vbcol=seagreen]
>
> I had always thought this is what a Remote Distributor would do? Is this
> incorrect? Also, Push/ Pull doesnt have anything to do with where the load
> is placed, right?
>
> "Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
> news:%23mFVPNvoEHA.516@.TK2MSFTNGP09.phx.gbl...
> warrant.
> when
with[vbcol=seagreen]
> much
Remote
> for
>
|||So then whats the benifit to having a remote distributor. I always thought
if processing got really heavy on the Publisher I could just use a Remote
Distributor and that would fix it. It sounds like my whole thought process
is off?
My goals are:
To offload all the processing to the Subscriber. Keep as secure as possible.
After reading all this it sounds like I should:
Use a Local Distributor. Use Remote Activation Agent. Use Pull Subscriptions
with FTP.
Is this how you would do it for my scenario?
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:uQ4G7axoEHA.2340@.TK2MSFTNGP11.phx.gbl...
> No, a remote distributor contains all the commands to be replicated and
the
> history if you are using a push subscription.
> If you are using a pull subscription your remote distributor only contains
> all the commands to be replicated. This history is on the subscriber. If
> your remote distributor is on your subscriber, and your pull subscription
> agents are there as well then the commands and history are there.
> With remote activiation your agent exe will run wherever you specify -
> publisher, subcsriber or distributor. So you can run a pull subscription
and[vbcol=seagreen]
> have the agent run on your publisher or a push subscription and have your
> agent run on your publisher.
> HTH
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
>
> "ChrisR" <chris@.noemail.com> wrote in message
> news:%234ZdwMxoEHA.3460@.tk2msftngp13.phx.gbl...
your[vbcol=seagreen]
> with
load[vbcol=seagreen]
the[vbcol=seagreen]
your[vbcol=seagreen]
> with
welll[vbcol=seagreen]
> Remote
(Push
>
|||You are completely correct. To offload some of the processing involved in
replication use a remote distributor. The only replication overhead on the
publisher will be the log reader agent which will still run on the
publisher.
However, you will then have another point of failure. Life is simpler with a
local distributor.
When you migrate to pull you get better performance as the distribution
agent runs on the subscriber. But then you have to administer your
distribution agent on your subscriber, and consequently lose your single
central point of administration.
So its a trade off, administrative simplicity vs. the performance boost.
Same with remote activation; it is slightly more complex, but there can be
performance benefits by running your push agent on your subscriber - note
that is push agent, not pull. If the server you are running your
distribution agent on (publisher, subscriber, distributor) is under load you
may get dcom timeouts when you agent starts up.
If you chose the local distributor, and pull subscriptions with FTP you are
probably getting better performance than with local and push. You would get
better performance with remote and pull, but then there is the added
administrative burden - albeit slight.
If you want to throw remote activation into the mix where is your agent
going to run? Publisher, subscriber, distributor? For performance reasons
it should be the distributor or subscriber. If its the subscriber you should
be using a simple pull.
"ChrisR" <chris@.noemail.com> wrote in message
news:OaO7L0yoEHA.1712@.tk2msftngp13.phx.gbl...
> So then whats the benifit to having a remote distributor. I always thought
> if processing got really heavy on the Publisher I could just use a Remote
> Distributor and that would fix it. It sounds like my whole thought process
> is off?
> My goals are:
> To offload all the processing to the Subscriber. Keep as secure as
> possible.
> After reading all this it sounds like I should:
> Use a Local Distributor. Use Remote Activation Agent. Use Pull
> Subscriptions
> with FTP.
> Is this how you would do it for my scenario?
>
>
> "Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
> news:uQ4G7axoEHA.2340@.TK2MSFTNGP11.phx.gbl...
> the
> and
> your
> load
> the
> your
> welll
> (Push
>
|||How would you do it? Publisher performance is more important to me than
centralized administration. It sounds like the ultimate performance boost
would be:
Remote Distributor. Pull Subscriptions. Remote Agent.
Would you agree?
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:OaeV0e1oEHA.3900@.TK2MSFTNGP10.phx.gbl...
> You are completely correct. To offload some of the processing involved in
> replication use a remote distributor. The only replication overhead on the
> publisher will be the log reader agent which will still run on the
> publisher.
> However, you will then have another point of failure. Life is simpler with
a
> local distributor.
> When you migrate to pull you get better performance as the distribution
> agent runs on the subscriber. But then you have to administer your
> distribution agent on your subscriber, and consequently lose your single
> central point of administration.
> So its a trade off, administrative simplicity vs. the performance boost.
> Same with remote activation; it is slightly more complex, but there can be
> performance benefits by running your push agent on your subscriber - note
> that is push agent, not pull. If the server you are running your
> distribution agent on (publisher, subscriber, distributor) is under load
you
> may get dcom timeouts when you agent starts up.
> If you chose the local distributor, and pull subscriptions with FTP you
are
> probably getting better performance than with local and push. You would
get
> better performance with remote and pull, but then there is the added
> administrative burden - albeit slight.
> If you want to throw remote activation into the mix where is your agent
> going to run? Publisher, subscriber, distributor? For performance reasons
> it should be the distributor or subscriber. If its the subscriber you
should[vbcol=seagreen]
> be using a simple pull.
>
> "ChrisR" <chris@.noemail.com> wrote in message
> news:OaO7L0yoEHA.1712@.tk2msftngp13.phx.gbl...
thought[vbcol=seagreen]
Remote[vbcol=seagreen]
process[vbcol=seagreen]
If[vbcol=seagreen]
subscription[vbcol=seagreen]
subscription[vbcol=seagreen]
your[vbcol=seagreen]
but[vbcol=seagreen]
lose[vbcol=seagreen]
but
>
|||I did some testing a couple of years ago with pulling from an FTP site.
Doesnt it have an issue with filling up the C: drive? Something like making
a copy of the snapshot in a temp folder?
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:OaeV0e1oEHA.3900@.TK2MSFTNGP10.phx.gbl...
> You are completely correct. To offload some of the processing involved in
> replication use a remote distributor. The only replication overhead on the
> publisher will be the log reader agent which will still run on the
> publisher.
> However, you will then have another point of failure. Life is simpler with
a
> local distributor.
> When you migrate to pull you get better performance as the distribution
> agent runs on the subscriber. But then you have to administer your
> distribution agent on your subscriber, and consequently lose your single
> central point of administration.
> So its a trade off, administrative simplicity vs. the performance boost.
> Same with remote activation; it is slightly more complex, but there can be
> performance benefits by running your push agent on your subscriber - note
> that is push agent, not pull. If the server you are running your
> distribution agent on (publisher, subscriber, distributor) is under load
you
> may get dcom timeouts when you agent starts up.
> If you chose the local distributor, and pull subscriptions with FTP you
are
> probably getting better performance than with local and push. You would
get
> better performance with remote and pull, but then there is the added
> administrative burden - albeit slight.
> If you want to throw remote activation into the mix where is your agent
> going to run? Publisher, subscriber, distributor? For performance reasons
> it should be the distributor or subscriber. If its the subscriber you
should[vbcol=seagreen]
> be using a simple pull.
>
> "ChrisR" <chris@.noemail.com> wrote in message
> news:OaO7L0yoEHA.1712@.tk2msftngp13.phx.gbl...
thought[vbcol=seagreen]
Remote[vbcol=seagreen]
process[vbcol=seagreen]
If[vbcol=seagreen]
subscription[vbcol=seagreen]
subscription[vbcol=seagreen]
your[vbcol=seagreen]
but[vbcol=seagreen]
lose[vbcol=seagreen]
but
>