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
>

Push data to remote server

Can I run bulk insert or bcp on a local server to insert data into a
remote server?
What are the other options to Push data to a remote server outside a
firewall?
Bulk insert is only for insert purposes -- you would need to run this on the
remote server. BCP does in/out. In theory you could run this from your
machine (with a file on your PC) and specify the remote server as the
destination.
You might be able to use replication or custom built insert statements that
utilize linked servers for connectivity.
Keith Kratochvil
"Rishi" <mrrishisharma@.gmail.com> wrote in message
news:1159992378.416088.171020@.b28g2000cwb.googlegr oups.com...
> Can I run bulk insert or bcp on a local server to insert data into a
> remote server?
> What are the other options to Push data to a remote server outside a
> firewall?
>

Push data to remote server

Can I run bulk insert or bcp on a local server to insert data into a
remote server?
What are the other options to Push data to a remote server outside a
firewall?Bulk insert is only for insert purposes -- you would need to run this on the
remote server. BCP does in/out. In theory you could run this from your
machine (with a file on your PC) and specify the remote server as the
destination.
You might be able to use replication or custom built insert statements that
utilize linked servers for connectivity.
Keith Kratochvil
"Rishi" <mrrishisharma@.gmail.com> wrote in message
news:1159992378.416088.171020@.b28g2000cwb.googlegroups.com...
> Can I run bulk insert or bcp on a local server to insert data into a
> remote server?
> What are the other options to Push data to a remote server outside a
> firewall?
>

Push data to remote server

Can I run bulk insert or bcp on a local server to insert data into a
remote server?
What are the other options to Push data to a remote server outside a
firewall?Bulk insert is only for insert purposes -- you would need to run this on the
remote server. BCP does in/out. In theory you could run this from your
machine (with a file on your PC) and specify the remote server as the
destination.
You might be able to use replication or custom built insert statements that
utilize linked servers for connectivity.
Keith Kratochvil
"Rishi" <mrrishisharma@.gmail.com> wrote in message
news:1159992378.416088.171020@.b28g2000cwb.googlegroups.com...
> Can I run bulk insert or bcp on a local server to insert data into a
> remote server?
> What are the other options to Push data to a remote server outside a
> firewall?
>

publishing sql db

web site made in web dev

db all ok locally

got server at local ip......

need to upload script files to server...

got microsoft publishing wizard all working and database all scripted out.

server consul looks like horrible unix outfit....virtuozzo

question is now what?

ip says use enterprise manager to publish to server.....is that the old

version of management studio express, which i have

You can always download the new version of SQl Management Studio for free. For publishing you need to register it with the DNS and then put either the IP or the servername in the connection string.

|||

I have got ssmse already

can you expand a little on this "For publishing you need to register it with the DNS "

|||

If you are using an IP address or a server name thatshould be resolved through DNS or over the Internet, you'll want to make sure that TCP/IP is enabled. Go to Start / Programs / Microsoft SQL Server, open the Client Network Utility, and on the General tab, make sure TCP/IP is at the top of the list on the right hand side.

If you are trying to connect to a named instance, you can use the following format:

Data Source = <server/ip>\<instancename>;

If you are running SQL Server or MSDE on the same machine as your ASP pages, you are probably tempted to use the hostname "localhost." This doesn't always work, due to different configuration issues, so try (local), 127.0.0.1, the actual host name, or simply a period (".").

|||

yes.. why dont I run both the asp pages and sql server on the

server together...sounds much cleaner. great idea

I,ll give it a try.

Thanks so much for your help naturehermit

|||

yes.. why dont I run both the asp pages and sql server on the

server together...sounds much cleaner. great idea

I,ll give it a try.

Thanks so much for your help naturehermit

|||

Thanks and all the best

(If you have got a large website, running sql server and code on same machine will create performance issues)

|||

oooh

right ..maybe not then...i think i can see where

you are coming from.

|||

However I have run many test with 100 or so cuncurrent users where SQL Enterprise and Asp.net are both sitting on a win2k3 Enterprise Machine with 4 Gig RAM, havent found any issue at all.

|||

So if I was running a server with seperate asp.net pages ...no problem.

This is all new to me and trying to get sorted what road

to go down is the hardest bit.

Got any help on publishing scripts to a server.

I don,t know if I should be uploading sql server 2005 to the server or just

the .mdf

|||

Hi there,

I shall try to explain this,

With publishing scripts if you mean the code, then in visual studio there is a publish website option, from Build. If you mean something different please specify.

sql server 2005 is a server itself that runs on top of windows 2003 and hence if you havent given your sql server a different name it should be the name of your 2003, If you have DNS enabled and have got a domain, it should already be configured for you.

If you want somebody to host the db for you, then you can supply them the .mdf files so that they can re-create the table in their sql host for you, however in that case you will need to modify your connectionstring to theirs.

so for e.g. curently say you are using server =192.168.1.1 and they may have a server with ip 2.3.2.1 or say sqlserver(if mapped to dns)

then you will simply use

server =sqlserver or server =2.3.2.1 in your connection string.

Hope that helps

|||

If you want somebody to host the db for you, then you can supply them the .mdf files so that they can re-create the table in their sql host for you, however in that case you will need to modify your connectionstring to theirs.

Is that all.

You see after reading this article I decided that I should have to build scripts..DDL to upload to a "server"

http://weblogs.asp.net/scottgu/archive/2006/12/22/recipe-deploying-a-sql-database-to-a-remote-hosting-environment-part-1.aspx

rather than just upload .mdf to my host......I think I have over cooked this some what

|||

Well that article is to make life easier for people and for people with stored procedures and other stuff. Generally .mdf is enough to create the database. But as pointed out in that article most providers do not know what they are doing and hence it creates a lot of problems to iron out these installation issues. Do not upload but supply them .mdf files and ask them to create the db for you, and they will give you the server name to modify in your connection string.

|||

naturehermit you are truly a star of mine.

thanks for all your help today...I owe you.

And I hope this post may help others who get to this greyer area

regards Richard

|||

Hey Richard,

Thanks for your compliments but I am just an ordinary folk. Please feel free to ask if you get stuck. Also please mark all posts that helped you.

Regards