Wednesday, March 7, 2012

operating systems

Hello,
We aim to use the current server (w2k,sql2000ent, 2x1ghz, 1gb ram, mirrored
pair & raid 5 for data) as a failover machine and upgrade to a new server
for production.
The 2 machines will be in different countries. Users in both countries will
use the production server. If the connection between the countries is
broken, the remote users will use the failover.
We propose to have merge replication between the 2 machines (mainly one
way).
How can we estimate the physical physical size of data that would need to be
transferred to the failover m/c for a given time period?
Presumably it would make sense to use w2003 on both machines?
Do the operating systems on 2 merge replicating machines have to be the
same?
Any advice would be appreciated.
Thanks SOC.
I would not use merge for this - I would use bi-directional transactional
replication. This is ideal because your data is highly partitioned.
Transactions occur on only one side at a time.
Transactional replication is in general much faster than merge replication.
Transactional replication is designed for server to server replication -
whereas merge is designed for clients who often go offline. Merge
replication adds a GUID column to each table you are replicating.
Transactional requires a primary key on each table.
Merge replication can be more difficult to trouble shoot than transactional.
Merge also requires (in general) more processing than transactional.
This is not to say of course that merge is always less performant than
transactional or slower than transactional. If you have a solution where
there are heavy updates, the servers are not connected for significant
lengths of time, and transactions originate on one server - merge is faster
and performs better. Consider a stock market application where 1) the
majority of the transactions are updates 2) the servers connect once a day
3) the transactions all occur on the publisher - in this case merge performs
way better than tranny.
Hilary Cotter
Looking for a SQL Server replication book?
Now available for purchase at:
http://www.nwsu.com/0974973602.html
"soc" <zxc0@.yahoo.com> wrote in message
news:eWfg9uQ4EHA.2404@.TK2MSFTNGP14.phx.gbl...
> Hello,
> We aim to use the current server (w2k,sql2000ent, 2x1ghz, 1gb ram,
> mirrored pair & raid 5 for data) as a failover machine and upgrade to a
> new server for production.
> The 2 machines will be in different countries. Users in both countries
> will use the production server. If the connection between the countries is
> broken, the remote users will use the failover.
> We propose to have merge replication between the 2 machines (mainly one
> way).
> How can we estimate the physical physical size of data that would need to
> be transferred to the failover m/c for a given time period?
> Presumably it would make sense to use w2003 on both machines?
> Do the operating systems on 2 merge replicating machines have to be the
> same?
> Any advice would be appreciated.
> Thanks SOC.
>
|||Thanks Hilary,
I will look into bi-directional tranasactional replication.
-Presumably it would make sense to use w2003 on both machines?
-Do the operating systems on 2 replicating machines have to be the
same?
Any advice would be appreciated.
Thanks SOC.
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:O8z42MR4EHA.4092@.TK2MSFTNGP14.phx.gbl...
>I would not use merge for this - I would use bi-directional transactional
>replication. This is ideal because your data is highly partitioned.
>Transactions occur on only one side at a time.
> Transactional replication is in general much faster than merge
> replication. Transactional replication is designed for server to server
> replication - whereas merge is designed for clients who often go offline.
> Merge replication adds a GUID column to each table you are replicating.
> Transactional requires a primary key on each table.
> Merge replication can be more difficult to trouble shoot than
> transactional. Merge also requires (in general) more processing than
> transactional.
> This is not to say of course that merge is always less performant than
> transactional or slower than transactional. If you have a solution where
> there are heavy updates, the servers are not connected for significant
> lengths of time, and transactions originate on one server - merge is
> faster and performs better. Consider a stock market application where 1)
> the majority of the transactions are updates 2) the servers connect once a
> day 3) the transactions all occur on the publisher - in this case merge
> performs way better than tranny.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> Now available for purchase at:
> http://www.nwsu.com/0974973602.html
> "soc" <zxc0@.yahoo.com> wrote in message
> news:eWfg9uQ4EHA.2404@.TK2MSFTNGP14.phx.gbl...
>
|||you do not have to have the same operating system. It is adviseable to use
NT server operating systems, ie NT 4., Win2k, and Win2003.
I think you can get away with using NT workstation, or XP professional but
there can be a connection limit you can bang into.
Hilary Cotter
Looking for a SQL Server replication book?
Now available for purchase at:
http://www.nwsu.com/0974973602.html
"soc" <zxc0@.yahoo.com> wrote in message
news:egaFkBT4EHA.2540@.TK2MSFTNGP09.phx.gbl...
> Thanks Hilary,
> I will look into bi-directional tranasactional replication.
> -Presumably it would make sense to use w2003 on both machines?
> -Do the operating systems on 2 replicating machines have to be the
> same?
> Any advice would be appreciated.
> Thanks SOC.
>
> "Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
> news:O8z42MR4EHA.4092@.TK2MSFTNGP14.phx.gbl...
>

No comments:

Post a Comment