你好 我叫Antonina，我是Sportmaster Lab IT部门的Oracle开发人员。 我在这里工作了仅两年，但是由于有一个友好的团队，一个紧密联系的团队，一个指导系统，一个公司培训，当我不仅要消耗知识，而且要分享我的经验时，关键的群体已经积累。
因此，基于版本的重新定义。 为什么我们甚至还需要研究这项技术，以及“高可用性”一词？基于版本的重新定义如何在Oracle开发人员节省时间的同时帮助我们？
Oracle作为解决方案提出了什么建议？ 应用此技术时，后院正在发生什么，我们遇到了什么问题...总的来说，有很多问题。 我将在有关该主题的两篇文章中尝试回答这些问题，其中第一篇已经被削减。
每个开发人员团队在创建自己的应用程序时都在努力制定最实惠，最容错，最可靠的算法。 为什么我们都为此奋斗？ 可能不是因为我们太棒了，我们想发布一款很酷的产品。 更确切地说，不仅因为我们是如此出色。 这对业务也很重要。 尽管我们可以编写一个很酷的算法，用单元测试覆盖它，看到它是容错的，但我们（Oracle开发人员）仍然有一个问题-我们面临着升级应用程序的需求。 例如，忠诚度系统的同事被迫在晚上这样做。
如果这种情况很快发生，用户会看到一张图片：“请原谅！”，“别难过！”，“等等，我们在这里有更新和技术工作。” 为什么这对企业如此重要？ 但这很简单-长期以来，企业一直在蒙受损失，不仅损失了一些实际商品，材料价值，而且还遭受了基础设施停机的损失。 例如，根据《福布斯》（Forbes）杂志，在13天内，亚马逊服务中断一分钟，便造成6.6万美元的损失。 也就是说，在半小时内，这些家伙损失了将近200万美元。
显然，对于中小企业（而不是像亚马逊这样的巨头）而言，这些定量特征将大大减少，但是相对而言，这仍然是一个重要的评估特征。
因此，我们需要确保应用程序的高可用性。 Oracle开发人员对此可访问性有哪些潜在危险位置？
首先，我们的硬件可能会发生故障。 作为开发人员，我们对此概不负责。 网络管理员必须确保服务器和结构对象可以运行。 我们正在导致的是软件升级。 同样，计划的软件更新可以分为两类。 或者，我们正在改变某种基础架构，例如，更新服务器所在的操作系统。 我们要么决定迁移到Oracle的新版本（如果我们成功迁移到了它，那会很好：））...或者，第二类，这是我们关系最大的东西-这是更新与您一起开发的应用程序的对象。
同样，此更新可以分为另外两个类。
或者我们更改该对象的某些物理特性（我认为每个Oracle开发人员有时都会遇到这样的事实，即他的索引下降了，他不得不即时重建索引）。 或者，假设我们在表中引入了新的部分，即不会停止。 而且那个非常麻烦的地方是应用程序逻辑的改变。
那么基于版本的重新定义与它有什么关系？ 而这项技术-就是如何在不影响用户工作的情况下即时在线更新应用程序。
此在线更新有哪些要求？ 我们必须在用户未察觉的情况下执行此操作，也就是说，所有应用程序都必须保持工作状态。 如果用户坐下，开始工作并清晰地记得他有紧急会议或需要乘汽车去服务时，可能会发生这种情况。 他起床，因为工作场所而跑了出来。 那时，我们以某种方式更新了我们的应用程序，工作逻辑发生了变化，新用户已经与我们建立联系，数据开始以新的方式进行处理。 因此，我们需要最终确保在应用程序的原始版本和应用程序的新版本之间交换数据。 它们是在线更新提出的两个要求。
提出什么解决方案？ 从Oracle 11.2版开始，引入了基于版本的重新定义技术，并引入了诸如版本，可编辑对象，编辑视图，跨版本触发器之类的概念。 我们允许自己进行“版本”这样的翻译。 通常，具有扩展性的EBR技术可以称为DBMS本身内部的DBMS对象版本控制。
那么，作为实体的Edition是什么？
这是一种容器，您可以在其中更改和设置代码。 在您自己的范围内，在您自己的版本中。 在这种情况下，数据将被更改并仅写入当前版本中可见的那些结构。 版本表示将对此负责，我们将进一步考虑他们的工作。
这就是外部技术的外观。 如何运作？ 对于初学者-在代码级别。 我们将拥有原始应用程序版本1，其中有一些算法可以处理我们的数据。 当我们了解到需要升级时，在创建新版本时，会发生以下情况：处理代码的所有对象都在新版本中继承了……同时，在这个新创建的沙箱中，我们可以向用户隐蔽地享受我们想要的乐趣：我们可以改变工作方式功能，程序； 更换包装； 我们甚至可以拒绝使用任何对象。
会发生什么？ 原始版本保持不变，仍可供用户使用，并且所有功能均可用。 在我们创建的版本中，在新版本中，那些未更改的对象保持不变，即从应用程序的原始版本继承。 通过我们所涉及的块，对象将以新版本进行更新。 当然，当您删除对象时，该对象在我们的应用程序的新版本中不可用，但是在原始版本中仍然可以使用，这就是在代码级别上工作的简单程度。
数据结构会发生什么，版本控制视图与它有什么关系？
由于通过数据结构，我们意味着一个表和一个版本控制视图，因此，实际上，这是一个外壳（我自称是表的道德“查找”），是对原始列的投影。 当我们了解到需要更改应用程序的操作，并以某种方式将列添加到表中，甚至禁止使用列时，我们将在新版本中创建一个新的版本控制视图。
因此，在其中，我们将仅使用我们需要处理的一组列。 因此，在应用程序的原始版本中，数据被写入此范围中定义的集合中。 新应用程序将写入其范围内定义的一组列。
结构清晰，但是数据发生了什么？ 以及所有这些如何相互关联，我们将数据存储在原始结构中。 当我们了解到可以使用某种算法将原始结构中的数据转换为新数据并将其分解为新结构时，可以将该算法放入所谓的交叉版本触发器中。 它们只是旨在查看来自应用程序不同版本的结构。 也就是说，根据这种算法的可用性，我们可以将其挂在桌子上。 在这种情况下，数据将从原来的结构转换为新的结构，并且逐步向前的触发器将对此负责。 前提是我们需要确保将数据传输到旧版本，再次基于某种算法，反向触发器将对此负责。
当我们确定数据结构已更改并且可以为应用程序的旧版本和新版本的应用程序并行运行时，会发生什么情况？ 我们可以简单地用一些空闲更新来初始化新结构的填充。 之后，我们的应用程序的两个版本都可供用户使用。 对于旧用户，该功能仍保留在该应用程序的旧版本中；对于新用户，该功能将保留在该应用程序的新版本中。
当我们意识到旧应用程序中的用户都已断开连接时，可以隐藏此版本。 也许甚至数据结构也已更改。 我们记得，对于我们来说，新创建的版本中的版本控制视图将仅查看列1、3、4、5的集合。 好吧，因此，如果我们不需要此结构，则可以将其删除。 这是它如何工作的简短摘要。
有哪些限制？ 也就是说，做得好的Oracle，优秀的Oracle，优秀的Oracle：他们提出了一个很酷的东西。 目前的第一个限制是版本化类型的对象，它们是PL / SQL对象，即过程，包，函数，触发器等。 同义词已版本化，视图已版本化。
未版本化且永远不会版本化的是表和索引，实例化视图。 也就是说，在第一个版本中，您和我只更改元数据，并且可以根据需要存储它们的副本...实际上，此元数据的副本数量有限，但稍后会更多。 第二个问题涉及用户数据，其复制将需要大量磁盘空间，这是不合逻辑的，而且非常昂贵。
下一个限制是，仅当架构对象属于经版本授权的用户时，它们才会被完全版本化。 实际上，对用户的这些特权只是数据库中的某种标记。 您可以使用通常的命令授予这些权限。 但我提请您注意这一行动是不可逆转的事实。 因此，我们不要立即袖手旁观，在战斗服务器上键入所有这些内容，首先我们将进行测试。
下一个限制是非版本对象不能依赖于版本对象。 好吧，这很合逻辑。 至少，我们将不了解要查看对象的哪个版本。 在这一点上，我想引起注意，因为我们必须与这一刻竞争。
下一个 版本化视图属于模式所有者，表所有者，并且仅在每个版本中。 版本化视图的核心是表包装器，因此很显然，它在应用程序的每个版本中都应该是唯一的。
同样重要的是，层次结构中的版本数可能是2000。这很可能是由于您没有以某种方式加载字典而导致的。 我最初说过，对象在创建新版本时会被继承。 现在，此层次结构完全是线性构建的-一个父级，一个后代。 也许会有某种树形结构，我看到了一些先决条件，因为您可以将版本创建命令设置为特定版本的继承者。 目前这是一个严格的线性层次结构，该链中的链接数为2000。
显然，随着我们应用程序的某些频繁升级，该数目可能会用尽或超出，但是从Oracle的第12版开始，可以在不再使用此链的情况下削减此链中创建的极限版本。
希望您现在大致了解其工作原理。 如果您决定-“是的，我们想触摸它”-切换到使用该技术需要做什么？
首先，您需要确定使用策略。 什么事啊 了解我们的表结构多久更改一次，是否需要使用版本化视图，尤其是在我们需要跨版本的触发器以确保数据更改的情况下。 否则，我们将仅对PL / SQL代码进行版本控制。 在我们的例子中，当我们进行测试时，我们看到表仍然在更改，因此我们可能还会使用版本化视图。
此外，自然地，所选方案被授予版本化特权。
之后，我们重命名表。 为什么要这样做？ 只是为了保护我们的PL / SQL代码对象免遭表的修改。
考虑到30个字符的限制，我们决定在表格末尾添加一个尖锐的符号。 之后，将使用原始表名称创建版本控制视图。 而且它们已经在代码中使用了。 重要的是，在我们要使用的第一个版本中，版本化视图是源表中完整的列集，因为PL / SQL代码对象可以完全相同地访问所有这些列。
之后，我们将DML触发器从表扩展到版本化视图（是的，版本化视图允许我们将触发器挂在它们上）。 也许我们从表中撤消了授权，然后将它们提供给新创建的视图...从理论上讲，所有这些点就足够了，我们只需要重新编译PL / SQL代码和从属视图即可。
I-and-and-and ...当然，测试，测试以及尽可能多的测试。 为什么要测试？ 不可能那么简单。 我们偶然发现了什么？
这就是
我的第二篇文章 。