Online Patching就是允许用户在运行时打patch，并且无需重启服务器。以前如果用户要打patch，用户必须重启应用服务，这个很麻烦并且让会造成几个小时的停机，给客户也造成了成本的损失，12.2以后引入Online Patching,就不会有这样的烦恼了,对于EBS DBA绝对是一个福音 R12.2 OLP的实现方式：12.2引入了双文件系统(一个是run time文件系统，另一个是patching文件系统)，包括APPL_TOP, Common Top, Home, Web Home等等. 那么对于DB来说，在runtime和patching文件系统，是怎么管理数据库对象的？R12.2引入了一个新的概念“the logical view of the data model”，如果对于具体的实现方式可以看下边这篇文章 Oracle E-Business Suite Release 12.2 introduces Online Patching (OLP) using the new adop (AD Online Patching) utility. Online patching allows the application of patches while the system is up and running, and the users are online processing transactions. Oracle Apps 12.2 comes with dual file systems (one for run time and another is for patching) and two port pools (one for each file system). Think of dual file systems as two copies of R12.1 file systems, including APPL_TOP, Common Top, Oracle Home, Web Home..etc. This enables online patching the system on patch APPL_TOP, while application is still running on runtime APPL_TOP. This might sound like advanced staged APPL_TOP patching. All right, we got two APPL_TOPs, but how do we manage the database objects in the same database between runtime and patching to make online patching even possible? Well, Release 12.2 introduces a new concept, the logical view of the data model. This is implemented via editioning views, which isolate the running application from changes to the data model that may be introduced by a patch. So, data model changes are guaranteed to not affect the running application. Oracle Database 11g R2 Edition-Based Redefinition (EBR) feature is used to maintain the runtime and patch editions of the database objects. The following are few important concepts here. Two identical file systems are created during the Oracle Apps Installation in 12.2. After the installation, services can be started from either of the file systems. Once an online patch is applied, services must be started from the right RUN File system only. Both the file systems are not equal any more. During the next prepare phase, ADOP copies the differences (Sync the file systems). ADOP is a wrapper on top of auto patch (adpatch). ADOP manages the file sync, creating editions, etc and finally invokes adpatch to patch the PATCH environment. ADOP always patches the $PATCH_BASE, while application is running out of $RUN_BASE. Once patching $PATCH_BASE is complete, we need to flip $PATCH_BASE into $RUN_BASE and $RUN_BASE into $PATCH_BASE. This is known as cutover phase in ADOP. This still needs downtime/outage. There are three editions in the database: Run - Online users connect to this edition, which is the default database edition Patch - Patching tools connect to this edition Old - the previous run edition is now old edition ADOP has got different phases: Prepare, Apply, Finalize, Cutover, and Cleanup. These phases are explained below. Oracle Database 11g R2 Edition-Based Redefinition (EBR) feature enables multiple copies of the same code object in the database in different editions of the database. However, not all database objects are editioned. In this case, a temporary object is created and all the rows are copied there. This may cause serious problems if the database is very large. Online patching analysis report, ADZDCHKP.SQL, provides detailed report about the non-editioned object references. This can be run in R12.1 database before the upgrade. You can still apply patches using ADPATCH, but not support (or not recommended). Database would have two services defined out of the box.
<EOF>
具体内容参见