2PC and Replication 2005

We are having a symmetry issue between rep over a LAN and over the WAN. I want to know the roll of the MSDTC and possible two-phase commits (2PC) that may be occurring with certain subscription types. It didn't seem the replication stream scales well over the WAN and 2PC are not the thing to do over longer distances due to the excessive amount of handshaking needed in 2PCs (reflectivity issues).

If 2PCs and the MSDTC are used, are certain setups or types of replication in SQL 2005 available that would be more efficient over a long distance WAN? Can 2PCs be avoided?

The setup that was built with the issues is not a typically built replication topology (by my book). By my own rule, I never place the distributor on the publisher, ever. Apparently, when setup this way, I didn't have any issue replicating over a similar WAN. Does the distributor work differently when running on a dedicated server?

What's the best replication topology when attempting to replicate over a long distance WAN?

Thanks.

Transactional replication works well over a wan. If you are replicating DML which modifies large numbers of rows consider replicating the execution of stored procedures.

Immediate updating does use MSDTC when transactions originate on the subscriber. Other replication types do not.

2PC and Replication 2005

We are having a symmetry issue between rep over a LAN and over the WAN. I want to know the roll of the MSDTC and possible two-phase commits (2PC) that may be occurring with certain subscription types. It didn't seem the replication stream scales well over the WAN and 2PC are not the thing to do over longer distances due to the excessive amount of handshaking needed in 2PCs (reflectivity issues).

If 2PCs and the MSDTC are used, are certain setups or types of replication in SQL 2005 available that would be more efficient over a long distance WAN? Can 2PCs be avoided?

The setup that was built with the issues is not a typically built replication topology (by my book). By my own rule, I never place the distributor on the publisher, ever. Apparently, when setup this way, I didn't have any issue replicating over a similar WAN. Does the distributor work differently when running on a dedicated server?

What's the best replication topology when attempting to replicate over a long distance WAN?

Thanks.

Transactional replication works well over a wan. If you are replicating DML which modifies large numbers of rows consider replicating the execution of stored procedures.

Immediate updating does use MSDTC when transactions originate on the subscriber. Other replication types do not.

2005 or 2000?

We are about to purchase a new Server which will act as a SQL Server and
expand access to our existing MSDE database. Currently 5 users on a Lan but
we will be going to approx. 25 users (15 of which will be using Terminal
Server). I appreciate this is about the cut off point for the Licensing
options (between Processor or Server Licensing). My worry is that I go for
the single processor option (and by extension a single processor server) and
it isn't able to cope. Anyone got any experience of similar scenarios. I
don't really want to go to a Dual Processor option due to cost. Also, I take
it it makes sense to pay the extra for a 2005 license (for future benefits)
even though existing database is only compatible with 2000 currently.25 users is tiny, how big is the Db and how many transactions...will it get
bigger, new users ?.....not knowing all the details, i would bet a one proc
would do ya on sql 2000
"AK" <AK@.discussions.microsoft.com> wrote in message
news:9EC567CA-2EC2-448B-803E-04A11C256944@.microsoft.com...
> We are about to purchase a new Server which will act as a SQL Server and
> expand access to our existing MSDE database. Currently 5 users on a Lan
> but
> we will be going to approx. 25 users (15 of which will be using Terminal
> Server). I appreciate this is about the cut off point for the Licensing
> options (between Processor or Server Licensing). My worry is that I go for
> the single processor option (and by extension a single processor server)
> and
> it isn't able to cope. Anyone got any experience of similar scenarios. I
> don't really want to go to a Dual Processor option due to cost. Also, I
> take
> it it makes sense to pay the extra for a 2005 license (for future
> benefits)
> even though existing database is only compatible with 2000 currently.|||Db is currently about .5 Gb, not a huge number of transactions. Majority of
Users will be accessing for reporting purposes. Sounds like 1 proc should be
ok then
"David J. Cartwright" wrote:

> 25 users is tiny, how big is the Db and how many transactions...will it g
et
> bigger, new users ?.....not knowing all the details, i would bet a one pr
oc
> would do ya on sql 2000
> "AK" <AK@.discussions.microsoft.com> wrote in message
> news:9EC567CA-2EC2-448B-803E-04A11C256944@.microsoft.com...
>
>

2005 or 2000?

