升级或迁移后是不是有一种好方法可以验证数据库架构是不是正确？

Posted 2023-03-14

【中文标题】升级或迁移后是不是有一种好方法可以验证数据库架构是不是正确？

【英文标题】：Is there a good way to verify if a database schema is correct after an upgrade or migration?升级或迁移后是否有一种好方法可以验证数据库架构是否正确？

【发布时间】：2011-04-04 08:07:10

【问题描述】：

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

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

更新

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

【参考方案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 进行哈希/校验和（之前保存/之后比较），但计算成本与比较两个表的索引并没有太大区别。

【讨论】：

+1 为简单起见，尽管它不会捕获缺失的约束。

好点 - 当然任何 sys 生成的名称（如约束）都可以更改。您必须对 ALL_CONSTRAINTS 中的约束内容（不是名称）进行类似的匹配。

有趣的解决方案。我不知道这件事。缺少约束是我们开始研究这个问题的原因，所以我也必须研究匹配的约束内容。感谢您的提示！

【参考方案2】：

我不会编写检查脚本，我会编写一个程序来从特定版本的数据库生成检查脚本。只需检查元数据并记录那里的内容并将其写入文件，然后将该文件中的值与客户数据库中的值进行比较。如果您对约束使用系统生成的名称，这将不会那么好用，但只需验证事物是否存在就足够了。迁移数据库时删除索引和约束是很常见的，因此您甚至可能不需要检查太多；如果缺少两三件事，那么假设它们都缺少是合理的。您可能还想编写一个脚本来删除所有约束和索引并重新创建它们，并让您的客户将其作为迁移后的步骤运行。只需确保按名称删除所有内容，以免删除客户可能创建的任何自定义索引。

【参考方案3】：

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

希望对你有帮助。

SQL Developer - download

罗尼。

【讨论】：

我们可以建议客户的 DBA 将其拉起，但我们希望有一个命令行实用程序，它可以提供布尔响应，我们可以将其嵌入到脚本中。

【参考方案4】：

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

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