通过

  • 项目

SQL Q & A 删除索引碎片，同步与同步及其他

Paul S. Randal

Q我是有关如何删除索引碎片影响统计信息相混淆。 我已经听到我应在有时重建后重建索引我统计信息，然后有时我不，重建聚集的索引会影响其他的索引太。 可以在 shed 此请上的某些灯我想要确保我不无意中使性能更糟糕？

A这当然是一个的问题导致大量混淆，但右全面的数据库维护策略包括删除索引碎片，并更新统计信息。 我不要进入完全有时间和要删除索引碎片的原因的详细信息） 的请参阅 8 月 2008 文章" 有关有效的数据库维护的前提示." 相反，我假设您知道该索引使用，我将只重点操作的工作方式。

第一部分是混淆的周围的碎片删除操作影响统计信息。 重建索引 （使用 ALTER INDEX … 重建、 DBCC DBREINDEX 或使用 DROP _ CREATE INDEX … WITH EXISTING） 不会更新统计信息与完整的扫描的等效但重新组织索引 （使用 ALTER INDEX … 重组或 DBCC INDEXDEFRAG） 不会更新统计信息的是所有即使同时删除索引碎片。

原因重建不会更新统计信息，不重新组织必须与用于这些操作的算法。 索引重新生成操作已索引的全面并且因此会更新统计信息正确。 在重新组织操作但是，只对执行运算的索引的几页一次并为整个索引不能正确地更新统计信息。

混淆的第二部分是在重建索引时将统计信息更新哪些。 有两种常规类型的一个表的统计信息） 的表的索引的列和非索引的列。 索引重新生成操作只更新正在重新生成索引的统计信息。 非索引的列的统计信息必须手动更新维护计划中。 此外，如我"的有效的数据库维护的前提示"文章中提到的您必须小心，不要手动重建该的索引后更新索引统计信息为手动更新可能会使用小于 100%的示例速率，而索引重新生成将使用完整扫描 (100%) 示例的等效项。 换句话说，这可能导致用样本的统计信息覆盖全扫描统计信息。

混淆，最后一部分是围绕重建索引有何影响对其他索引。 答案总是该特定索引和它的统计信息重建索引只影响。 例外情况是对 SQL Server 2000，位置重新生成类的索引会也导致所有非聚集索引重建表中的非唯一群集索引。 这已得到修复从 SQL Server 2005 向前直到。 在我的博客文章中，您可以找到这一点上的详细信息" 从每个角度的索引."

若要汇总，在索引和统计信息维护应执行以下：

  • 重新生成或重新组织索引删除碎片
  • 更新索引统计信息不重新生成的这些索引的
  • 更新非索引的统计信息

Q我已经被试验 SQL Server 2008，，我已发现一些奇怪的行为。 似乎，如果我启用生产数据库中的数据压缩，然后备份数据库并尝试在 Standard Edition 实例上还原它，在还原将失败 ！ 此预期的行为？ 这样，是否这限制了数据压缩或任何其他功能影响？ 为什么不还原失败立即而不是为整个还原出现故障之前 seeming？

A您看到的行为是特意。 最"只企业"功能只是限制的版本与您可以使用功能来 Enterprise Edition、 Enterprise Evaluation Edition 和 Developer Edition 的 SQL Server。 有一些功能，但是的 SQL Server 版本可以还原包含功能的数据库的备份，也限制。 您已经找到具有此限制的 SQL Server 2008 功能之一，数据压缩。

行为是实际的 SQL Server 2008 不新增的。 在 SQL Server 2005，如果数据库包含任何分区的表或索引 （显式使用该分区的功能），然后该数据库的备份只能还原使用列表中的版本我刚才提到。 有两个问题这，但，SQL Server 2005 中。 首先，可能很难判断是否没有一个的数据库任何分区，以及然后，还原不失败之前只是将已完成之前。

这意味着您不了解您的还原将之前所等待通过整个 （可能长期运行） 还原操作失败。 这是因为数据库不事务性一致，直到完成的还原恢复部分），因此操作恢复过程中的可能会添加或删除分区。 遇到这种情况下可以是在灾难恢复情况下，唯一的服务器可以快速获取还原该数据库正好是 Standard Edition 非常令人讨厌。

SQL Server 2008 中的具有此行为的"仅企业"功能列表已增长到 4： 数据压缩、 更改数据捕获、 透明的数据加密，和分区。 这意味着更多的人将会遇到此问题。 为此新的 DMV 添加，这样轻松地检查任何这些功能是否启用数据库中的 DBA 的 sys.dm_db_persisted_sku_features。

对于是实例表已启用数据压缩数据库中, 运行该 DMV 将提供以下结果：

SELECT * FROM sys.dm_db_persisted_sku_features;
GO
feature_name    feature_id
--------------  -----------
Compression     100

但是，SQL Server 2008 没有解决该问题在还原操作不必 DBA 通知实际上无法还原数据库之前几乎完成。 实际上，此问题不太可能解决给定方法的性质还原工作，请参阅在 从 10 月 2008 问题的 SQL 问题与解答列 有关详细信息。

