问题：DBCC CHECKDB 会全面检查数据库中的所有内容吗?有人说不会。另外，修复系统能修复所有问题吗?同样有人说不能。如果 DBCC CHECKDB 的检查和修复并不全面，我该怎么做?
解答：该工具的检查和修复可以说是全面的，也可以说是不全面的!DBCC CHECKDB 可提供一组全面的一致性检查，而随着其版本的不断更新，其检查功能还在不断增强。不过，也有一些方面是该工具无法检查的。
简单来说，该工具可以：
·检查系统目录的一致性
·检查分配元数据的一致性
·检查所有用户表的一致性
本解答不提供有关运行哪些检查的更详细的说明(您可以访问我的博客或阅读最近的 SQL Server 2008 Internals 一书了解详情)，但所用的每个数据库页至少会被读入内存并验证。这样可以找出由 I/O 子系统中的错误导致的常见损坏(约 99.99% 的损坏都是这样产生的)。
在任何版本的 SQL Server 中都不会被检查的两个最常见的项目是，存储在数据库中的列内容和索引键值统计信息，不过，在今后的版本中，我们可能会添加对这两个项目和约束有效性(举例来说，表格之间的外键约束)的检查。约束有效性可单独使用 DBCC CHECKDB 的 DBCC CHECKCONSTRAINTS 命令检查，实际上，如果您必须在包含约束的数据库中运行修复操作，则建议您以后再验证约束的有效性，这是因为修复操作不会考虑约束，并可能会意外使其无效。这些内容都可以在联机丛书中找到。
修复系统无法修复所有问题。在合理的时间内，此工具可能无法保证彻底修复某些错误。此类损坏很少，我的博客文章“CHECKDB From Every Angle:Can CHECKDB Repair Everything?”对此进行了说明，举例来说，如果在系统目录中有一个损坏的页面，则可采取的修复措施只能是删除此页面。不过，如果该页面存储了数据库中某些用户表的元数据，那该怎么办?删除该页面也就意味着删除这些用户表，因此不能进行修复。
大部分修复操作都会导致某些数据丢失(因为这是在合理的时间内保证正确修复损坏的唯一途径)，因此，在执行灾难恢复时，不到万不得已请勿使用修复操作。使用全面备份策略中的备份是避免丢失数据的唯一途径(除非维护了某些格式的同步副本)。
DBCC CHECKDB 功能非常全面，可以检测到破坏性损坏，为确保在第一时间发现损坏的内容，应将定期运行 DBCC CHECKDB 作为数据库维护策略的一部分(参见我的博客文章“Importance of Running Regular Consistency Checks”)。没有任何工具可以解决一切问题，不过，如果您确保针对所有数据库启用页面校验和，则可以使 DBCC CHECKDB 发挥更大的作用，同时可使 SQL Server 检测到在 SQL Server 内存之外更改数据库页的时间。
问题：我对压缩操作感到困惑。在我阅读过的相关文章中，关于压缩数据文件的操作是好还是坏，说法不一。我在查找有关压缩日志文件的相关信息时也遇到了这种问题。到底是怎么回事?
解答：压缩操作的确非常容易让人产生误解，而数据文件压缩和日志文件压缩之间的差异是导致这些误解的重要原因。
针对数据文件的压缩操作是为了将距离文件末尾最近的数据库页移到文件的开头部分。这样会导致数据文件的末尾部分产生“空白”区域，这些区域可以返还 OS。换句话说，数据文件从物理角度而言变小了。
另一方面，针对事务日志文件的压缩操作不会移动任何内容，只要事务日志记录没有因为任何原因被保留，该操作就只会删除文件末尾的事务日志的空白区域。如果操作成功，日志文件从物理角度而言会变小。
用户的困惑主要集中在这两种操作的副作用以及何时执行上。
用户有时会被建议(或自行决定)压缩数据文件以回收空间，这可能是因为其索引维护操作导致数据文件增大，或者其驱动器空间不足，面对这种情况，用户自然会想到回收这样的一些“被浪费”的空间。不过，数据文件可能会再次用到这些空间，因此，通常情况下，最好将剩余的空闲空间保留供数据文件使用，而不要重复地压缩文件并使文件自动增长。
压缩数据文件的副作用非常严重，因此应尽量避免使用此操作。压缩数据文件会导致大量索引碎片的产生，因此可能会影响查询的性能。我的博客文章“Why You Should Not Shrink Your Data Files”中提供了一段简单的脚本来说明这种情况。
我在这篇博客文章中还阐述了何时可以压缩数据文件(几乎没有合适的时间)以及可以避免产生碎片副作用的其他方法。遗憾的是，我见过许多未提及相关的副作用就推荐用户执行数据文件压缩的情况。
与压缩数据文件相比，压缩日志文件的操作更应该慎之又慎。通常情况下，由于用户采用的文件大小管理方法不当，导致日志文件过大且与数据文件大小相比极不均衡，因此用户希望压缩日志文件，或者是因为用户看到日志文件变大而希望将其控制在尽可能小的范围内。主动数据库的日志文件需要保持合理的大小，但应对日志进行管理，以保证无需对其进行压缩，并无需使其增大以应对数据库中的活动。
您可以阅读我为 2009 年 2 月那一期杂志撰写的文章“Understanding Logging and Recovery”了解有关事务日志的详情。我还写过一篇阐述如何管理事务日志大小的博客文章，请参阅“Importance of Proper Transaction Log Size Management”。
最低要求是尽可能少地进行任何形式的压缩操作，如果确定采取压缩操作，应确保完全理解其可能造成的后果。
