MOSS Database Server Options

Backend Servers / SQL Server


Principally, MOSS and Windows SharePoint Services v3 use a SQL Server database to store all of its documents, web pages, and metadata. Another database is used to store the configuration detail of the portal. In fact, almost everything pertaining to SharePoint is stored in a SQL Server. This highlights the importance of the availability of the database and if this is not available your Portal is not available.
A high availability solution masks the effects of a hardware or software failure and maintains the availability of applications so that the perceived downtime for users is minimized. If there is a need for uninterrupted operation of an organization's SharePoint databases, it is recommended that a understanding of the high availability alternatives offered in SQL Server. With regard to SharePoint, SQL Server 2005 offers three high availability alternatives: log shipping, failover clustering, and database mirroring. Peer-to-peer replication is another SQL high availability alternative; however, it is not applicable to SharePoint.

Log Shipping

Log shipping is a recommended solution for creating redundant copies of databases from a source SQL Server to another target SQL Server. The normal procedure of log shipping involves the transaction logs being backed up from a source server (primary server), copied across to another target server (secondary server), and finally restored. To provide high availability for SharePoint mission-critical databases, log shipping is adequate because first, it is inexpensive, and second, it is relatively easy to administer. This is the most cost-effective method available for creating redundant databases compared to significantly higher costs associated with a hardware cluster. Unlike database mirroring, which is limited to a single destination server, when using log shipping, it is possible to configure more than one secondary server for redundancy. On the other hand, log shipping offers a slower and manual failover process that is not seamless. Therefore, log shipping might not be the best solution for providing an organization with high availability when compared to the Windows clustering and database mirroring approaches. All SharePoint database connections will also have to be manually changed to reflect the name of the new target SQL Server.

Windows 2003 and SQL Server 2005 Clustering

Windows Server 2003 and SQL Server 2005 support the shared-nothing cluster model. In a shared-nothing cluster, each node of the cluster owns and manages its local resources and provides nonsharing data services. In case of a node failure, the disks and services running on the failed node will failover to a surviving node in the cluster. However, with high availability clustering, only one node is managing one particular set of disks and services at any given time.
SQL 2005 on Windows 2003 Enterprise or Windows 2003 Datacenter can support up to eight nodes within a single cluster. Failover clustering of SQL Server 2005 can be configured in two ways: a single-instance failover (Active/Passive) configuration or a multiple-instance failover (Active/Active) configuration.
Single-Instance Failover Configuration
In a SQL Server single-instance failover configuration, the cluster runs a single instance of SQL Server on all nodes in the cluster. If the main SharePoint SQL Server instance fails on the primary node, the surviving node or nodes will run the same SQL Server instance. In this configuration, all the servers within a cluster share a master database along with a set of SharePoint databases, such as the configuration and content databases.
In the multiple-instance failover configuration, each of the active nodes has its own instance of SQL Server. Each instance of SQL Server includes a separate installation of the full service and can be managed, upgraded, and stopped independently. To apply a multiple-instance failover configuration, at least two instances of SQL Server must be installed on the cluster and each instance should be configured to run on a certain node as its primary server.

Database Mirroring

Database mirroring is a new high availability alternative introduced in SQL Server 2005. This solution increases database availability by maintaining an up-to-date copy of the source database on a hot standby server in real-time.
Database mirroring consists of two mandatory roles and a third optional role. The first mandatory role is the Principal Server, which contains the source database and is the source of all transactions. The secondary mandatory role is the Mirror Server, which is another server, one that focuses on receiving transactions from the principal server. The Witness Server is the third and optional role, which detects and enables automatic failover between the principal and mirror servers in the event of a failure.
Mirroring is implemented on a per-database basis and works only with databases that use the full recovery model. The simple and bulk-logged recovery models do not support database mirroring. Database mirroring is supported in SQL Server 2005 Standard Edition and Enterprise Edition.
Database mirroring offers a substantial improvement in availability over the previous high availability alternatives. Implementation is simplistic and it is straightforward to maintain. It is similar to log shipping; however, when a database mirroring session synchronizes, it provides a hot standby server that supports rapid failover with no loss of data from committed transactions. In addition, unlike log shipping, the failover is nearly seamless and client applications can recovery with minor interruption by reconnecting to the mirror server.