SQL Q&A: Checksum Problems, Choosing the Correct Recovery Model and More

项目
08/17/2016

SQL Q&A 选择正确的恢复模型和更多的校验和问题

Paul S. Randal

Q我是 SharePoint 管理员，最近已经发现我的内容数据库的一个成为损坏时我每月的一致性检查发现的错误。我们追溯它与有缺陷的 RAID 控制器，而之后某些研究我们正在开启数据库页上的校验和。我的问题是：如何判断时的校验和不等待，直到每月的维护计划问题？

A有您可以执行一些操作。第一次，可以将的 CHECKSUM 选项添加到备份。进行完整和差异的备份，此选项将导致备份操作来测试任何页面校验和它看到，如果它找到一个损坏失败，出现一个错误。（我介绍这更详细地了解 SQL Server 备份的最后一个月的文章）。

第二个，请考虑经常比每月运行一致性检查。建议至少每周一的次运行某种形式的一致性检查是否这是一个 DBCC CHECKDB 数据库或可能上还原该数据库的副本。，当然，将取决于您 I/O 子系统与您舒适的级别。

第三个，添加一些 SQL 代理警报。可以在各种因素，SQL Server，错误引发一个特定的严重度或交叉阈值一个性能计数器通过引发一个特定的错误号上触发设置警报。此功能提供了监视服务器问题的一个非常强大机制。

将触发警报时一个消息发送到预定义的"运算符"使用这些选项之一或全部：呼叫程序消息、电子邮件，或 NET SEND。您可以使用若要定义一个运算符，存储过程 sp_add_notification.

就是而言 I/O 子系统问题，该错误您感兴趣是 823 824，825 错误。前两个引发 I/O 问题发生时（特别是，824 是时发现一个页面校验和是断开，825 SQL Server 时试图读取的操作多次完成之前）。这些是您想知道有关为立即尽可能以进一步限制损坏数据库（和可能的恢复的停机时间量）的所有问题。

823 和 824 是这两种严重级别 24 错误但 825 是仅严重级别 10 个"信息"消息（有关详细信息，请参阅我的博客张贴，" 即将 doom 的鲜为人知的标志: 错误 825.") 若要通知您应定义警报的所有严重级别的 24 错误和一个专门用于错误 825 这些的错误（实际上的最佳做法将每个严重级别从 19 到 25 的警报）。

若要定义实际的警报，可以使用 T-SQL 或管理 Studio。下面是要添加一个通知 825 错误的 T-SQL 代码的示例。

USE msdb;
GO 
EXEC msdb.dbo.sp_add_alert @name = N'825 - Read-Retry Required', 
    @message_id = 825,
    @severity = 0,
    @enabled = 1,
    @delay_between_responses = 0,
    @include_event_description_in = 1,
    @category_name = N'IO Subsystem Error';
GO

您可以找到定义和添加包括一个分步演练上添加使用我的 SQL 代理日志中的管理 Studio，警报的通知的详细信息类别"( SQL 2005 SP2 中的维护计划错误屏蔽鎹熷潖)."

Q我，开发人员的 DBA 者是负责一些代码和数据库中运行。我已经被 arguing 与其他一些数据库开发人员有关如何获取唯一的值来标识表中的行。希望用作该聚集的索引键的 GUID，但其他 arguing 它可能导致索引的性能问题。是此 true，如果是这样，可以您解释一下为什么？

A 是，的确 — GUID 是一种前导 SQL Server 数据库中的索引碎片的原因。

GUID 是一个全局唯一标识符。 SQL Server 中,，这是 16 字节值生成 SQL Server 中或其他位置（如通过.NET 客户端的或 mid-tier 中）。 GUID 通常具有一个随机值，除非使用 NEWSEQUENTIALID 函数 SQL Server 2005 中引入生成。

此函数生成可帮助解决的一些问题将在此处介绍的 GUID 的范围。但它需要生成服务器端 GUID 到数据层向下发送数据之前，必须生成唯一的标识符，因为不在许多应用程序环境中起作用。

无论其中生成无序的 GUID，让它为前导键索引中的表示实质上是随机，密钥是插入点在索引中新记录的则还随机 — 键记录的值决定了它在索引中的位置。它还意味着 16 个字节 GUID 将出现在允许从非聚集索引的记录导航到聚集的索引获得列值为查询选择列表不在非聚集索引所用的（通常也称为书签查找）中的记录，存储引擎的链接的一部分的每个非聚集索引的每一行中。

为更多的记录插入到索引，则存储记录的页填满。如果要在已经是完整的页面上插入记录（请记住，密钥值确定在新记录），然后必须拆分页面，将移动到新分配页的一些记录。页拆分是要执行的一个昂贵的操作（一个新页是分配并链接到索引，和记录被移动到新页上），并使碎片。

页拆分导致逻辑碎片影响范围扫描性能）的索引由导致物理和逻辑的顺序索引中的页面可以不同。它还会导致较差的页密度（在页上没有未使用的空间）的指向页和较差的磁盘 I/O，内存利用率上浪费的空间。

有关索引的碎片，以及如何检测并删除它的详细信息，请参阅我的 2008 年 8 月文章" 最重要的有效的数据库维护的提示." 选取一个很好的聚集的索引键超出了本文的范围，我将让我的妻子，Kimberly L。 Tripp，解释。请参阅也将进入 GUID 和聚集的索引结构"(有关详细信息的主题上张贴她好日志 GUID 作为主关键字和/或聚集键.")

