您如何对 Oracle 数据库更改进行版本控制？

在我工作过的站点上，需要对生产实例进行的任何更改都必须编写为将在 SQL*Plus 中运行的更改脚本；此外，从头开始重新创建所有模式对象所需的脚本必须保持最新。所有这些脚本都被签入变更控制，并从那里迁移。

您可以审计 DDL 更改或使用 DDL 触发器来获取更改，甚至使用 diff 软件比较两个实例，但这些方法是不分青红皂白的；开发人员通常会在确定需要更改的内容之前对模式进行一些更改（例如，很少的测试更改、创建虚拟表以测试概念等）。

我已经思考并阅读了很多关于这个主题的内容。这是配置控制和变更管理策略的广泛主题。CMMI 在这个主题中有一个域。即使在获得 CMMI 3-5 认证的公司中，他们有时也不对其数据库进行版本控制。

应在牢记以下约束的同时回答这个问题。

1. 你有一个 keeper，每个 DDL 都由这个 keeper 执行。
2. 其他人有能力执行 DDL 语句。
3. 您只需要记录所做的更改，而不需要比较巨大的差异。
4. 您的数据库设计是通过外部工具完成的，然后发布到数据库。这个外部工具甚至可以是源代码管理中的 DDL 脚本。但关键是你的源代码控制然后发布到数据库。
5. 您不需要知道瞬时变化，而是不时知道：即每小时、每天。
6. 您有一个已定义的服务器结构：开发、测试、生产。和一个很好的测试策略。

答案 1

• 如果 1 ,4,6 为真，那么您可以使用外部源代码控制。例如
  • Embercadero 有一个数据库变更管理工具 ( http://www.embarcadero.com/products/db-change-manager-xe )。它具有对数据库（Oracle）进行逆向工程并将其置于源代码控制中的能力。然后任何数量的开发人员，dba 都可以访问此架构并对其进行更改。
  • Oracle SQL Designer 与此方法类似。
  • 让您创建表脚本到源代码控制（svn、mercurial 等）并维护它们也是同样的事情。
  • http://www.liquibase.org是上述的自动化方法。
  • 我编写了生成 DAL（数据访问层）、DDL（创建表）语句的代码生成器。我们将它们放在源代码控制并在那里维护。我认为像 liquibase 这样的专用解决方案可能会更好。

如果有 6 个，这种方法效果很好。您将 DDL 语句（也是代码）放在源代码管理中并维护它。没有人会在没有适当考虑的情况下更改测试和生产服务器。

缺点是如果您出于任何原因对生产或测试服务器进行任何更改，快速修复错误，更改主键等。您还需要将该更改滚动到开发服务器。因为实际上开发服务器是您的基本事实。没有别的办法。

这是一种非常面向开发人员的方法。但是当你第一次开发一个新模块时，它工作得很好。

答案 2 - 如果 1 和 6 为真：

答案 1 的类似方法是维护开发服务器。每个人使用它都会改变它。比到时候更新了。您使用数据库比较工具。将这些作为脚本获取，并将其置于源代码管理之下。

- Red Gate Schema Compare supports Oracle
- Embercadero has similar tool
- https://github.com/carbonfive/db-migration
- http://www.sumsoftsolutions.com/svco/ (I have not used this product but I believe it belongs to this category.)
- Rails Active Migration (http://www.oracle.com/technetwork/articles/kern-rails-migrations-100756.html)

答案 1 和答案 2 之间的区别在于，在答案 1 中，您收集整个数据库的 DDL 语句并存储它们。在答案 2 中，您需要存储每个版本的更改。

1. 开始
2. V1
3. V2
4. V3
5. ...

如果您将一列放入表中，然后决定将其删除。您的脚本将在 answer2 中显示此内容，而在 answer1 中您只会看到最新版本。您需要比较 V2 和 V1 才能看到差异。我个人更喜欢答案 1，因为我可以轻松比较 Start 和 V3、V1 和 V3。在 answer2 中，我需要查找所有更改。同样在源代码控制中的答案 2 脚本往往是一个大爆炸，复杂的脚本。很难找到信息。

答案 3 如果 3 为真。请注意，在这种情况下，您没有约束 6，即：您没有开发、测试、产品服务器。只有生产服务器。您可以使用 DDL 触发器来记录所做的更改。这主要用于阻止人们滥用他们的 DDL 赠款。如果出现任何问题，您可以追究责任。为此，每个人都应该连接他们的用户帐户，并且应用程序帐户不应该有任何 DDL 授权。由于每个开发人员都知道应用程序帐户并且可以使用它。

回答 4 如果您有 3 和 5。请注意，在这种情况下，您没有约束 6，即：您没有开发、测试、产品服务器。只有生产服务器。而不是触发器来存储更改。您使用外部工具查找更改并将 DDL 脚本存储在源代码管理中。

如果这些工具能够记录谁进行了更改，那将很有用。请注意，在此解决方案中，您会丢失间隔完成的额外 DDL。

刚刚发现了一个关于使用Liquibase对 Oracle 进行版本控制的有趣教程。

在我们的一些数据库中，我们使用 DDL 触发器来捕获更改并将它们保存到表中。然后，我们有一个 Web 界面来提取这些以前的版本。它有严重的缺点，这就是我寻找替代品的原因，但它很容易并且比没有版本控制要好。

我们在 11g 数据库中使用了模式版本控制，但在 11.2 上的软件出现了一些问题。如果不是因为我们仍在努力解决的那些问题，这将是一个很棒的产品。

我们曾经使用 Oracle SQL Designer，现在（我猜）它已经被 SQL Developer Data Modeler 取代了。http://www.oracle.com/technetwork/developer-tools/datamodeler/overview/index.html

那很好，尤其是。能够为列设置 DOMAIN 并节省大量创建公共列（mtime、ctime 等）的时间。

我们使用oracle-ddl2svn工具集（我是其作者）在 SVN 中自动存储 oracle DDL 模式。

我从未使用过它，但http://blog.gitora.com/是另一种选择。

看看 DBmaestro TeamWork，它的数据库实施了变更管理方法。

_{披露：我为 dbMaestro 工作}