High Availability

In many mission-critical environments, the application must be available at all times—24 hours a day, seven days a week. SQL Server helps ensure availability by providing online backup, online maintenance, automatic recovery, and the ability to install SQL Server on a cluster for failover support. SQL Server's dynamic online backup allows databases to be backed up while users are actively querying and updating the database. The SQL Server Agent service provides a built-in scheduling engine that enables backups to occur automatically, without administrator involvement. You can also accomplish other maintenance tasks, such as diagnostics, design changes (for example, adding a column to a table), and integrity changes without having to shut down SQL Server or restrict user access.

Only a few systemwide configuration modifications, such as changing the maximum number of user connections, require that SQL Server be restarted. Although reconfiguration doesn't commonly occur in a well-planned and well-deployed production system, it can typically be completed with less than a minute of system downtime if it's necessary.

In the event of a system failure, such as a power outage, SQL Server ensures rapid database recovery when services are restored. By using the transaction logs associated with each database, SQL Server quickly recovers each database upon startup, rolling back transactions that weren't completed and rolling forward transactions that were committed but not yet written to disk. In addition, you can set the SQL Server Agent service to continually monitor the state of SQL Server. If an error occurs that causes SQL Server to stop unexpectedly, the service detects this and can automatically restart SQL Server with minimal interruption.

In cooperation with shared-disk cluster hardware, SQL Server Enterprise Edition provides failover support when you install one or more instances of SQL Server 2000 on a node that's part of a Microsoft Cluster Service (MSCS) cluster. Up to four nodes can be part of a cluster. The applications communicating with SQL Server don't need to know that the server they're connecting to is actually a virtual server, which can be running on any member of a cluster. If the server on which SQL Server is running fails, one of the other servers in the cluster immediately takes ownership of the disks that hold the SQL Server data and takes over the failed server's workload. The other servers in the cluster don't need to be inactive when the first server is working—they can run SQL Server while it performs other activities.