你好 正如
先前有关基于版本的重新定义的
文章中所承诺的
那样 -这是第二部分。
那么我们在做什么呢？ 我们的主要生产服务器是Oracle 12C企业版。 而且，需要注意的是，数十个应用程序正在同时运行。 我们为什么要专注于此？ 该技术是相对较新的技术，并非很好。 马上将一些关键系统转移给它是不合逻辑的。 因此，我们自己决定，我们将逐渐从不太重要的系统过渡到更重要的系统。 因此，我们需要了解的下一个问题：当拥有一个版本版本而另一个版本没有版本时，如何使用EBR技术以及如何组织集成。 事实证明，在Oracle版本12中，您可以在版本化方案中创建未版本化的对象，未版本化的程序包，未版本化的表示形式，以组织高度集成。
当然，我们可以创建未版本控制的API并将其提供给未版本控制的架构以供使用。 但是，如果此非版本API（或其一部分）在我们的应用程序内部使用，而我们需要在自己内部对其进行版本控制，并将非版本化对象放在一边，该怎么办？ 这只是我们面临的下一个问题。 我们多次使用API，但是，正如您所记得的，存在一个限制，即版本化对象不能非版本化使用。 自然，假设服务器上正在运行多个应用程序，则有必要了解我们如何将一个应用程序切换到新版本，并保持与其他数据库方案一起使用该方案的API的能力。
有几种安装Edition的选项：
- 将默认版值设置为整个数据库
- 重新在整个数据库上安装环境。
这些选项将立即被取消，因为至少某些应用程序不会切换为使用EBR。
当将应用程序连接到电路时，还可以创建一个服务来确定版本，或者确定版本。 如果我们通过某些第三方应用程序连接到数据库，这将很方便。
如果我们需要工作按计划运行并在某些特定版本上工作？ 相应地，还有另一个选项可以切换到新版本-这是
将当前会话定向到特定版本 。
实际上，我们自己选择了此解决方案。 您可以在登录后将触发器附加到版本控制方案，这将表明该方案中的当前会话将在此版本中起作用。
返回到逻辑的集成和重复。 有任务：我想在方案内部对某种应用程序逻辑进行版本控制，并且还需要将其设置为非版本用户。 最初似乎无法实现，但是，深入研究这个问题，我们发现通常的dbms_sql程序包可以帮助解决此问题，该程序包原则上旨在执行某种动态查询。 怎么了 非常简单-处理请求或调用任何匿名块时，我们可以将条件名称作为参数抛出，从而指示将在其中解析和执行此代码的版本。 如果我们需要在内部使用某些过程并将相同的过程提供给第三方方案，则只需在dbms_sql.parse过程中通过调用将其包装即可，从而创建可以放入非版本对象的包装器，并且-请使用我们的版本化对象非版本用户。
您在这里面对什么？ 由于某些原因，在指定条件时，过程中不会发出out参数。 为什么-尚不清楚，但是在我们工作过的那些方案中，这种方式并不经常使用。 也许我们会以某种方式重做逻辑，或者我们会寻找其他解决方案。
以下问题是我们遇到的EBR的错误或功能。 首先是构造类型和流水线函数的问题。 管道与它有什么关系？ 除了我们确实有某些基于流水线函数工作的算法这一事实外，Pipeline是一种将版本化视图放在一边的特定解决方案。 我们继承了视图，这些视图包含用于数据预处理的相当复杂的逻辑，并且第三方方案也使用这些视图。 因此，有必要了解如何将我们的版本控制视图设置为非版本数据用户电路，只要列的输出集不变。 作为这种解决方案，很明显，您可以在Pipeline函数中使用dbms_sql包装所有这些视图，并将它们放在最终视图中以供使用者使用，是的，这对于服务器来说是资源密集型的，但是这不需要对接收系统进行任何修改。
因此，回到流水线函数的使用，结果表明，如果要构造的类型不是在现有的版本包中创建的，而是第一次构造的，则该包根本就不会编译而崩溃。 立即没有解决方案，去寻找其他程序员的建议？ 有人说需要在程序包的零版本中创建此类型，或者在数据库的零版本中创建具有相应类型的程序包。 目前尚不清楚为什么要这样做。 他们找到了一个解决方案，可以将这些类型（在编译软件包时隐式创建）创建为数据库对象，然后将其简单地放入单独的类型中。 从而解决了输送机功能的问题。
我们偶然发现的下一个功能是版本化视图的非标准行为。
还记得我谈到过对象被继承和更新的事实吗？ 因此，事实证明，如果您和我在有条件的零版本上创建了版本化视图，则到第五版时，我们注意到注释中的错误。 例如，我自己注意到在专栏评论中，我可以在地方交换两个字母。 不要留下这样的瑕疵！
因此，通常的注释命令导致这样的事实，即我们的版本视图已在当前版本中更新。 因此，所有依赖包都会崩溃，如何处理呢？ 为此，他们编写了一个特定的脚本，该脚本在创建新版本时将在每次发布下一个发行版时更新版本控制视图。 这不会给数据库字典带来很大的负担，但是如果需要，可以进行一些更正，例如，发出新的授权，我们不需要创建新版本
好吧，最后一个这样的错误或功能...尚不清楚为什么在更改为非null时，版本化视图列的限制会消失。 也就是说，一旦我们说基本表的列现在不应该具有null限制，即使使用dbms重定义，视图也会崩溃。 我们无法以任何方式打败这件事，也许读者遇到过这个问题，知道是否找到了解决方案将很有趣。
最后我想说什么？ 基于版本的重新定义是一项有效的技术，可为您提供真正的机会，以用户模式在线发布发行版或修补程序。 我们感触到，意识到并不是所有方案都将使用该技术来组织在一台服务器上的集成是真实的，更不用说版本化方案可以在专用服务器或单独的容器数据库上工作。
作为一个应用程序和对关键问题的回答，“有可能在生产中使用吗？” ...我们希望基于版本的重定义或早或晚会应用到我们所有的项目中，也许这将是我们应用程序的最后一站，并确保您的应用程序平静下来。负责安装新版本的开发人员的睡眠。
实际上，仅此而已。 谢谢您的关注。