我有现有的oracle数据库。我想把它放在源代码控制下(Subversion)。 我知道的唯一解决方案 - 创建'DROP / CREATE / INSERT'文本脚本并将它们存储到SVN。
可能有更好的方法来管理架构和数据吗?我正在使用Oracle SQL Developer,我已经看到了迁移/存储库管理功能。我应该使用它们吗?以及如何使用它们?
答案 0 :(得分:5)
免责声明:我为Red Gate工作
Oracle的源代码管理可以将您现有的架构链接到Subversion(仅限Windows): http://www.red-gate.com/source-control-for-oracle/
这允许您签入CREATE文件的基线,以及向前移动的任何更改。它还允许您将源控件中的更改应用于模式,将更改作为ALTER语句处理,从而在修改表时保留数据。这也允许您为每个开发人员创建私有/专用模式,从而创建一个沙盒环境(如果您在团队中工作)。
我们目前不支持将静态/参考数据添加到源代码管理中,但我们计划。
答案 1 :(得分:3)
我不确定我是否真的在这里回答你的问题,或者只是随意喷出一些东西:)
首先,我想首先说我非常反对将数据放入源代码管理中 - 您的数据库是您维护数据的地方。我使用SCM来跟踪对象更改以及DB中的归档策略以跟踪数据更改。
我没有使用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脚本。这使我们可以独立跟踪每个更改,并使用我们的回滚逻辑恢复到特定的构建。
答案 2 :(得分:1)
我希望当您需要将更改从Subversion存储库传递到Oracle数据库时,我的命令行工具非常有用。请试一试:www.dbapply.com。
它适用于Windows和Linux。一般来说,我这样使用它:
dbapply --paths <local svn repository> <local SVN repository> ... --database <database connection string>
示例:
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);
使用这种类型的注释,您可以为脚本添加“rerunability”。如果出现问题并且上面的示例中的表已经存在,DbApply将忽略“ORA-00955”错误并继续使用其他脚本。
此工具的先前版本在一家公司中运行了好几年。也许你也可能觉得它很有用。任何反馈都将不胜感激。
谢谢!
答案 3 :(得分:1)
查看oracle-ddl2svn - 用于在SVN中自动存储oracle DDL架构的工具集。