Couple of Qucik Questions

First of all, would like to thank everyone on advance for any assistance you
can render!!
I've just got a couple of quick questions and looking for mostly feedback
and opinion versus cut and dry ansswers...
- I was wondering what is the TRUE impact/overhead of the various SQL Server
Replication agents? Specifically the Distribution and Log Readerr agents. A
client I'm at is concerned they will needlessly tax the server. I assured
them that the impact would be minimal at best, but a couple of people just
think it will cause the server to just get beat down.
- To replicate data between two servers that are geographically located in
different parts of the country, is VPN absolutely necessary? Would enabling
multi-protocol encryption suffice to provide adequate security?
- How much impact can one expect from transactional replication on the
network? I again told them you will have some latency between when the
transaction occurs at the publisher and when it is applied at the subscriber.
They're concerned about the NIC on the publisher getting "congested" with
replication traffic and general production activities. I suggested a second
NIC on the publisher and subscriber, both utilizing a "private" IP address
dedicated solely to replication.
- What type of backup strategy have people used for the Distribution
database? In the past, I haven't really though about backing up Distribution.
Again, thanks for any input.
answers inline.
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
"A. Robinson" <ARobinson@.discussions.microsoft.com> wrote in message
news:FFF39C2B-04E0-4549-930B-2FDDE827E983@.microsoft.com...
> First of all, would like to thank everyone on advance for any assistance
you
> can render!!
> I've just got a couple of quick questions and looking for mostly feedback
> and opinion versus cut and dry ansswers...
> - I was wondering what is the TRUE impact/overhead of the various SQL
Server
> Replication agents? Specifically the Distribution and Log Readerr agents.
A
> client I'm at is concerned they will needlessly tax the server. I assured
> them that the impact would be minimal at best, but a couple of people just
> think it will cause the server to just get beat down.
This is a function of the load on your database, and your hardware on your
publisher and subscriber. The load is minimal for transactional replication
and will probably consume less than 10% of your cpu. However it is hard to
quantify what the impact on your system will be.
> - To replicate data between two servers that are geographically located in
> different parts of the country, is VPN absolutely necessary? Would
enabling
> multi-protocol encryption suffice to provide adequate security?
For a truly secure solution you should be using a VPN. You can use
multi-protocol, however across the interenet you will be running TCP/IP.

> - How much impact can one expect from transactional replication on the
> network? I again told them you will have some latency between when the
> transaction occurs at the publisher and when it is applied at the
subscriber.
> They're concerned about the NIC on the publisher getting "congested" with
> replication traffic and general production activities. I suggested a
second
> NIC on the publisher and subscriber, both utilizing a "private" IP address
> dedicated solely to replication.
All SQL related activity is relatively chatty. I have run replication in
several large topologies and we have never had a problem with network
staturation. You can measure this as a performace monitor counter on your
nic card.

> - What type of backup strategy have people used for the Distribution
> database? In the past, I haven't really though about backing up
Distribution.
>
Backing up your distribution database must be done in tandem with the msdb,
and publication database. There is a sync with backup option which allows
you to ship these databases to a standby server to achive some measure of
point in time recovery.
> Again, thanks for any input.