SQL Server 灾难恢复

  • 项目

SQL Server：利用备份进行灾难恢复

Paul 胜 randal

T在此处 不采取 SQL Server 备份，除非您知道如何还原这些多点。 如果您有任何内容更复杂的只是一个完整数据库备份比，您将需要了解一些 RESTORE 选项，以便能够成功地将数据库还原到需要的点的时间。

如果您有一个复杂的数据库布局或复杂的备份策略，并希望能还原，渚嬪单个文件组，或利用的部分数据库可用性，这是更多这种情况。
只要有一个有效的备份策略，而且是有效的备份您应该能够从您恢复时间目标 (RTO) 内和向您恢复点目标 (RPO) 在灾难恢复。 第一篇文章中此三部分系列，我介绍了各种类型的备份以及如何制定备份策略 （请参见"了解 SQL Server 备份" 在七月 2009年问题）。

此文章中我将介绍还原的工作原理以及如何执行一些更常见的还原操作。 如果您阅读完备份文章，并在该文章介绍我提到的背景材料，它将很有帮助。 我还将介绍几个更多的棘手操作，如执行时间点还原和具有部分数据库可用性联机逐段还原。

只是作为在 BACKUP 上以前的文章，我不打算介绍 RESTORE 语法的工作原理或穿过所有的还原操作的具体步骤。 SQL Server 联机丛书作用的一个极好的作业。 请参阅"RESTORE (Transact-SQL)"了解详细信息尤其示例传播整个主题。 有实际这么多选项来还原它的整个其他主题解释它们!" 备份和还原帮助主题 （SQL Server Management Studio）"说明如何使用该工具执行还原操作。

还原的四个阶段

让我们开始还原实际工作原理。 还原操作具有最多四个阶段：

  1. 文件创建和初始化
  2. 数据和/或事务日志复制
  3. 重做恢复阶段
  4. 撤消恢复阶段

灾难恢复的主要目标之一是尽可能快地使数据库联机。 如果灾难恢复计划涉及还原备份 （而不是说，未能通过数据库镜像），您将需要还原过程将尽可能快。 与每个四个的还原步骤，记住是否还有任何您可以执行它们加快内容吗？

数据和日志文件已经存在，第一步可以是本质上是跳过它们。 这意味着，如果您将覆盖现有的数据库不除去数据库在执行还原之前。 告诉 SQL Server 使用现有的文件使用第一次还原操作中的 WITH 替换选项。 如果文件不存在，它们将被创建并再初始化。 创建该文件是非常快，但初始化的过程零-它们可以是速度很慢。

出于安全原因，默认情况下，所有数据库文件将都是零初始化。 您可以启用即时文件初始化为 SQL Server 实例，哪些跳跃 zeroing 的进程的数据文件创建和增长包括那些还原--即使数据文件的大小仅千兆字节可能保存小时的停机时间，过程中所需的操作。 事务日志文件始终是零初始化因循环性质的事务日志本身。

您可以阅读更多有关所有这与联机，参考资料中我"即时初始化" 博客张贴内容类别。

您可能想有关第二阶段--为什么该项目不会说知道"和 / 或事务日志"？ 如果阅读了以前的文章您记得所有完全备份和差异备份还包括某些事务日志记录启用数据库还原到事务性一致点的时间。 两个阶段是一个纯粹的复制操作--执行数据的未处理--以便以加快这主要的方法是让 better-performing 的 I/O 子系统。 这是一个在几次，它是可接受"处问题引发硬件"。

其他方法来加快复制阶段是使用某种类型的备份压缩技术，或者本机 SQL Server 2008 或通过各种第三方解决方案之一。 复制阶段的两个部分都从备份媒体中读取和写到数据和/或日志文件。 如果您可以执行更少的读取 （使用压缩的备份媒体），可以加快整体流程代价是少量的 CPU 资源。

有关事务日志，以使事务性一致点时间中的数据库上运行故障恢复是三个和第四个阶段。 我所述的恢复在 2009 年二月文章中的详细信息"了解 SQL Server 中的日志记录和恢复功能". 请注意，第四个阶段是可选的如将稍后解释。