如果有可能的数据库需要 Standard Edition （或一个较低版本） 上还原，，就强制 DBA 禁止这些功能或定期使用该 DMV 试图还原在严重情况时避免棘手的意外。

Q我已经实现同步的数据库镜像，并受这意味着与主体数据库始终同步镜像数据库的印象。 但是，我偶尔会过镜像状态会同步而不是 SYNCHRONIZED，以及当我们首次建立镜像。 为什么会这样发生？

A我回答问题之前，我将定义 SYNCHRONIZED 和同步数据库镜像状态。 一个简单地说数据库镜像通过不断地发送主体数据库的宿主 SQL Server 实例和镜像数据库的宿主的实例之间的实际交易记录日志记录的工作原理。 如果没有等待发送到镜像主体交易记录日志记录，同步镜像的状态 （即，两个数据库都保持同步）。 如果交易记录但尚未发送到镜像 （镜像数据库为"隐藏"主体） 的日志记录，镜像的状态是同步。

该方法用于初始化数据库镜像是执行一个完整数据库备份和至少一个事务日志备份，并将其 （使用 WITH NO_RECOVERY） 还原在镜像上。 然后启用镜像时, 镜像的状态是初始同步。 这是因为有可能是某些事务活动主体上自上次在镜像已还原的日志备份。 这种很可能为常量工作负荷的数据库。

以最小化尝试使镜像数据库为最新，可以使用的镜像的状态保持同步的时技巧日志备份。 但是，常量工作负荷数据库这可能很难，因此镜像的状态将最初在同步时间。 一旦镜像捕获设置，镜像的状态将更改 SYNCHRONIZED。

之后，有可能为镜像数据库再次退之后的情况镜像的状态将删除回要同步的该主体。 一个原因是时间的如果镜像和主体是时间的无法进行通信。 或者它可能主体生成事务日志速度比在日志可以发送到镜像。 在任何一的种情况下和根据数据库镜像的配置方式中，主体数据库可能会继续处理交易记录和事务日志记录将建立 （称为 SEND 队列） 的队列。 这必须发送到镜像为了捕获设置。 直到镜像数据库已捕获设置，镜像的状态将保持同步。

在主体和镜像之间不可靠网络链接是否可以看到镜像同步和 SYNCHRONIZED 之间进行切换后端和-提出的状态。 可以在白皮书中找到这些状态的完整讨论 数据库镜像 SQL Server 2005 中.

Q我们必须同步的数据库设置镜像集，我们主要应用数据库的并我们监视显示在镜像上的恢复队列通常附近零。 我们希望为报告使用镜像数据库和一致性检查，因此我们可以进行更好地使用冗余硬件。 我们知道这是可能，但有任何缺点这样我们应该知道的呢？

A 这是非常习惯，但有可能需要注意的一些缺点。

第一个问题授权。 如果该实例仅用于该目的的可用 SQL Server 实例作为镜像数据库的宿主的许可证。 一旦在镜像数据库上创建数据库快照，或执行任何其他与该 SQL Server 实例操作，您必须购买许可证。

就而言一致性检查，在镜像数据库上运行 （通过数据库快照） 不会提供主体数据库的一致性保证。 仅事务日志记录与镜像在的数据库之间这样如果 I / O 子系统损坏了主体数据库中的一个页，将不被镜像数据库镜像的损坏。 这意味着镜像数据库的一致性检查主体数据库上将无法看到该损坏的页。

报告是数据库镜像的一个正确用法。 用户所遇到的第一个问题是如何刷新对运行报表的数据库快照。 无法刷新快照，因此必须创建新的快照数据库和报告应用程序必须连接到新的快照中。 这需要额外的逻辑内置报告应用程序。 第二个问题确定报告应用程序应在镜像的故障转移事件中的行为方式，应该保持连接到新的主体，或它应该移动到新的镜像？ 到详细信息的访问，对此不在本文的范围之内。

镜像数据库任何额外使用主要问题是可能导致在镜像上的性能问题。 创建数据库快照将添加额外的 I / O 负载，页面更改到镜像数据库第一次它必须被推到数据库快照。 此外，然后数据库快照放置任何工作负荷增加了 I / O 负载在镜像数据库上的，读取数据库快照在页的许多将真正将读取从该镜像数据库因为它们将不具有更改创建快照后。

此额外的镜像数据库上的 I / O 负载可以降低在重播事务日志记录，进而导致一个待办事项。 此待办事项调用恢复队列，并且是镜像数据库可以联机在故障转移之后之前必须重播的事务日志的量。 大 I / O 负载数据库快照，较大恢复队列将可能增长镜像数据库和越长数据库上的将不可用在故障转移之后。

您未提到的您恢复 Queue Length 是通常接近零，因此这可能不是您的问题，但它是明确以便不最终危及中增加能够运行报表的回报的数据库的可用性监视出的。

Randal Paul S。 被管理的 Director SQLskills.com和 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.