October 24, 2006 at 8:45 am
We currently operate a SQL 2000 cluster with log shipping to a out-of-cluster standby server enabled . The database size is approx 400g. The log shipping occurs every 15 mins. Our customer would like that latency reduced. The system processes 2g-4g of transactional data daily, primarily from a series of data feeds from other systems.
We will be upgrading to SQL2005 shortly which introduces (with SP1) data mirroring.
Questions:
1. Is Mirroring reasonable/feasible/desriable with database and transaction volumes of this size
2. Partitioning the database is relatively easy, in our case. With partitioning, the much smaller / much more important transactions can be separated from the much larger / much less important transactions. As such, we could mirror the 'important' one and continue to log ship the 'less important' ones. Is that reasonable?
3. We have steered clear of replication. How is mirroring any better or worse?
4. Can you mirror to more than one mirror server or is replication/log shipping to more than one destination the only answer. This question relates to the need to refresh our QA environment periodically from production. A database restore from our ATL takes 6-8 hrs.
October 24, 2006 at 10:22 am
The following two white papers about database mirroing may be helpful for you to make the decision.
Database Mirroring Best Practices and Performance Considerations:
http://www.microsoft.com/technet/prodtechnol/sql/2005/technologies/dbm_best_pract.mspx
Database Mirroring in SQL Server 2005:
http://www.microsoft.com/technet/prodtechnol/sql/2005/dbmirror.mspx
Viewing 2 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply