PostgreSQL 中是否有任何 DBCC（数据库一致性检查器）命令？我可以找到 SQL 服务器 DBCC 命令，但不能找到 Postgres？我读到 postgresql 具有内置的性能调整功能，并且没有可用于 postgres 的 DBCC 命令。这是真的吗？
Cra*_*ger 13
PostgreSQL 中没有内置的一致性检查命令或工具。
一般的观点是，应该没有必要，因为在高质量的硬件/软件堆栈上应该不可能出现损坏和不一致的情况。如果确实出现问题，则无法保证任何类型的一致性检查都会找到它们，因此只会产生一种虚假的安全感。我不同意这种观点，但是当 pgsql-hackers 定期讨论这个问题时，似乎就会出现这种情况。
像往常一样，潜在的问题是没有人特别需要一致性检查工具来满足他们的直接需求，所以没有人花时间编写一个来解决问题，也没有人根据商业合同或内部基础为开发提供资金。志愿服务？:p
PostgreSQL（直到 9.3）不支持块级校验和。因此，您用于验证的主要内容之一不存在，因此无法验证。PostgreSQL 9.3 中不存在扫描所有关系和验证校验和的工具，但希望添加并可能出现在未来版本中。与此同时，您所能做的就是SELECT *单独从每个关系中获取 - 但由于 PostgreSQL 使用操作系统缓冲区缓存进行读取，因此无法保证实际上会强制读取底层磁盘块。需要一个新工具来做到这一点。
PostgreSQL 倾向于在可能的情况下避免冗余存储信息，因此通常没有什么可检查的，只有一个权威来源。除非出现相同的信息，或者可以从多个不同的地方得到相同的信息，否则一致性检查器无能为力。
在仍然忙碌且活动的数据库上同时进行任何类型的有用检查也非常困难。大多数安装都不愿意锁定整个数据库，或至少一次锁定几个主要关系，以运行某种一致性检查。因此，检查器需要能够对受并发修改影响的数据库进行操作，这使得编写更加困难，并且能够可靠地检测到更少的问题。
如果编写了一个验证器工具，它仍然可以做很多事情，特别是如果它被允许采用多个关系排他锁：
检查磁盘上是否存在所有表空间。
检查每个pg_class条目是否relfilenode在正确的表空间中具有与其对应的文件。
检查可见性地图、自由空间地图等，确保它们在应有的时候出现、可读，并且看起来与它们关联的关系相匹配。
报告孤立的磁盘文件节点。（由于事务性 DDL 和延迟取消链接，这些是正常的，但检查器可以在运行检查之前强制紧急取消链接并锁定所有关系）。
阅读每个关系的每个块并寻找明显的问题。对于类似于以下内容的堆关系：
xmin大于xmax（考虑XID环绕后）_in和_out功能不变或抛出错误的数据NULL在NOT NULL表属性上设置的位图字段CHECK约束失败锁定所有涉及的表后重新检查外键和排除约束
... 可能还有更多我对 Pg 的胆量不够了解，例如尝试检测撕裂的页面、b 树结构验证、健全性检查 GIN 和 GiST 索引、健全性检查pg_control，以及更多我不会知道从哪里开始。
如果你渴望拥有这样一个工具，最好的办法就是学习足够的知识来提出一个关于它应该如何工作的具体建议 - 并腾出时间来研究它，或者资助其他人花时间在它上面发展。
就我个人而言，我真的很高兴有一些东西可以使用postgres后端的特殊启动模式检查已停止的数据库集群，因此我可以（在某种程度上）验证使用pg_basebackup, with pg_start_backup(), rsync 和pg_stop_backup, 使用文件系统级别获取的物理数据库副本原子快照等
或者，您可以做大多数其他人会做的事情：确保您的硬件和软件堆栈健壮且配置正确，保持良好的备份，并监控您的日志。在调试服务器之前对整个堆栈进行适当的测试是无可替代的 - 以及良好的备份，包括物理（流/PITR）和逻辑（转储）。在上线之前对加载的数据库进行即插即用测试 - 重复 - 以确保您所谓的可靠 I/O 子系统确实如此。使用多种形式的备份。
pgFoundry上有一个名为 pgCheck 的项目。请注意，开发状态是“Alpha”。
我看起来最后一次活动是在 2012 年初。
已经在其他地方提出了
大多数人使用数据库范围的真空吸尘器或从每个表中选择 * 的组合；IE。尝试以某种方式扫描/处理每一行