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

概览： 管理数据和事务日志文件 清除索引碎片 确保统计数据准确、最新 检测遭到破坏的数据库页 建立有效的备份策略 ??目录 HYPERLINK /link.php?url=%2Fzh-cn%2Fmagazine%2F2008.08.database.aspx%23id0230012 \t _blank 数据和日志文件管理? HYPERLINK /link.php?url=%2Fzh-cn%2Fmagazine%2F2008.08.database.aspx%23id0230032 \t _blank 索引碎片? HYPERLINK /link.php?url=%2Fzh-cn%2Fmagazine%2F2008.08.database.aspx%23id0230050 \t _blank 统计数据? HYPERLINK /link.php?url=%2Fzh-cn%2Fmagazine%2F2008.08.database.aspx%23id0230062 \t _blank 损坏检测? HYPERLINK /link.php?url=%2Fzh-cn%2Fmagazine%2F2008.08.database.aspx%23id0230078 \t _blank 备份? HYPERLINK /link.php?url=%2Fzh-cn%2Fmagazine%2F2008.08.database.aspx%23id0230086 \t _blank 总结? 在一周之内多次有人向我征求高效维护生产数据库的建议。有时问题来自 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 编写的一篇很受欢迎的博客文章 HYPERLINK /link.php?url=%2Fblogs%2Fkimberly%2F2005%2F06%2F25%2F8Ste