作为一个数据库服务，SQL Server其实可以分成两个部分：
1) SQL Server服务本身
SQL作为一个应用服务，接受用户的连接，处理用户发过来的各项请求等。这部分功能是由一组安装在Windows上的可执行文件来提供的。如果这部分出问题，就需要恢复Windows系统、网络连接、SQLServer的可执行文件、以及SQL的一切相关配置。如何能保证这部分的正常运行，在系统故障时能够快速恢复，是非常重要的。
2) 存储的数据（数据库）
SQL Server将其处理和存储的数据以文件的形式存储在硬盘上。SQL可执行程序需要访问这些文件，才能访问到数据。如果数据文件发生损坏，管理员需要将文件里的内容恢复到“正确”的状态。当SQL Server的数据库文件达到几百GB，甚至上TB时，在磁盘上全部恢复这么大的数据量是很花时间的。所以一定需要使用相关技术，减少数据恢复时间。
而一个服务的生命周期是怎么样的呢？对SQL来讲，它无外乎两种状态：
1) 在线
SQL Server服务正常运行，数据库文件也可以被正常读写。这时候用户可以正常使用SQLServer服务。每个数据库管理员，都希望这个状态越长越好。
2) 宕机
也就是SQL Server由于用户连接无法建立，或者由于SQL服务的可执行文件不能正常运行，或者因为数据库文件不能被正常读写，而产生的宕机时间。严格来讲，宕机时间分成两个阶段：
2.1) 离线
从服务发生宕机问题，到被管理员发现，开始采取措施恢复服务之前。
2.2) 修复
管理员修复SQL Server服务所需要的时间。
数据库服务的可用时间=在线时间/（在线时间+宕机时间）
这样分析很有意思，您可以得到这样一个事实：
为了降低宕机时间，管理员可以通过:
1) 努力让系统从来不宕机或极少出现宕机事故，
或者
2) 能够很快地从宕机事故中恢复。也就是说，要能够很快发现SQLServer离线，并且能够快速地修复服务。
提高服务可用性的种种技术和方案，都是围绕着这两点来设计的。
讨论数据库系统的持续可用还需要区分两个概念：“高可用性”和“灾难恢复”。
“高可用性”（High Availability，简称HA）指的是数据库服务能够始终保持在线运行。在数据库系统中的某台服务器发生任何软件和硬件的故障时，还可以保持数据库服务不宕机，或者尽量缩短停机时间（downtime）。换句话说，“高可用性”技术主要关心的，是SQL Server服务本身。它要努力保证在任何一个时间点，客户端都能够找到一个SQLServer服务来响应它们的请求。
“灾难恢复”（Disaster Recovery，简称DR）指的是当数据库中的数据发生损坏或者不可访问时，可以在尽可能短的时间恢复全部数据或者恢复尽可能多的数据，从而保证应用系统的正常运行。有时灾难恢复也简称为“灾备”。“灾难恢复”是要保证数据库里的数据始终可用。理想情况下，假使一份数据因为火灾、地震这样的灾难而损毁，管理员也要能够很快地准备好第二份数据，供SQLServer服务使用。
“高可用性”和“灾难恢复”的概念非常接近，在很多文档中它们都被彼此互相涵盖了。本书倾向于将两者的概念区别开来：“高可用性”针对的是软件或硬件问题造成的数据库系统不可用；而“灾难恢复”针对的是保存在数据库系统中的数据不可用。这两者同等重要。例如用户经常使用的群集技术，它可以在一台服务器发生问题时，自动将SQLServer服务切换到另一台服务器上，从而使宕机时间缩短到几分钟甚至更短。所以它是一个广泛使用的“高可用性”技术。但是，如果数据库存储的磁盘发生损坏，群集的SQL还是不能使用。这时，需要有相应的“灾难恢复”技术，来帮助用户快速恢复数据库中的数据，从而快速恢复SQL Server服务。
SQL Server所提供的各种技术，有些针对于“高可用性”，有些针对于“灾难恢复”，有些对两者都有帮助。所以，用户需要清楚地看到各种SQLServer技术所针对的不同目标，然后根据自己的实际需求，选择最适合自己的方案。在本章接下来内容中，我们会逐个介绍SQLServer 各种传统的“高可用性”和“灾难恢复”技术。