suffice 起来可说的更多的事务日志的需要恢复还原期间，将采用越长还原。 这意味着如果对于实例有一星期前从完整数据库备份和事务日志备份后的再还原过程每小时实质上是将重播之前完成最后一周中的所有交易记录。 我讨论此解决方案中以前的文章--添加到完整 plus 日志备份策略的差异备份。

差异数据库备份包含从最近的完整数据库备份后已更改，并可在还原操作中用于避免必须重播完整数据库备份和差异数据库备份之间时间段中发生的所有交易记录的所有数据文件页。 这可以大大减少还原该数据库所需要的时间，但代价是略微复杂一些的备份策略。

您可以联机丛书主题中找到详细信息"优化备份和还原性能 SQL Server 中".

您需要杩樺師什么？

当灾难 strikes 时的首先您需要做的是工作出什么已损坏，这将要听写从灾难中恢复时必须采取的操作与。 存储媒体鏁呴殰可能性包括：

  • 对整个数据库损坏 （对于实例任何已存储在数据库已破坏或数据库是一个数据文件和已损坏）。
  • 到单个文件组中的多文件组数据库损坏。
  • 多文件的文件组的单个文件损坏。
  • 要在数据库中单个页损坏。
  • 通过数据库传播损害。

您可以通过 SQL Server 的错误日志文件将无法访问，页读错误发生 （对于实例、 页校验和故障或数据被破坏页检测错误），或遇到该常规损坏了的通知查找确定损害。 如果发生损坏，它是运行 DBCC CHECKDB 一致性检查操作您将了解如何普遍损害是通常的做法。

一致性检查的解释是此文章的范畴，但您可以观看演示文稿在 tech-ed IT 论坛进行中标题为 2008 年十一月的视频"损坏生存技术"，和收听我介绍的数据库损坏 （直接下载链接是从前面今年一个 TechNet 收音机面试此处).

灾难不限于 I/O 子系统或服务器故障 — 还有要考虑的人为错误。 由编写拙劣的应用程序或粗心的 TRANSACT-SQL 语句 （在"我不知道我已在生产服务器上"方案） 通常会意外地删除数据库表 （或从它们的数据）。 在这样的情况下可以很难图出什么需要还原以及从时间，什么点，尤其是在任何人都拥有在使错误。 您可能获得幸运使用从默认跟踪其中 DDL 操作是仍可用或 DELETE 语句已捕获由您自己的日志记录--但是通常还有没有记录的标准报告的谁在做什么到数据库。 我将讨论这种情况下更详细地以后从恢复。 无论谁执行意外数据删除或它发生时，将更长时间等待恢复--或传递之前进行注意的问题--多个复杂的可恢复的更多的时间的。

因此，作为第一个步骤，如果数据库运行在完全恢复模型和事务日志是没有损坏，执行尾的-在-日志备份以确保备份到灾难的点的所有交易记录。 此"最终"事务日志备份将具有所有内容，直到该灾难的时间，并且可用于使所还原久远作为尽可能可能是最新的数据库。

简而言之，需要出必须还原工作。 然后它将成为一个问题的是什么，就无法恢复。

什么是您可以还原？

任何还原操作的目标是还原最少的可能备份，以便还原操作是尽可能快，同时还允许您以满足您 RPO 您 RTO 内完成。

此处提出主要问题是"什么备份必须？"如果您有唯一的备份是从一星期前完整数据库备份，并且整个数据库已丢失的只有一个恢复选项--在一周前丢失以来的所有工作然后时间点。 只需将放置备份策略应该始终确保您能还原需要的内容在灾难发生的以前的文章中介绍。

那么如何才能确定哪些备份，您有可用？ 首先，您可以查询各种备份 msdb 数据库中的历史记录表。 这些表包含的所有备份自上次备份的历史记录表都会清除被执行 SQL Server 实例中的记录。

就而言是备份本身，它是一种最佳做法包括数据库、 键入的备份，日期和时间，以便可以一眼标识备份的备份文件名称。 如果还没有执行此操作，您可以找出什么备份的文件包含使用 RESTORE HEADERONLY 命令。 这将显示实质上的元数据描述备份本身上的备份文件的标头的内容。 您可以阅读更多联机丛书主题中"查看关于备份的信息".

