SQL 2005 Clustering vs Mirroring | SQL Server Performance Forums

SQL Server Performance Forum – Threads Archive

SQL 2005 Clustering vs Mirroring

I have a growing number of small databases (all < 1GB) hosted on the same server, a small number of which are business-critical. Which of the following solutions would be best in providing both high-availability & resilience while also considering cost & maintenance : (1) Mirroring all the business-critical databases to the same dedicated mirror server
(2) Sharing out the business-critical databases between 2 servers both acting as Principal & Mirror to each other.
(3) 2-node (SQL 2005 Standard edition) active-passive cluster with some kind of raiding on the shared disks I have difficulty seeing how & when clustering beats mirroring. I can only think of 2 scenarios: where either distributed transactions or high transaction rates are involved. Is this fair ? TIA Bryn
I would compare database mirroring more to logshipping than to clustering. You are replicationg your data so that it exist on two servers. That is not the case with clustering. Clustering uses one single shared high availiblity storage area. If serverA crash on a hardware level serverB in the cluster will take over. Also clustering is done on server level. The entire instance is clustered with all databases. Database mirroring is done on database level. You can choose which databases that you want to mirror. Each database requires their own configuration for this. So it is not a choice between clustering or mirroring. You could combine them both by having the entire instance clustered and then have a few databases mirrored to a seperate single server. This could be used as a reporting server (via snapshots) or to reach even higher availibilty if the one provided by clustering is not enough.
IF you more budgets to allocate then go for clustering, if not Database mirroring is best way forward. Satya SKJ
Microsoft SQL Server MVP
Contributing Editor & Forums Moderator
This posting is provided AS IS with no rights for the sake of knowledge sharing.