通过

  • 项目

灾难恢复计划

在管理 SQL Server 数据库时，为从可能出现的灾难中进行恢复做好准备至关重要。为了在发生灾难后恢复数据库，为 SQL Server 备份制订设计合理和经过测试的备份和还原计划十分必要。有关详细信息，请参阅 SQL Server 中的备份和还原策略简介。而且，为了确保在发生自然灾难时您的所有系统和数据能够快速还原到正常操作状态，必须创建灾难恢复计划。创建此计划时，应考虑为可能影响您的系统的各种灾难类型制订恢复方案。这些灾难包括自然灾难（如火灾）和技术灾难（如 RAID-5 阵列中两个磁盘出现故障）。创建灾难恢复计划时，应确定应对每种灾难的所有必要步骤并为它们做好准备。有必要测试每个方案的恢复步骤。我们建议通过模拟自然灾难来验证灾难恢复计划。

设计备份和还原计划时，应根据您自身的特定环境和业务需求来考虑灾难恢复计划。例如，假设失火了并且烧毁了您的 24 小时数据中心。您是否有把握恢复数据？恢复系统并保证系统运行需要多长时间？您的用户能够承受丢失多少数据？

理想的情况是，灾难恢复计划应规定恢复所需的时间以及用户可以期望的最终数据库状态。例如，可以确定在获取指定的硬件后，在 48 小时内完成恢复，并且保证最多能恢复到上周末时的数据。

灾难恢复计划可以通过多种方式构建，并且可以包含各种类型的信息。灾难恢复计划类型包括：

  • 获取硬件计划。

  • 通信计划。

  • 发生灾难时的联系人名单。

  • 与负责处理灾难的人员的联系方式。

  • 对计划拥有管理权的人员的信息。

  • 每个恢复方案所需执行的任务的清单。为了便于您检查灾难恢复的进度，将初始化已完成的任务，并在清单中指示任务完成时间。

SQL Server 恢复模式

SQL Server 提供三种可供选择的恢复模式：简单恢复模式、完整恢复模式和大容量日志恢复模式。恢复模式是一个数据库属性，它用于控制数据库备份和还原操作基本行为。为每个数据库选择最佳恢复模式是计划备份和还原策略的必要部分。为给定数据库选择何种恢复模式在一定程度上取决于系统的可用性和恢复要求。恢复模式的选择反过来也会影响数据库灾难恢复的可能性。

有关恢复模式的说明，请参阅恢复模式概述。

管理备份媒体

我们建议在备份计划中包括管理备份媒体的条款，例如：

  • 存储和回收备份集的跟踪和管理计划。

  • 覆盖备份媒体的计划。

  • 在多服务器环境中，使用集中式或分布式备份的决策。

  • 跟踪媒体有效生存期的方法。

  • 将丢失备份集或备份媒体（如丢失磁带）造成的影响降到最小的过程。

  • 将备份集存储在站点内或站点外的决策，以及对这样做将如何影响恢复时间的分析。

有关 SQL Server 如何使用备份设备和媒体的信息，请参阅在 SQL Server 中使用备份媒体。

运行基本功能脚本

通常，应在灾难恢复计划中包含基本功能脚本，以确认所有事情是否按预想的方式进行。基本功能脚本为系统管理员或数据库管理员提供了一种可靠的工具，用于验证数据库是否回到可工作状态，而无需依赖于最终用户。

基本功能脚本是应用程序专用脚本，并且有多种形式。例如，在决策支持或报告系统上，该脚本可能只是几个主要报告查询的副本。而对于联机事务处理 (OLTP) 应用程序，该脚本则可能是执行 INSERT、UPDATE 和 DELETE 语句的批处理存储过程的执行计划。例如，基本功能脚本可能与从 sqlcmd 实用工具向服务器发送批处理 SQL 语句的 .sql 文件一样简单。另一个示例是使用包含 bcp 命令和 sqlcmd 命令的 .bat 文件。

确保为灾难的到来做好准备

为了确保您为灾难的到来做好准备，我们建议您定期执行下列活动：

  • 在真正的故障发生之前，彻底测试您的备份和恢复过程。测试有助于确保您拥有从各种故障恢复所需的备份，确保已明确定义和记录过程，任何合格的操作员都可以顺利迅速地执行该过程。

  • 定期执行数据库和事务日志备份，以使丢失的数据量降到最低。建议同时备份系统数据库和用户数据库。

  • 以安全的方式维护系统日志。保留 Microsoft Windows 和 SQL Server 中安装的所有 Service Pack 的记录。保留所使用的网络库和安全模式的记录。此外，如果 SQL Server 在混合模式身份验证（SQL Server 和 Windows 身份验证模式）下运行，则将 sa 密码记录在安全位置。有关详细信息，请参阅安全性和保护（数据库引擎）。

    重要说明重要提示

    Windows 身份验证比 SQL Server 身份验证要安全得多。请尽量使用 Windows 身份验证。

  • 在其他服务器上，评估从灾难中恢复要采取的步骤。如有必要，根据需要修改这些步骤使其符合本地服务器环境，并测试修改后的步骤。

  • 维护基本功能脚本以快速评估最小功能。

审核并减少潜在灾难性的用户错误

一个更具挑战性的恢复方案是从严重的用户错误（例如，不慎删除了数据库对象）中恢复。本节列出的工具有助于审核对数据库所做的更改，某些情况下也会有助于调整对数据库所做的更改。

  • 数据定义语言 (DDL) 触发器

    可以创建这些触发器来审核及调整对数据库架构所做的某些更改。DDL 触发器激发存储过程以响应各种 DDL 语句。这些语句主要是以 CREATE、ALTER 和 DROP 开头的语句。DDL 触发器的作用域可以为某个特定数据库，也可以为整个服务器实例。有关详细信息，请参阅了解 DDL 触发器。

  • 事件通知

    执行事件通知可响应各种 Transact-SQL DDL 语句和 SQL 跟踪事件，并将这些事件的相关信息发送到 Service Broker 服务。

    可以对 SQL 跟踪捕获的许多相同事件的事件通知进行编程。但与创建跟踪不同，您可以使用事件通知在 SQL Server 实例内部执行操作以响应事件。由于事件通知异步执行，因此，这些操作不会占用立即事务定义的任意资源。有关详细信息，请参阅事件通知（数据库引擎）。

    注意注意

    并非所有的 DDL 事件都可用于 DDL 触发器中。有些事件只适用于异步非事务语句。例如，CREATE DATABASE 事件不能用于 DDL 触发器中。应该针对此类事件使用事件通知。

  • SQL Server 代理

    这是一种 Windows 服务，可执行计划的管理任务（称为作业）。SQL Server 代理使用 SQL Server 存储作业信息。在其他事务中，SQL Server 代理可以运行作业以响应特定的事件（例如，具有特定严重级别或消息号的错误）。

    有关 SQL Server 代理的介绍，请参阅自动执行管理任务（SQL Server 代理）。有关如何针对事件使用 SQL Server 代理的信息，请参阅监视事件和响应事件。

  • SQL 跟踪

    SQL 跟踪提供了 Transact-SQL 系统存储过程，以针对 SQL Server 数据库引擎实例中用户选定的事件类创建跟踪。可以在您自己的应用程序中使用这些系统存储过程来手动创建跟踪。有关详细信息，请参阅 SQL 跟踪简介。

    注意注意

    SQL Server Profiler 是用于 SQL 跟踪的图形用户界面，用来监视数据库引擎或 Analysis Services 的实例。有关详细信息，请参阅使用 SQL Server Profiler。