使用这两种方法尝试出还原顺序，使用还原损坏或删除数据。 还原顺序是必须还原的备份集和适当的顺序，在其中还原它们。 还原顺序可能很简单，只是一个完整备份的数据库、 文件组或文件），或一组复杂的完全差异备份和事务日志备份。

对于实例设想备份策略涉及到完整数据库备份、 差异数据库备份和事务日志备份方案。 如果发生系统崩溃，并且数据文件已损坏什么是还原顺序？ 图 1 阐释了此示例。

在本例中，最短和最快的还原顺序是最新完整数据库备份 (F)、 最新的差异数据库备份 (D2) 和然后所有后续的事务日志备份，直至并包括尾的-在-日志备份 （L7 和 L8）。

当规划还原顺序棘手的问题之一查找要还原的最早所需的事务日志备份 （有时称为查找"最小-LSN 或"最小的日志序列号"）。 在 的 图 1 中的该示例仅事务日志备份 L7 和 L8 所需，因为差异数据库备份 D2 数据库为带来更多最近的点中时间比所有以前的事务日志备份。

图 1：示例还原序列

SQL Server 将允许以前的不需要的事务日志备份以进行还原，但它们将不会使用和实质上是只需废物灾难恢复 time.Continuing 如果差异数据库备份 D2，会发生什么我示例已损坏或丢失？ 图 2 显示了这种情况。

图 2：还原序列与损坏的差异数据库备份

在此方案中最短和最快的还原顺序是最新完整数据库备份 (F)、 下一次的最新差异数据库备份 (D1) 和然后所有后续的事务日志备份 （L4、 L5、 L6、 L7 和 L8）。 这是可能的只有只要 D1、 L4、 L5 和 L6 备份仍然可用。 它是不要太快删除备份 ； 否则您可能遇到问题了灾难过程中很重要。

对于实例如果完整数据库备份 F 鎹熷潖除非上一次完整数据库备份仍然可用，否则，将无法恢复数据库。 如果 D2 完成时立即删除，差异数据库备份 D1，然后在 的 图 2 中方案将不可能，并还原顺序将涉及的所有事务日志备份以来完整数据库备份--一个可能很长的还原顺序。

这将引发的问题"时应在删除以前的备份？答案是肯定"它依赖 ！"如果您没有将某些长的时间周围备份一个法律义务，然后您，并取决于您拥有的备份策略和是必需的磁盘空间量。 不论，不立即删除以前的备份时尽快采取一个新 ； 最好保留至少一个或两个完整周期的备份之前除去的较旧的备份。 理想情况下，删除较旧的之前应测试您的备份。

事务日志的备份通常必须有所有这些由于执行最后一次完整数据库备份的原样最终回退还原顺序。 如果单个事务日志备份从事务日志备份"链"已丢失或损坏，还原操作不能继续过去的该间隙。 我正如提到以前的文章中的那样验证备份的完整性是即可还原成功的关键部分。

您可以找到有关找出您能还原全面的联机丛书主题中的内容的详细信息"使用 SQL Server 数据库还原序列".

示例还原方案

最常见的还原方案涉及完整数据库备份和再一个或多个事务日志备份时间内使数据库前滚。 可以执行此操作通过 SQL Server Management Studio (SSMS) 或 $ 通过 TRANSACT-SQL，虽然事情需要注意的如果您将直接使用 RESTORE 命令。

在还原一个备份，是时如何还原操作完成的三个选项，它们都与相关的故障恢复撤销阶段。 还原每个后续的备份中还原顺序，总是执行的恢复恢复阶段，但不能执行撤销阶段，直到恢复事务日志备份链中最后的备份。 这是因为没有进一步的事务日志备份恢复完成，立即应用，以便所有还原在还原顺序必须指定不以运行故障恢复撤销阶段。

