With every release of SQL Server, Microsoft has emphasized one area of technology. For SQL Server 7.0, that area was scalability; for SQL Server 2000, it was security. For SQL Server 2005, the emphasis is system and database availability. Microsoft has not only added one completely new technology, database mirroring, to achieve higher availability, but also substantially improved existing availability features.

SQL Server 2005 provides four high-availability technologies: failover clustering and database mirroring, both with supported automatic failover; and log shipping and replication, with either manual or custom-coded failover. Because Microsoft supports automatic failover for both failover clustering and database mirroring, they're clearly the technologies of choice to maximize uptime. If you don't need automatic failover or you're willing to custom-code your automatic failover processes, log shipping and replication might provide the availability you need.

These four availability solutions address a system and database failure. However, Microsoft has also addressed another aspect of availability in SQL Server 2005: the availability of data in a highly concurrent system. If you can't access the data you need because another process has it locked, you have an availability problem. Microsoft has added several new features to support data availability in highly concurrent environments, including snapshot isolation and online index building.

In addition, some enhancements to the database restore process can make your data available more quickly. Although you probably think first about restoring a database as part of recovery from a failure, keep in mind that you might perform a database restore for other reasons, such as when you move to new hardware or create a test system with data from an earlier backup. Two new features that make your data available more quickly during a restore are online recovery and fast recovery (see "Faster Restoring" in this article). Let's look at what you can expect from these new and improved high-availability features.

Failover Clustering
Of SQL Server's high-availability solutions, failover clustering remains the technological leader. A failover cluster consists of a set of redundant servers (called nodes) that share an external disk system. Clustering requires special Windows software. In addition, to be eligible for Microsoft support, Microsoft must certify your entire cluster configuration, and it must be listed in the Windows Catalog in the cluster solution category. During a cluster failover, a virtual SQL Server instance moves from one node to another.

As a result, a cluster failover appears to external applications as if the virtual SQL Server instance is briefly unavailable (usually for less than a minute), then available again. The instance seemingly just stops and restarts. Behind the scenes, an orderly process takes place quickly. One SQL Server instance located on one physical server becomes unavailable. Windows closes the database data files that the instance had open on a commonly shared disk space. Then, another SQL Server instance starts on another physical server, opens the same data files, and takes over the virtual server name and virtual IP address of the failed instance.

SERVER VS. DATA REDUNDANCY
The fact that SQL Server's cluster failover works at the SQL Server instance level is its essential advantage. Because an entire instance can fail over from one to another node of a cluster, all server settings remain the same. All data files are the same, including system databases; therefore, all logins, permissions, SQL Server Agent jobs, server configurations, and more are preserved. Failover clustering is the only SQL Server high-availability technology that provides such server redundancy.

Unfortunately for failover clustering, server redundancy doesn't imply data-file redundancy. Because failover clustering makes use of shared disks among the nodes of the cluster, even though those disks might be located in redundant arrays and on a SAN, that common drive system is a potential point of failure. Some SAN vendors provide methods for replicating SAN data over relatively long distances, but the technology can be costly and complex to administer.

SQL Server 2005 extends the range of clustering and uses the full capabilities of Windows clustering.The number of nodes that SQL Server 2005 Enterprise Edition supports is now limited only by the version of Windows you use. Perhaps the biggest news in SQL Server 2005 clustering is that the Standard Edition now supports a twonode cluster, whereas in earlier versions of SQL Server, only the Enterprise Edition supported clustering.

   Prev. page   [1] 2 3 4     next page



You must log on before posting a comment.

If you don't have a username & password, please register now.