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...
>

Operating System Upgrade

Hi,
We are running SQL Server 7 on NT Server.
I am responsible for an upgrade path which will migrate to Windows 2000 Server and SQL Server 2000.
The upgrade will take place in steps with the operating system done first.
Is there any documentation describing the recommended methodology for performing such an upgrade ?
Are there any known problems to watch out for ?
I know theses are general questions but I would rather be aware of best prctices or potential problems before I start.
Any help gratefully received,
Den.
Have a look at
http://www.sqlteam.com/item.asp?ItemID=9066
http://www.sqlteam.com/item.asp?ItemID=9465
Query plans will change so some SQL may go faster others slower.
Paul
"Den" <anonymous@.discussions.microsoft.com> wrote in message
news:4CB242DE-4818-4E1E-AC3C-21D962AADDDC@.microsoft.com...
> Hi,
> We are running SQL Server 7 on NT Server.
> I am responsible for an upgrade path which will migrate to Windows 2000
Server and SQL Server 2000.
> The upgrade will take place in steps with the operating system done first.
> Is there any documentation describing the recommended methodology for
performing such an upgrade ?
> Are there any known problems to watch out for ?
> I know theses are general questions but I would rather be aware of best
prctices or potential problems before I start.
> Any help gratefully received,
> Den.

Operating System Upgrade

Hi,
We are running SQL Server 7 on NT Server.
I am responsible for an upgrade path which will migrate to Windows 2000 Serv
er and SQL Server 2000.
The upgrade will take place in steps with the operating system done first.
Is there any documentation describing the recommended methodology for perfor
ming such an upgrade ?
Are there any known problems to watch out for ?
I know theses are general questions but I would rather be aware of best prct
ices or potential problems before I start.
Any help gratefully received,
Den.Have a look at
http://www.sqlteam.com/item.asp?ItemID=9066
http://www.sqlteam.com/item.asp?ItemID=9465
Query plans will change so some SQL may go faster others slower.
Paul
"Den" <anonymous@.discussions.microsoft.com> wrote in message
news:4CB242DE-4818-4E1E-AC3C-21D962AADDDC@.microsoft.com...
> Hi,
> We are running SQL Server 7 on NT Server.
> I am responsible for an upgrade path which will migrate to Windows 2000
Server and SQL Server 2000.
> The upgrade will take place in steps with the operating system done first.
> Is there any documentation describing the recommended methodology for
performing such an upgrade ?
> Are there any known problems to watch out for ?
> I know theses are general questions but I would rather be aware of best
prctices or potential problems before I start.
> Any help gratefully received,
> Den.

Operating System Upgrade

Hi
We are running SQL Server 7 on NT Server
I am responsible for an upgrade path which will migrate to Windows 2000 Server and SQL Server 2000
The upgrade will take place in steps with the operating system done first
Is there any documentation describing the recommended methodology for performing such an upgrade
Are there any known problems to watch out for
I know theses are general questions but I would rather be aware of best prctices or potential problems before I start
Any help gratefully received
Den.Have a look at
http://www.sqlteam.com/item.asp?ItemID=9066
http://www.sqlteam.com/item.asp?ItemID=9465
Query plans will change so some SQL may go faster others slower.
Paul
"Den" <anonymous@.discussions.microsoft.com> wrote in message
news:4CB242DE-4818-4E1E-AC3C-21D962AADDDC@.microsoft.com...
> Hi,
> We are running SQL Server 7 on NT Server.
> I am responsible for an upgrade path which will migrate to Windows 2000
Server and SQL Server 2000.
> The upgrade will take place in steps with the operating system done first.
> Is there any documentation describing the recommended methodology for
performing such an upgrade ?
> Are there any known problems to watch out for ?
> I know theses are general questions but I would rather be aware of best
prctices or potential problems before I start.
> Any help gratefully received,
> Den.