In the database, there is also a run edition and patch edition, but they do not swap roles back and forth as in the file system: the patch edition only comes into existence during apatching cycle, and becomes the new run edition at the end of the cycle. The former database run edition (the old edition) and the obsolete objects it contains are discarded at the end of an online patching cycle, and the space reclaimed during the cleanup phase.
关于EBR，转载一篇文章：http://www.itpub.net/thread-1230250-1-1.html
在11gR1之前,当业务系统需要升级的时候,我们常常需要停下,从而保证版本的一直性和访问的连续性,对于一些APP变更频繁但又不允许经常停应用的IT系统,这实在是一个很头大的问题,那么现在好了,从11gR2开始,Oracle引入了一个edition(版本)的概念,借助这个特性,我们可以实现app的online upgrade.同时该特性允许pre-upgrade application and the post-upgrade application并存,等我们确认post-upgrade app没问题的时候再把pre-upgrade app切换下来,在这期间整个APP的访问是不受影响的.从而可以最大程度的减少application down time.
实际上这个特性，在11gR1中已经提供了，只不过需要通过一个隐藏参数来控制
_edition_based_redefinition 11gR1中该参数默认是false.
11gR2中，该参数已经被废弃！
关于的edition-based redefinition的一些特性
1）一个database至少有一个缺省的edition
SQL> SELECT * FROM DATABASE_PROPERTIES WHERE PROPERTY_NAME = 'DEFAULT_EDITION';
PROPERTY_NAME PROPERTY_VALUE DESCRIPTION
----------------- ---------------- ------------------------------------
DEFAULT_EDITION ORA$BASE Name of the database default edition
SQL>
2）设置数据库的缺省edition
alter database DEFAULT EDITION = edition_name;
3）与edition相关的系统权限有
SQL> select name from system_privilege_map where name like '%EDITION%';
NAME
------------------
ALTER ANY EDITION
DROP ANY EDITION
CREATE ANY EDITION
SQL>
这些系统权限都默认授予了DBA角色，也就是说任何具有DBA role的用户都可以执行与Edition-Based Redefinition相关的任务。
这些任务包括
Grant or revoke privileges to create, alter, and drop editions
Enable editions for a schema
Set the database default edition
4）与edition相关的数据字典
*_editions -->列出了当前数据库中的所有的EDITIONS,缺省情况下ORA$BASE
SQL> select * from dba_editions;
EDITION_NAME PARENT_EDITION_NAME USABLE
-------------- -------------------- ------
ORA$BASE YES
*_objects -->描述当前版本下对应的objects的可见性（是实际对象还是继承对象）
SQL> select owner,object_name,edition_name from dba_objects;
*_objects_ae -->描述当前数据库中每个真实的objects(所有版本)
SQL> select owner,object_name,edition_name from dba_objects_ae;
5）通过不同的edition连接数据库
从11gR2开始，SQL*Plus这样的工具也有对edition的连接支持
<logon> is: {<username>[/<password>][@<connect_identifier>] | / }
[AS {SYSDBA | SYSOPER | SYSASM}] [EDITION=value]
默认情况下EDTION=DEFAULT_EDITION,也就是对应当前数据库的缺省版本
6）11gR2中editions支持的objects type有
■ Synonym
■ View
■ Function
■ Procedure
■ Package (specification and body)
■ Type (specification and body)
■ Library
■ Trigger
7）用户要想使用edition，必须先Enable editions for a schema。
注意：这是一个不可逆的动作，一旦enable了就不能disable了
比如
conn /as sysdba
alter user study enable editions;
通过如下语句可以查看某个schema是否enable editions.
select username,editions_enabled from dba_users;
注：这里有一个隐藏参数来控制是否对所有的用户enable editions，默认是false,需要按照上面的方法去enable.
_enable_editions_for_users FALSE enable editions for all users
通过查询R12.2系统中用户，可以发现，所有产品用户，APPS用户都支持EBR功能：
我们可以对比下，在R12.1的环境中，查询，发现所有用户都没有开启EBR功能：
logical view：
EBR自动管理对象的版本信息。但是，并不是所有的对象都是有版本信息的，比如一些交易（事务）数据。
所以，R12.2中，引入了一个新的概念，叫数据模型的logical view（逻辑视图），
这个的实现，是通过synonyms（同义词）和 editioning views 版本视图。 logical view （逻辑视图）实现了 把补丁引进的数据模型 和 正在运行的应用分开的功能。
数据模型的改变不会对当前运行的应用程序有任何的影响。数据模型的改变被实现为表中创建新的列，这些列在应用的patch edition中，通过editioning view展示在patch edition中。补丁新建的表，也会根据这种规则实现版本的屏蔽。
Cross-Edition Triggers:
一种新的对象：交叉版本触发器，被用来同步在线补丁的数据。这种触发器，提供了一种同步和转换run edition和patch edition表列的逻辑机制。
特别地，交叉版本触发器允许run edition发出信号：现在需要进行数据更新。在 insert into, delete from, or update of, FND_TABLE的时候，这个触发器被触发。举个栗子：有个patch想要更新一列：DESCRIPTION，从upper case更新成mixed case。edition view 就映射出同一个表的不同的视图（run and patch edition），这个时候，当前运行的应用程序仍会看到的是原先的upper case。但是patched application就会看到这个列的数据是mixed case。这个更新的列就是被cross-edition trigger管理的。In summary, cross-edition triggers are used to upgrade both existing data and ongoing changes that occur while the run edition remains in use.
所谓的版本视图，可以被看做是一个cover layer或者数据的逻辑表示层。所有的代码（包括(Oracle E-Business Suite, custom, or third-party）必须通过这个cover layer去访问Oracle E-Business Suite的数据。
关于数据库中的seed data：
In terms of editions and seed data, the run edition:
• Always operates on a private copy of the seed data
• Is never modified by patch application
In contrast, the patch edition:4-18 Oracle E-Business Suite Concepts
• Runs the seed data loader
• Prepares the relevant table for patching
• Copies all table rows
• Loads seed data changes into the (patch) copy
Updates to seed data in the run edition are automatically propagated to the patch
edition by the use of cross-edition triggers