遗憾的是，该默认是运行恢复--相当于使用 RESTORE 语句中的 WITH 恢复选项的撤销阶段。 还原多个备份时, 必须注意每个指定 WITH NORECOVERY。 在事实的方式数据表最安全的方法是使用还原序列中的所有还原的 WITH NORECOVERY 选项，然后手动完成恢复事后。 下面是一些示例 TRANSACT-SQL 代码，以还原完整数据库备份和两个的事务日志备份，并手动完成恢复，以使数据库联机：

FROM RESTORE DATABASE DBMaint2008
DISK = C:\SQLskills\DBMaint2008_Full_051709_0000.bak
替换、 校验、 NORECOVERY ；
转

FROM RESTORE LOG DBMaint2008
DISK = C:\SQLskills\DBMaint2008_Log_051709_0100.bak
与 NORECOVERY ；
转

FROM RESTORE LOG DBMaint2008
DISK = C:\SQLskills\DBMaint2008_Log_051709_0200.bak
与 NORECOVERY ；
转

RESTORE DATABASE DBMaint2008 WITH 恢复 ；
转

请注意，我还使用上的完整数据库备份还原 CHECKSUM 选项以确保它们都将还原为验证正在被恢复的数据库中存在任何页面校验和。

如果第一个 RESTORE 语句上未指定 WITH NORECOVERY，返回以下错误：

消息 3117，级别 16，1，状态行 1
无法还原日志备份或差异备份，因为没有文件已准备好前滚。
消息 3013，级别 16，1，状态行 1
RESTORE LOG 异常终止。

您必须非常小心使用右边的选项，否则为风险不必重新启动一个长的还原顺序 — 没有办法撤消恢复后它已完成。

没有，但是，一个有趣的选项，其类型的作用的--WITH STANDBY 选项。 这是最后一上文提到的三个选项。 通过运行故障恢复，撤销阶段的工作，但它保留记下它在"撤消"文件，指定其名称和路径） 中，然后使该数据库的只读访问权限。 数据库是事务性一致，但您必须能够继续还原顺序。 如果您决定继续，该撤销相反的 （使用撤消文件的内容），然后在下一个事务日志文件还原。 这是在两个方案中很有用：允许只读访问到日志传送辅助数据库和为还原序列期间查看数据库的内容。

如果您正在从恢复的灾难涉及的表的意外删除，对于实例可能要执行时间点还原。 有几种方法来执行此，但最常用的是要还原数据库，但确保过去的特定时间不会不继续进行恢复。 在这种情况下可以使用 WITH STOPAT 选项防止事务日志还原进入过去知道表时间已被删除。 对于实例使用 TRANSACT-SQL 示例之上，如果我愿意防止数据库正在被恢复以前的上午 1: 45，我可以使用以下语法上第二个 RESTORE LOG 语句：

FROM RESTORE LOG DBMaint2008
DISK = C:\SQLskills\DBMaint2008_Log_051709_0200.bak
与 NORECOVERY，STOPAT = ' 2009-05-17 01:45:00.000 ；
转

我甚至可以合并 STOPAT 和待机请参阅时间中是否是正确的点，然后再，如果不，以后等等还原几秒钟的时间与相同的事务日志备份。 这种操作变得非常乏味，但它可能是唯一的解决方案，如果您不知道什么时间的操作所花费的地方。

可以在联机丛书主题中找到这些，RESTORE 语句的其他选项的全面讨论"RESTORE 参数 (Transact-SQL)".

酷 SQL Server 2005 企业版中引入的新功能之一是部分数据库可用性。 此功能允许多个文件组数据库是联机并可作为长为至少主文件组处于联机状态。 显然，不能访问任何脱机文件组中的数据，但此功能允许非常大的数据库拆分成更容易、 更快的可恢复性的单独文件组。 已添加的另一种仅企业的功能是能够执行逐段还原 （对于实例单个文件组从多个文件组数据库） 联机，而该数据库的其余部分用于处理。

组合这两种功能启用某些非常复杂的和有效地还原方案，只要数据库构建这种方式，并且存在正确的备份。

您会发现一个极好、 深入 SQL Server 技术文章标题带有一些广泛示例 tinyurl.com/mbpa65 中可用的"Microsoft SQL Server 2005 部分数据库可用性"。 还有 Kimberly L.的 75 分钟录制 传递 tech-ed EMEA 会话标题为 Tripp"SQL Server 2005 VLDB 可用性和恢复策略"的是很好地值得观看。

