Sql Server Clustering Concepts: Inception Of Melbourne Sql Server Group

You are here: Home / Enterprise Edition / Sql Server Clustering Concepts: Inception Of Melbourne Sql Server Group

Posted by Andy on Jun 08, 2010 | 1 Comment

Sql Server Clustering Concepts: Inception Of Melbourne Sql Server Group

In Computer Science Clustering is a concept where a set of components provide scalable data at low overheads. Clustering enables high-end applications to flow stored and manipulated information on a network.

This particular concept conflicts with Database Mirroring as apparently this two provide the same facility of partner failover to the database. But there are some differences as the SQL Server Melbourne group has revealed that in a meeting.

After going through the presentation I have intercepted some points which are noted below:

Mirroring provides automatic failover and failback between servers, and doesn’t require SAN / NAS hardware from Microsoft’s approved hardware list. Each Mirror server can use entirely separate hardware. Where as Clusters use shared hard disks (SAN / NAS) with the servers, creating a single point of failure. Clustering in 2000 required Enterprise edition of SQL server and windows advanced server. No word from MS yet about what licensing will be required for Mirroring or clustering in 2005.
I don’t think you would use Mirroring and Clustering together, unless you had two clusters being mirrored. Otherwise you would have a single point of failure.
You could snapshot the Server ‘B’ (the non active server) and report from the snapshot.
Replication allows a greater distance between servers, ideal if DBA wants to have highly responsive servers in local / international offices. There is a lag of at least a minute between the servers syncing themselves, and there are some database design considerations. But the benefits of a well organized replicated database means that each server can operate independently and doesn’t rely on the other server being constantly available.

Here are some write ups on Log Shipping:

Minimal impact on the production server
No changes to the database are required
Transactional consistency
Supports delayed load of transaction logs
Not all SQL Server objects are automatically copied
Users must exit for next log to be applied

Sql Server melbourne group has accepted this particular Log Shipping technologies with their meeting.

Abhijit Dey is a Software Professional working in India for last 4 years and his expertise is on .Net technologies and Sql Server. He is also pursuing PhD on Distributed Database.