Oracle：将现有数据库置于版本控制中答案

【问题标题】：Oracle: put existing db to version controlOracle：将现有数据库置于版本控制中
【发布时间】：2012-08-10 19:18:39
【问题描述】：

我有现有的 oracle 数据库。我想把它放在源代码控制（Subversion）之下。我知道的唯一解决方案 - 创建“DROP/CREATE/INSERT”文本脚本并将它们存储到 SVN。

是否有更好的方法来管理架构和数据？我正在使用 Oracle SQL Developer，我已经看到了迁移/存储库管理功能。我应该使用它们吗？以及如何使用它们？

【问题讨论】：

是的，您需要使用 SQL Developer 中的Versioning 功能。另外，我建议使用 SVN 仅控制自定义的源代码（由开发团队）。
查看我最初在 SO [这里][1] 上发布的 cmets，希望对 [1] 有帮助：stackoverflow.com/questions/9195170/…
我无法将 sql developer 连接到 subversion。这看起来像错误，因为所有其他 svn 客户端都在工作。

标签： oracle svn version-control oracle-sqldeveloper

【解决方案1】：

免责声明：我为红门工作

Source Control for Oracle 可以将您现有的模式链接到 Subversion（仅限 Windows）： http://www.red-gate.com/source-control-for-oracle/

这允许您签入 CREATE 文件的基线，以及对这些文件的任何更改。它还允许您将更改从源代码控制应用到您的模式，将更改作为 ALTER 语句处理，从而在修改表时保留数据。这还允许您为每个开发人员创建私有/专用架构，从而创建沙盒环境（如果您在团队中工作）。

我们目前不支持将您的静态/参考数据添加到源代码管理，但我们计划这样做。

【讨论】：

【解决方案2】：

我不确定我是真的在这里回答你的问题，还是只是随意吐槽:)

首先，我想说的是，我非常反对将数据放入源代码控制中 - 您的数据库是您维护数据的地方。我使用 SCM 来跟踪对象更改，并使用数据库中的存档策略来跟踪数据更改。

我没有使用 SQL Developer 的版本控制，主要是因为我们将部署与我们的 Jenkins CI 服务器集成在一起，所以它可能完全满足您的需求。

需要一个基本结构来组织您的代码，我认为这应该尽可能接近您的实际数据库。

<database>
    |_____<schema>
    |         |____<DDL>
    |         |____<DML>
    |         |____<PLSQL>
    |         |____<Indexes>
    |         |____<Constraints>
    |____<schema>
    ...

上面模拟了 Oracle 中的命名空间边界。 PLSQL 和 DDL 对象确实共享相同的命名空间，但由于 PLSQL 具有业务逻辑，我将它们分开。

我使用 OBJECTNAME.TYPEEXTENSION 的命名架构托管这些文件夹中的所有对象，并使用（或多或少）标准化的文件扩展名：

Table           .tbl
Package Spec    .pks
Package Body    .pkb
Trigger         .trg
View            .vw
...

我找到的这些脚本的内容取决于您的部署工具和对象类型。

您能否在文件对象之间创建依赖关系，或者知道要运行什么？
它可以处理可重运行性还是您需要将其构建到您的脚本中？
工具能否回滚到以前的版本？

考虑到这一点，您可以确定这些文件中需要具备的结构。

我们的工具目前无法处理可重运行性，即我们没有 CREATE OR REPLACE 对象或用户定义对象之间存在紧密耦合的依赖关系。

为此，我们必须编写一个 PLSQL 块来检查系统表，例如，查看是否添加了索引，如果添加了索引，则会引发异常，该工具会捕获并知道丢弃该异常并继续下一个脚本。

我只希望在持续集成期间应用数据库中的增量，因此我们不使用 DROP/CREATE/INSERT 脚本。这使我们能够独立跟踪每个更改，并使用我们的回滚逻辑恢复到特定的构建。

【讨论】：

关于数据 - 我同意你的观点，数据不应该存储在数据库中。但是 测试数据 很可能存在于各种版本的模式中。这将使我们能够重现特定于 db 的错误等。作为部署工具，我有 maven。
嗯，我们即时生成测试数据，一旦运行测试，它就会被删除，所以我认为这就是为什么不必处理这个问题 - 在布局中添加了一个 DML 文件夹以适应这个
自动化是如何工作的？您是否有一份工作只运行添加到这些文件夹中的任何脚本？
我们有一组 Jenkins CI 作业被配置为在签入发生时触发，然后 jenkins 作业将运行一个脚本来遍历所有新文件

【解决方案3】：

我希望当您需要将更改从 Subversion 存储库传送到 Oracle 数据库时，我的命令行工具会很有用。请试一试：www.dbapply.com.

它适用于 Windows 和 Linux。一般来说，我是这样使用它的：

dbapply --paths  ... --database

例子：

dbapply --paths /space/svn/oracle/scripts --database scott/tiger@localhost/orcl

DbApply 分析所有脚本，对它们进行排序（以避免依赖错误）并执行。

它还在数据库模式中创建了几个表来跟踪应用脚本的修订。每次运行 DbApply 时，它都会比较修订并仅应用更改的脚本。

此外，您所有来自 SVN 存储库的脚本都可以导出到批处理或 shell 命令文件中。此命令文件仅适用于 SQL*Plus，并且可以在未安装 DbApply 的服务器上执行。

最后，您可以指定 SQL 命令可以忽略的错误列表：

/* ignore_error(955) */ CREATE TABLE a (n NUMBER);

使用这种类型的注释，您可以为您的脚本添加“可重新运行性”。如果出现问题并且上面示例中的表已经存在，DbApply 将忽略“ORA-00955”错误并继续使用其他脚本。

该工具的先前版本在一家公司中运行了好几年。可能您也会发现它很有用。任何反馈将不胜感激。

谢谢！

【讨论】：

【解决方案4】：

查看oracle-ddl2svn - 用于在 SVN 中自动存储 oracle DDL 模式的工具集。

【讨论】：