还原到不同位置时的注意事项

它通常是附加到，并具有相同名称在同一 SQL Server 实例上正在还原数据库时，最简单的还原方案。 当移走进一步从该方案中，还原操作的结果变得更复杂。

如果正在还原数据库，在同一个实例，但具有不同名称，您可能需要对类似于 DTS/SSIS 包、 数据库维护计划、 应用程序字符串和任何依赖于数据库名称的元素所做的更改。

如果在同一服务器上的不同实例上还原该数据库，事情获取复杂得多：

  • SQL Server 登录将不同或不存在。
  • SQL 代理作业和 DTS/SSIS 包将不同或不存在。
  • master 数据库是不同，因此任何用户定义的存储的过程可能会丢失。
  • 因此有可能是客户端连接问题，将不同，SQL Server 实例名称。
  • 如果在不同的服务器实例上还原该数据库，列出的所有内容都适用，但那里可能会添加安全问题用作 Windows 帐户可能会不同，和它们可能是不同的 Windows 域中。
  • 一个另一个考虑因素是的 SQL Server 正在还原数据库的版本。 某些功能，如果使用该数据库中使该数据库"企业-仅"--它不能还原上一个标准版或更低 SQL Server 实例。
  • 在 SQL Server 2000 以及更早版本，这不是一个问题。 SQL Server 2005 中使用表或索引进行分区时，如果数据库是"企业-仅"在 SQL Server 2008 功能列表是：
  • 更改数据捕获
  • 透明数据加密
  • 数据压缩
  • 分区

所有这些需要 sysadmin 权限才能启用由从而潜在地中断灾难恢复计划涉及到标准版实例还原的表所有者，可以启用其中的数据压缩除外。 您可以判断是否任何这些功能中使用 DMV sys.dm_db_persisted_sku_features 数据库正在使用，并相应地调整灾难恢复计划。

进一步了解

为与上备份数据系列中第一个文章，只是有大量没有空间来覆盖的还原操作方面。 现在，您已经知道基础知识，但是，您可以深入一些更深入的信息联机丛书和博客的链接。 若要开始联机丛书中最好是主题"还原和恢复概述 (SQL Server)". 您还可以找到大量的信息上我的博客备份/还原的类别打头。

我想您从本文获得对该主 takeaway 是使用备份一个数据库成功恢复，需要进行练习以确保您知道要执行的操作。 您不希望被过程 high-pressure 的灾难恢复情况中学习 RESTORE 命令的语法。 您还可以备份策略不允许您在您的业务需求内恢复。 也许备份要花很长时间还原，也许日志备份会意外覆盖彼此，或您可能忘记备份服务器证书用于启用 SQL Server 2008 中的透明数据库加密。

到目前为止为灾难准备最佳方法是列出步骤穿过，并有一组将帮助确定存在何种备份和还原它们顺序的脚本的一个还原计划。 总是想说这应该进行团队中写入的最高层 DBA 和测试通过最初级的 DBA--以确保每个人都可以安全地执行该步骤。 但是，如果您在非自愿 DBA，您将需要整理一个计划自己，并确保您可以按照它。

下一文章中我将介绍如何恢复从数据库损坏，如果您没有任何备份，为什么您可能会选择执行修复操作，即使您有备份。
在平均值时间和作为始终，如果您有任何反馈或问题，除去我行-Paul@SQLskills.com.

归功于 Kimberly l。 提供本文的技术审阅 Tripp。

Paul 胜 Randal 是 SQLskills.com、 SQL Server MVP 和 Microsoft 区域导演的管理主任。 他从事 SQL Server 存储引擎团队在 Microsoft 从 1999年到 2007年。 Randal 编写了 DBCC CHECKDB/修复 SQL Server 2005 和 SQL Server 2008 开发过程中被负责核心存储引擎。 Randal 是灾难恢复、 高可用性和数据库维护的专家，世界各地的会议出席。 在他博客SQLskills.com/blogs/paul 并且上作为 @ PaulRandal Twitter。