升级或迁移数据库后，有没有一种好的方法来验证数据库架构是否正确？

Question

我们有一些客户正在从一个数据库版本升级到另一个版本（具体来说是从Oracle 9i到Oracle 10g或11g）。在一个案例中，客户将旧的数据库导出并导入到新的数据库中，但由于某些原因，索引和约束没有被创建。他们可能为了加快导入进程而故意这样做，但我们仍在调查原因。

真正的问题是，我们是否有一种简单的方法来验证导入后数据库的结构是否完整？是否有某种校验和可以用于结构？我们意识到我们可以执行一系列查询来查看所有表、索引、别名、视图、序列等是否存在，但这可能很难编写和维护。

更新

感谢提供商业和/或GUI工具使用的答案，但我们确实需要一些免费的东西，可以打包到我们的产品中。它还必须是命令行或脚本驱动的，以便我们的客户可以在任何环境（Unix、Linux、Windows）中运行它。

- Javid Jamae

Answer 1

假设有一个单一的模式，类似于这样 - 在迁移之前将USER_OBJECTS转储到一个表中。

 CREATE TABLE SAVED_USER_OBJECTS AS SELECT * FROM USER_OBJECTS

然后在迁移后进行验证。

 SELECT object_type, object_name FROM SAVED_USER_OBJECTS
 MINUS
 SELECT object_type, object_name FROM USER_OBJECTS

一个问题是，如果你在版本之间有意删除了对象，那么你也需要从SAVED_USER_OBJECTS中删除它们。而且，如果存在错误版本的对象，这种方法也无法检测出来。

如果你有多个模式，则需要为每个模式执行相同的操作，或者使用ALL_OBJECTS并提取/比较相关用户模式。

你也可以对整个模式的object_type||object_name进行哈希/校验和（保存前/比较后），但计算成本与在索引上比较两个表的成本并没有太大的区别。

- JulesLt

---

+1 表示简单，但它并不能捕捉缺失的约束条件。 - DCookie

好的观点 - 当然，任何系统生成的名称（如约束）都可能会更改。您必须执行类似的操作，匹配ALL_CONSTRAINTS中约束内容（而不是名称）。 - JulesLt

有趣的解决方案。我不知道这个。缺少约束条件是我们开始研究这个问题的原因，所以我也要研究匹配约束内容。谢谢你的提示！ - Javid Jamae

Answer 2

如果你愿意花一些钱，DBDiff是一个高效的实用程序，可以完全满足你的需求。

http://www.dkgas.com/oradbdiff.htm

- Eton B.

Answer 3

在SQL DEVELOPER（免费的Oracle实用程序）中，有一个数据库模式差异功能。值得一试。

希望它能帮到你。 SQL Developer - 下载 Roni.

- Roni Vered

---

我们可以建议我们客户的数据库管理员查看此内容，但我们希望有一个命令行实用程序，可以提供布尔响应，并将其嵌入脚本中。 - Javid Jamae

Answer 4

我不会写检查脚本，我会编写一个程序从特定版本的数据库生成检查脚本。只需浏览元数据并记录其中的内容，然后将其写入文件，再将该文件中的值与客户数据库中的值进行比较即可。如果您为约束条件使用系统生成的名称，则此方法可能效果不佳，但仅验证是否存在相当充分。在迁移数据库时，删除索引和约束是非常常见的，因此您可能甚至不需要过多检查；如果缺少两三个东西，则假设它们都不存在是合理的。您还可以编写一个脚本来删除所有约束和索引并重新创建它们，然后让您的客户将其作为迁移后步骤运行。只需确保按名称删除所有内容，以便不会删除客户可能已创建的任何自定义索引。

- TMN