在oracle中部署plsql包

我希望了解部署大量plsql包的可能方法，因为依赖关系似乎是一个相当大的问题。 正如它现在所工作的那样，如果由于缺少依赖关系而无法在前一阶段部署包，那么包将在多次迭代中重新部署em。 我希望听到不同的方法来解决这个问题，如果你有问题要问我，我会更新我的问题，让它更清楚

---

这样搜索指南可以吗？

我建议先按正确的顺序安装所有规范。 然后安装所有阀体。 所有依赖项都需要在主安装脚本中预定义一次

更新： 您还可以做的是：

1） 将所有包装规格加载到主列表中（我假设所有规格和主体都是单独存储的。如果不是，则需要这样做）

2） 循环主列表中的所有规格

3） 试着编译它。如果失败，则添加到失败列表

4） 到达主列表末尾时，用失败列表中的项目替换主列表中的所有项目

5） 转至步骤2

同时，您可以保存第一次运行的结果，第二次运行可以根据上一次调用的结果订购项目。这将最小化迭代次数

车身可以按任何顺序安装

---

但是，您需要记住对视图和视图的依赖关系-规范可能依赖于视图（视图名称%TYPE、游标等），而视图依赖于包规范（可以调用包函数）。这不是一个微不足道的问题。。。你能解释一下目前是如何解决的吗？

我自己只是安装了所有的过程代码（以任何顺序），然后（重新）编译所有无效的对象

有几种方法可以重新编译所有无效对象：

---

谢谢您的回复。我们观察到了这种方法，但是有数千个包，并且它们经常由于正在进行的重构而改变，因此维护主脚本需要太多的时间/精力。这是糟糕设计的结果-您需要分离日志记录、动态sql执行、表管理、错误处理和其他实用程序的核心包。下一层是底层业务逻辑。然后是高级业务逻辑—为来自Oracle外部、来自其他应用程序等的调用打包。您可以自动定义它一次，然后维护它。即使是上千个软件包，您也不会在每个版本中更改所有软件包的依赖关系。很多事情都会在一天内发生变化，因为它的100+ppl正在处理这些软件包，从重命名到重写、重组等等。这里有很多地方可以改进，这个问题是改进工作的一部分。不能一蹴而就，最后期限就是最后期限。是的，我同意。我的评论伴随着建议的方法。让我更新一下我的答案……这就是它现在的基本工作方式，尝试展开并循环直到完成，但是一些规范使用force方法进行部署，而不管其依赖性如何，这会使依赖于此方法的所有对象无效。下一次部署迭代将不会重新部署这些包，因为它们已成功部署并从列表中删除？如果您有“许多”包，那么您必须在代码库中有其他一些“结构”-规程，比如：这25个包属于子系统FOO，这13个包属于子系统BAR，不是吗？也许子系统也有不同的模式？是否允许包使用任何其他包？您是否实现了单独的公共和私有包API？需要哪些其他数据库对象（表、对象类型、序列、视图）？版本控制系统中是否有源代码？@user272735是的，有几个分支涵盖所有测试级别，还有数千个包、数十个模式，包使用其他包，因为有一些常见的东西，所有在甲骨文中可以想象到的东西，包括你提到的那些，你比我大，所以我的做法对你没有帮助。我非常能够为每个生产部署从版本控制系统收集一系列已更改的脚本（PL/SQL代码、alter table语句等）到文本文件，并在没有任何依赖性问题的情况下半自动执行这些脚本（sqlplus）。您能简要解释一下您是如何通过源代码管理解决依赖性问题的吗？我们使用svn。