|
|
You're in the
sql server replication
group:operating systems
sql server replication:
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 [quoted text, click to view] "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. > >
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.
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 [quoted text, click to view] "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... >>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. [quoted text, click to view] "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... >> 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. >> >> > >
Don't see what you're looking for? Try a search.
|
April 2003
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
| home · blog · groups | Questions? Comments? Contact the dn |