We are about to purchase a new Server which will act as a SQL Server and
expand access to our existing MSDE database. Currently 5 users on a Lan but
we will be going to approx. 25 users (15 of which will be using Terminal
Server). I appreciate this is about the cut off point for the Licensing
options (between Processor or Server Licensing). My worry is that I go for
the single processor option (and by extension a single processor server) and
it isn't able to cope. Anyone got any experience of similar scenarios. I
don't really want to go to a Dual Processor option due to cost. Also, I take
it it makes sense to pay the extra for a 2005 license (for future benefits)
even though existing database is only compatible with 2000 currently.
25 users is tiny, how big is the Db and how many transactions...will it get
bigger, new users ?.....not knowing all the details, i would bet a one proc
would do ya on sql 2000
"AK" <AK@.discussions.microsoft.com> wrote in message
news:9EC567CA-2EC2-448B-803E-04A11C256944@.microsoft.com...
> We are about to purchase a new Server which will act as a SQL Server and
> expand access to our existing MSDE database. Currently 5 users on a Lan
> but
> we will be going to approx. 25 users (15 of which will be using Terminal
> Server). I appreciate this is about the cut off point for the Licensing
> options (between Processor or Server Licensing). My worry is that I go for
> the single processor option (and by extension a single processor server)
> and
> it isn't able to cope. Anyone got any experience of similar scenarios. I
> don't really want to go to a Dual Processor option due to cost. Also, I
> take
> it it makes sense to pay the extra for a 2005 license (for future
> benefits)
> even though existing database is only compatible with 2000 currently.
|||Db is currently about .5 Gb, not a huge number of transactions. Majority of
Users will be accessing for reporting purposes. Sounds like 1 proc should be
ok then
"David J. Cartwright" wrote:

> 25 users is tiny, how big is the Db and how many transactions...will it get
> bigger, new users ?.....not knowing all the details, i would bet a one proc
> would do ya on sql 2000
> "AK" <AK@.discussions.microsoft.com> wrote in message
> news:9EC567CA-2EC2-448B-803E-04A11C256944@.microsoft.com...
>
>

2005 or 2000?

We are about to purchase a new Server which will act as a SQL Server and
expand access to our existing MSDE database. Currently 5 users on a Lan but
we will be going to approx. 25 users (15 of which will be using Terminal
Server). I appreciate this is about the cut off point for the Licensing
options (between Processor or Server Licensing). My worry is that I go for
the single processor option (and by extension a single processor server) and
it isn't able to cope. Anyone got any experience of similar scenarios. I
don't really want to go to a Dual Processor option due to cost. Also, I take
it it makes sense to pay the extra for a 2005 license (for future benefits)
even though existing database is only compatible with 2000 currently.25 users is tiny, how big is the Db and how many transactions...will it get
bigger, new users ?.....not knowing all the details, i would bet a one proc
would do ya on sql 2000
"AK" <AK@.discussions.microsoft.com> wrote in message
news:9EC567CA-2EC2-448B-803E-04A11C256944@.microsoft.com...
> We are about to purchase a new Server which will act as a SQL Server and
> expand access to our existing MSDE database. Currently 5 users on a Lan
> but
> we will be going to approx. 25 users (15 of which will be using Terminal
> Server). I appreciate this is about the cut off point for the Licensing
> options (between Processor or Server Licensing). My worry is that I go for
> the single processor option (and by extension a single processor server)
> and
> it isn't able to cope. Anyone got any experience of similar scenarios. I
> don't really want to go to a Dual Processor option due to cost. Also, I
> take
> it it makes sense to pay the extra for a 2005 license (for future
> benefits)
> even though existing database is only compatible with 2000 currently.|||Db is currently about .5 Gb, not a huge number of transactions. Majority of
Users will be accessing for reporting purposes. Sounds like 1 proc should be
ok then
"David J. Cartwright" wrote:
> 25 users is tiny, how big is the Db and how many transactions...will it get
> bigger, new users ?.....not knowing all the details, i would bet a one proc
> would do ya on sql 2000
> "AK" <AK@.discussions.microsoft.com> wrote in message
> news:9EC567CA-2EC2-448B-803E-04A11C256944@.microsoft.com...
> > We are about to purchase a new Server which will act as a SQL Server and
> > expand access to our existing MSDE database. Currently 5 users on a Lan
> > but
> > we will be going to approx. 25 users (15 of which will be using Terminal
> > Server). I appreciate this is about the cut off point for the Licensing
> > options (between Processor or Server Licensing). My worry is that I go for
> > the single processor option (and by extension a single processor server)
> > and
> > it isn't able to cope. Anyone got any experience of similar scenarios. I
> > don't really want to go to a Dual Processor option due to cost. Also, I
> > take
> > it it makes sense to pay the extra for a 2005 license (for future
> > benefits)
> > even though existing database is only compatible with 2000 currently.
>
>