维护SQLSERVER数据库的关功键技巧.docxVIP

概览：管理数据和事务日志文件清除索引碎片确保统计数据准确、最新检测遭到破坏的数据库页建立有效的备份策略??目录数据和日志文件管理?索引碎片?统计数据?损坏检测?备份?总结?在一周之内多次有人向我征求高效维护生产数据库的建议。有时问题来自 DBA，他们正在实施新的解决方案，希望得到帮助对维护进行精细调整适合其新数据库的特点。但更为常见的情况是：提问的人不是专业 DBA，而是由于某种原因拥有数据库并承担相关责任的人员。我喜欢将这种角色称为“非自愿 DBA”。本文重点是为所有非自愿 DBA 提供数据库维护最佳实践的入门知识。在 IT 世界里，大多数任务和程序都没有一个简单、通用的解决方案可以高效维护数据库，但却有一些必须受到重视的关键领域。我所关心的五大重要领域是（没有任何特殊的重要性顺序）：数据和日志文件管理索引碎片统计数据损坏检测备份一个未经维护（或维护不良）的数据库可能会在其中的一个或多个领域内引发问题，最终可能导致应用程序性能欠佳，甚至是停机以及丢失数据。在本文中，我将说明这些问题很重要的原因并向您展示一些缓解这些问题的简单方法。我将以 SQL Server??2005 为基础进行说明，但我还会着重指出您将会在 SQL Server 2000 和即将发布的 SQL Server 2008 中发现的主要差别。数据和日志文件管理我始终建议在接管数据库时检查的第一个领域涉及到与数据和（事务）日志文件管理相关的设置。具体地说，您应确保：数据和日志文件彼此分开，而且还与其他所有内容相互隔离自动增长已正确配置即时文件初始化已配置自动缩减未启用而且缩减不是任何维护计划的内容当数据和日志文件（理想情况下应分别位于不同的卷中）与其他任何创建或扩展文件的应用程序共享一个卷时，可能存在文件碎片。在数据文件中，过多的文件碎片可能是导致查询（特别是扫描非常多数据的查询）效果不佳的一个因素。在日志文件中，它可能会对性能产生相当大的影响，尤其是在自动增长设置为需要增加每个文件的大小时，增量很小的情形。日志文件在内部被划分为多个称为“虚拟日志文件”(VLF) 的片段，而且日志文件（我在这里使用单数是因为拥有多个日志文件并没有任何好处，每个数据库只应有一个日志文件）内的碎片越多，VLF 就越多。一个日志文件具有多个（比方说，200 个）VLF 后，与日志有关的操作（如为事务性复制/回滚而读取日志）、日志备份乃至 SQL Server 2000 中的触发器（触发器的实现已在 SQL Server 2005 中更改为行版本框架，而不是事务日志）可能会对性能产生负面影响。调整数据和日志文件大小的最佳做法是创建它们时使用适当的初始大小。对于数据文件，初始大小应考虑短期内向数据库中添加其他数据的可能性。例如，如果数据的初始大小为 50GB，但您知道在接下来的六个月内将再添加 50GB 的数据，那么应创建 100GB 的数据文件，而不是多次将其增大以达到该大小。对于日志文件而言要更复杂一些，您需要多考虑一些因素，例如事务大小（长时间运行事务在完成之前无法从日志中清除）以及日志备份频率（因为这将删除日志的非活动部分）。有关详细信息，请参阅我的妻子 Kimberly Tripp 编写的一篇很受欢迎的博客文章提高事务日志吞吐量的 8 个步骤，它发表在 SQL 上。设置一旦完成，应不时监视文件大小，并在每一天的适当时间先行手动增加其大小。为以防万一，应保留自动增长，这样文件即使在发生一些异常事件的情况下仍可以完成所需的增长。反对将文件管理完全保留为自动增长的逻辑是步长极小的自动增长会导致文件碎片，而且自动增长会是一个耗时的过程，它可能会多次突然停止应用程序的工作。应将自动增长大小设置为一个具体值，而不是一个百分比，以约束执行自动增长（如果发生）所需的时间和空间。例如，您可能希望将一个 100GB 的数据文件的自动增长大小设置为固定值 5GB，而不是（比方说）10%。这意味着无论文件每次变得多大，它均将按 5GB 进行增长，而不是一个持续增长的数量（10GB、11GB、12GB 等）。当事务日志增长时（手动或自动增长），它将始终被初始化为零。数据文件在 SQL Server 2000 中具有同一默认行为，但从 SQL Server 2005 开始，您可以启用即时文件初始化，它会跳过零初始化文件，因此增长和自动增长会保持同步。所有版本的 SQL Server 中都提供了这一功能，这一点与正常的观点恰恰相佐。如欲了解详细信息，请在 SQL Server 2005 或 SQL Server 2008 的联机丛书索引中输入“即时文件初始化”。最后，应注意不要以任何方式启用缩减。缩减可用于减小数据或日志文件的大小，但它是一个干扰很大、极耗资源的过程，会导致数据文件中产生大量的逻辑扫描碎片（