Q我们的高可用性策略是使用日志传送到几个辅助服务器。我们的管理团队 pressuring 我一些使用冗余服务器以节省资金支出。我的想法是使用辅助服务器允许报告查询以运行，还会有卸载报表工作负荷从主服务器的好处。为执行此操作可能会运行哪些问题？

A 这种情况下的成为当前的经济气候的公司不希望显示（即使它们提供数据库的冗余副本）为空闲坐解决这一问题的服务器中更为常见。

您可能已经知道，当您设置了日志传送中，您可以定义如何在辅助服务器上还原事务日志备份）的 NORECOVERY 或的待机。前者不允许任何访问数据库，而后者允许只读访问数据库。这将使用特殊模式下位置恢复运行数据库并且事务性保持一致，但执行该操作却存储在单独的撤消文件中，以便可以进一步还原事务日志备份（我将讨论此详细下个月文章中有关使用还原）。

若要允许在辅助服务器上报告，您要使用的待机，所以报告的查询可以连接到数据库。一次您允许您立即运行了一些问题的用户连接。

第一次，使用的待机选项可能会导致 seeming 才能很长时间的事务日志备份在第二台服务器上还原为下一次事务日志备份可以被还原之前，必须重播撤消文件的内容。如果撤消文件中包含大量的操作，这可以是问题。

第二个的事务日志备份还原并不是联机操作。没有人可以连接到数据库的还原持续时间内。这意味着您辅助报告服务器的所有连接必须是删除，再还原完成后重新连接。此处有一个问题：就可以恢复下一次事务日志备份时, 是否终止用户连接或允许它们完成的查询？这完全取决于您。

如果您决定不终止连接，请记住一个问题：如何长您允许继续之前强制终止查询？再在等待，越长已经因为上一次日志备份所还原，并进一步的隐藏辅助一个主数据库获取。这可能是一个问题，如果要然后故障转移到辅助，因为有可能使数据库为到目前为止最尽可能，最小化鏁版嵁涓㈠け等待要还原的日志备份的队列。

您可以找到有关这些的选项，以及监视问题，如联机丛书主题中在第二台服务器上最后一次日志备份还原后的时间长度的详细信息" 使用辅助服务器的查询处理."

Q是否可以如何选择正确的恢复模型？从我已阅读，好像我应该将使用大容量日志记录减少我的事务日志大小，但它看上去像我的日志大小仍然不断使用。是否可以使用模式，不使用事务日志在完全避免鏁翠釜闂   吗？

A Ne 听说几次请求的是未记录的数据库在所有不生成任何事务日志记录时特别是对于 tempdb 的用户视图作为临时数据库由于重新创建它的服务器启动时。

据我所知这将永远不会发生 SQL Server 的。要获得的最佳的方式 BULK_LOGGED，大大剪切项下的事务日志量生成的某些操作（如索引重建和大容量装载）。所有数据库，甚至 tempdb，必须都具有允许回滚的事务日志记录的某些级别（也就是要撤消所有操作的事务的一部分）中用户取消该操作或某些错误，导致操作失败的事件。

除了 tempdb，数据库更重要的是一个系统崩溃发生数据库必须能够在不离开事务性不一致的数据或结构上一致的情况下恢复（也就是已损坏) 数据库。设想一下，是否没有什么有崩溃之前数据库中已更改的记录 SQL Server 如何运行恢复？您可以阅读更多有关在我的 2009 年 2 月文章中如何工作日志记录和故障恢复" 了解日志记录和 SQL Server 中恢复."

选择恢复模型，一个重写的问题将确定您的选择：要能够在发生灾难的执行点的时间"或"最新"故障恢复吗？如果是这样，您打算在某些情况下使用完全恢复模型（和可能 BULK _LOGGED 模型）。如果您不感兴趣这样，然后使用 SIMPLE 恢复模型。

如果不希望能够将数据库恢复（而不丢失工作最后一个数据库或差异备份后），而不是满使用 SIMPLE 原因是使用在 SIMPLE 恢复模型您不必执行事务日志备份，以管理事务日志的大小。

现在，可能会有其他原因您为什么必须使用完全恢复模型，如果希望使用例如，数据库镜像（DBM 仅支持 FULL 恢复模式）或日志传送（日志传送支持这两个 BULK_LOGGED 和 FULL 恢复模型）。在这两种情况下，您将必须确保您采用事务日志备份，以便日志不会增长太大（即使您只是最终丢弃它们）。

我提到过您可能有时会希望使用 BULK_LOGGED 恢复模式，而不是始终运行在该模式下。这是因为有一些限制周围并没有 BULK_LOGGED 恢复模式中最后一个事务日志备份后的最小日志记录操作时，从日志备份还原。详细信息太复杂，介绍了在本专栏中，但您可以找到更多信息此，和一般情况下，选择恢复模型，联机丛书主题中有关" 恢复模型概述."

Paul Randal S。被管理的 Director SQLskills.comMicrosoft 区域 Director 和一个 SQL Server MVP。他从事 SQL Server 存储引擎小组在 Microsoft 从 1999年 2007年。 Paul 编写 DBCC CHECKDB/修复 SQL Server 2005 但负责，核心存储引擎 SQL Server 2008 开发过程中。 Paul 是灾难恢复、高可用性和数据库维护方面的专家，常规演示者在全球范围内的会议大小写。在他博客 SQLskills.com/blogs/paul您可以发现他 Twitter 在上 Twitter.com/PaulRandal.

其他资源