January 13, 2003 at 10:20 am
I'm currently putting together the spec. for a disaster recovery site (we're a small business, so this is quite a luxury; but we're based in Midtown Manhattan, so we're strongly motivated to do it). The site will contain a server rack with two domain controllers and a MSCS cluster running SQL Server 2000. At the moment, it's network connection will be via a 56k modem router (it's in rural New Jersey).
So, my question is: what are people's thoughts about the various strategies of replicating our production database to the other site?
As far as I know there are the following options:
1, The "dumb" method. Visit periodically (once a week) and restore from an "off-site" backup tape. This will keep the server up-to-date with a big latency (but I plan to grab a tape as I run out of the building, in extremis).
2, Use SQL's transactional replication over the link. My problem with this is, as I understand it, I can't replicate identity columns.
3, Use SQL's log shipping system. I believe This gives me a perfect, off-line, copy with small latency.
4, Use a physical replication product, such as VERITAS's "Storage Exec". Again, I belive this also gives a perfect, off-line, copy with latency.
Best wishes,
Graham
January 13, 2003 at 10:41 am
I Would recomend transactional replication. You can replicate identity values but to prevent errors or discontinued values, you must set the identity column like not for replication. Check BOL for more info.
Maybe you should think in advanced and prevent that the db will become some day very big, so replication for me is the best choice.
Al least that what we use in here. We are replicating the 74 servers in all the country.
January 13, 2003 at 1:15 pm
I disagree, If your looking for a dsiaster recovery model, then Log Shipping is is no brainer. Replication is an additional overhead on the Production server.
see discussion:
John Zacharkan
John Zacharkan
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply