• 项目

SQL Q & A 数据库一致性、 临时表，和更多信息

Paul S. Randal

Q我们的 SQL Server 2005 数据库之一上，我已注意到某些很奇怪的行为。 我们在数据库上运行 DBCC CHECKDB 作为我们每夜的数据库维护的一部分，并且某些整夜，DBCC 返回损坏错误。 奇怪的事情是我们没有看到页校验和错误前一天，并如果手动运行 DBCC CHECKDB 维护作业失败后的在上午，消失，损坏。 可以解释的？ 这有已发生的有关一个月，我关心我不能信任 DBCC CHECKDB。

A很好必须 DBCC CHECKDB 作为您的定期维护的一部分，启用页校验和。 发生时您描述该问题会非常 disconcerting，几乎好像 DBCC CHECKDB 提供不正确的结果。 但这种情况下不会发生个如此频繁有损坏的没有运行时指示，DBCC CHECKDB 查找损坏，而且然后多个小时之后，损坏消失时都再次运行 DBCC CHECKDB。 让我们看此分步。

首先，就很常见的报告的 DBCC CHECKDB 未报告常规数据库操作过程中的损坏。 尽管页校验和是检测 I / O 子系统所造成的损坏的好方法，但它们是有效的仅当数据页读取由 SQL Server （发生损坏之后。

假设数据页面是具有应用于页校验和，并已然后损坏在更高版本由 I / O 子系统。 即使不是页校验和将检测到损坏，也是仅当 SQL Server 页校验和验证，并在发现损坏的将页读取到内存。 如果该页面永远不会读取 SQL Server，将永远不会被发现损坏。 这就是很重要启用页校验和，并定期执行一致性检查的原因，一致性检查将读取验证其页校验和，并发现损坏尽早数据库中的所有页。

在您的案例它的外观像在损坏已发生了未阅读作为常规数据库操作的一部分的数据页中，，所以，损坏不发现 DBCC CHECKDB 读取已损坏的页之前。 虽然它看起来如如果页校验和不检测损坏 （按应有，但这并不这样。

第二，"消失"损坏可以很轻松地发生，DBCC CHECKDB 而仅在两个 DBCC 运行之间发生更改的数据库上执行的连续期间。 假设一个页面已确实损坏，并且 DBCC CHECKDB 报告为已损坏。 现在假设页是然后释放从表 （是例如因为可为空）。 后续的 DBCC CHECKDB 将无法阅读该这一次并因此将不报告它被损坏。 DBCC CHECKDB 读取只分配页 （当前正在使用的含义页）。 您的情况，我猜测夜间维护作业的其余部分包括索引重建或重新组织，这两个可以极大地改变可以分配到特定的对象或索引的页面的一组。 这将考虑您看到此问题。 索引重新生成一个副作用释放已损坏的页而且然后下一个的 DBCC CHECKDB 回干净。

若要捕捉损坏的页，更改您的维护作业，以便它停止如果 DBCC CHECKDB 步骤失败。 这种方式，您可以手动验证该损坏和采取进一步的措施。

Q我们计划从 SQL Server 2000 直接升级到 SQL Server 2008，跳过 SQL Server 2005。 但我很担心 tempdb。 这已导致问题为我们 SQL Server 2000 中, 我们具有大量短的临时表。 从什么我了解，tempdb 用于更多大量现在 (SQL Server 2005 和 SQL Server 2008） 中并特别提供有办法阻止升级后删除的性能。 可以解释为什么这是这样，我们应该做？

A从您的问题，我猜测您所必须实现单文件的每个的处理器 tempdb 体系结构由多个数据库连接创建多个短的临时表时通常所需的。 可能有甚至必须启用 1118 跟踪的标志 （请参阅" 将 tempdb 数据库的并发性增强"有关详细信息此)。

尽管粗 tempdb 使用 SQL Server 2005 下列时间之后可能您可能会不看到这特别是使用依赖于 tempdb 的功能。 请注意如果您需要遇到 SQL Server 2000 tempdb 性能问题的解决方案并将其升级到 SQL Server 2008 同一硬件上，您应在许多情况下看到性能问题将 alleviated 也略有原因的 SQL Server 存储引擎 SQL Server 2005 中某些 tempdb 特定更改。

请使大量的功能使用 SQL Server 2005 上的 tempdb 的并且 SQL Server 2008：

  • 联机索引操作
  • DML 触发器
  • 多活动结果集 (MARS)
  • 快照隔离 （事务级和语句级别）

这些功能的全部四使用称为版本控制的底层技术存储的数据记录的各种时间点版本。 简单地说，这些记录版本存储在 tempdb 中, 版本存储用于共享相同的版本存储在单个 tempdb 中的所有用户数据库。 在多个您使用这些功能，在 heavier 版本存储的使用和因此 tempdb 将为，并且更可能有将为的性能影响。

任何成功升级的关键是与新的架构的测试系统实现典型的生产负载，并测量以避免可能遇到如果要直接进入生产的意外性能。

遗憾的是，讨论是方法超出了范围本专栏的封面深入，但有可用，我建议您签出一些极好资源：

Q我们要实现夜间数据库维护计划，包括改进索引性能。 我已经听到设置索引的"填充因子"选项可以完全删除需要维护索引。 这真吗？ 似乎我们的数据库中的一些索引从碎片会受到影响，一些无。 我们应设置为将应用于所有索引的数据库在默认填充因子并如果是这样，值应我们使用？

A填充因子设置可以确实将用于部分缓解需要索引维护，但是很少它可完全删除需要。 一个简单地说，填充因子设置指示存储引擎创建或重新生成时保留一定百分比的群集和非聚集索引的页中的可用空间。 （注意填充因子设置不维护常规插入/更新 / 删除操作过程中）。 90 的填充因子对是实例保留 10%的可用空间。 填充因素的 0 或 100 个保留 （这已被更混淆的源） 没有可用空间。

其理念是空间保留在页面，这样页上的记录或要在页面上插入而未导致调用页面分割的成本、 碎片导致操作的新记录。 您指定可用空间的百分比，因此直到下一个索引维护操作时，再次重置的填充因子的页会更稳定的完整。 该技巧就是选择最小化页面分割索引维护操作之间的一个百分比。

为 OLTP （联机事务处理） 数据库的除了要为每个索引在 trial 基于和错误选择的填充因子不容易应答。 对于索引不更改其中的数据仓库的填充因子应该是 100%（意味着没有可用空间处于页）。 是非常罕见默认填充因子，数据库将更改从默认的 100%，最好的填充因素，对于不同的索引是通常不同。 SQL Server 2008 联机联机主题" 填充因子"具有对此的更多信息。

一种其他的方法是更改索引，以便不会产生页面分割。 这可能涉及更改索引键，以便插入不随机 （对于是实例下不使用随机 GUID 主键），或禁用更改可变长度列的大小的操作。

Q我们将移动到 SQL Server 2008 一旦 SP 1 推出，而我们正向查找使用功能之一是 FILESTREAM，因为删除列的值 2 GB 大小限制。 我们设计我们的架构的下一版本的启动使用 FILESTREAM 数据类型有任何的缺陷或我们应注意的问题之前，可能导致在生产中的问题？

A始终是之前设计一个新的架构或应用程序尤其是指利用 outside of 本身，SQL Server 的技术，是与 FILESTREAM 确定一项新功能的所有特征智能的主意。 我为名为 SQL Server 团队编写的白皮书中包含的大部分信息需要" FILESTREAM SQL Server 2008 中的存储." 我强烈建议您阅读该白皮书有关一个完整的讨论，但我将汇总此处的问题的主要方面。

首先，FILESTREAM 数据存储在 NTFS 文件-系统，而不是 SQL Server 数据文件中。 有必须采取以确保 NTFS 执行用于非常大量文件 （如与关闭 8.3 的名称生成一个单个目录中设置 NTFS 的各种配置步骤适当，群集大小，可能将该 FILESTREAM 数据到上的分开物理磁盘其他数据。

第二个，应确保的存储使用 FILESTREAM 数据的平均大小为 1MB 或更高版本。 研究已显示的数据大小小于 256KB 的并且有时 256 KB 到 1 MB，之间更好的性能可以获得由存储直接内 SQL Server 数据而不是使用如 FILESTREAM 机制。

第三个，应考虑将会对 FILESTREAM 数据执行的操作。 部分更新不支持 FILESTREAM 数据因此甚至更新 200MB 数据值的一个字节会导致创建一个全新 200MB 值。 除了在一个开销很大的操作，这可以导致从而进一步减少性能的 NTFS 级别碎片。 如果部分的更新可在应用程序中的 commonplace，某种批处理机制可能需要以避免重复的更新单个 FILESTREAM 值。

上次，应考虑跨功能兼容性的 FILESTREAM 与高可用性技术。 FILESTREAM 完全支持备份和还原操作 （包括时间点恢复）、 日志传送和复制。 不，但是，与数据库镜像 SQL Server 2008 中的任何方式兼容。 （我已经被告诉 SQL Server 的下一个版本中将修复此)。

这是只是一个喜欢要考虑的事项。 将完整的图片应阅读此白皮书。 与任何新的功能但，设计它，应用程序之前一定要执行一些广泛测试以查看它的功能是否符合您的要求。 考虑 FILESTREAM 还包括 NTFS 存储，我还想执行试制的性能，灾难恢复测试以确保该无 Trips 您设置时就 Live。

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.