r12.2——adop cycle 详解

prepare：

prepare阶段要做的东西是根据上下文环境决定的，比如你是在这个系统上第一次运行prepare；再比如你是上次的apply 阶段失败后abort了，在运行的；再比如你是在cutover之后运行的。。。

Important：在运行prepare阶段之前，你必须保证满足如下条件（mgP77）：
如下空间必须满足：
• SYSTEM tablespace has a minimum of 25 GB of free space
• APPS_TS_SEED tablespace has a minimum of 5 GB of free space

可以通过如下脚本检查可用空间大小：$AD_TOP/sql/ADZDSHOWTS.sql 

prepare通用步骤：

1、检查环境变量是否被设置为run 版本的文件系统的APPL_TOP下。

2、检查是否需要运行cleanup步骤，如果在上次补丁cycle中cutover阶段结束后，未能成功调用cleanup，这次就要重新调用此步骤。

3、检查数据库是否已经做好了online patch的准备：

            ——检查FILE_EDITION环境变量的值设置为run，如果未设置为run，会报错。

            ——检查数据库的空间是否足够

            ——检查数据库用户是否edition-enabled（至少一个用户，plsql api将返回true）

             ——检查patch service是否被创建，如果检查没有patch service，将会建议你创建patch service。

           ——检查logon trigger是否存在，如果logon trgger丢失了或者patch service未被创建，adop会自动创建，fix这个错误，如果不能自动fix，adop退出。

4、检查file system，用TXK脚本：$AD_TOP/patch/115/bin/txkADOPPreparePhaseSanityCheck.pl——此脚本检查文件系统空间（会检查是否超过25g等等），数据库连接等等。

5、生成一个最重要表空间的信息报告，此报告的位置在$APPL_TOP/admin/$TWO_TASK/out

6、检查：“Online Patching In Progress”(ADZDPATCH) 并发程序  是否存在，这个程序可以阻止一些特定的预定义的并发程序的启动（这些特定的预定义的程序在patch cycle中是必需的）这个ADZDPATCH会在prepare到cutover所有过程中都运行，我现在的理解这个ADZDPATCH是用来保证patch进程，和正在运行产品数据一致性的一个程序，它能阻止一些可能引起数据不一致的进程的启动。

7、调用TXL脚本：$AD_TOP/patch/115/bin/txkADOPPreparePhaseSynchronize.pl 同步已经安装到run filesysgem中appltop下的补丁。（这个脚本里有检查空间，要求系统有75g空闲空间，我看了，如果没这么大空间就改了它）

8、检查数据库内是否存在这个补丁的版本，如果不存在，创建一个。

9、再次调用TXK脚本：$AD_TOP/patch/115/bin/txkADOPPreparePhaseSanityCheck.pl，确认数据库和patch文件系统的连接是正常的。如果检查失败，adop将会退出。

在prepare过程中，run file system APPL_TOP将会被同步到patch file system APPL_TOP下，有两种方式（1、只同步APPL_TOP目录；2、clone run file system to patch file system ,这种方法中首先把patch的文件系统：APPL_TOP,COMMON_TOP ,10.1.2 Oracle Home, FMW_Home重新命名，然后把run的file system拷贝过来，在运行adop phase = fs_clone）

如果在prepare阶段运行了adop phase= abort ，那也就是会说，你现在的patch file system是打了一半的补丁，所以，你也得运行adop phase=fs_clone ，然后才能再运行prepare，如果你不运行fs_clone ，那下次运行prepare的时候也会自动运行fs_clone，这就是为啥如果你adop上次abort了，直接在prepare会等待很长时间，因为adop在fs_clone。

apply

在apply阶段，你可以打任何多个补丁，然后一块运行cunover，这样就省去了来回切换的时间。

apply阶段，有个参数叫： analytics 

$ adop phase=apply analytics=yes

如果使用了这个参数，以下脚本会被调用：

• ADZDCMPED.sql - This script is used to display the differences between the run and patch editions, including new and changed objects. The output file location is: 
/u01/R122_EBS/fs_ne/EBSapps/log/adop/<adop_sessionID>/<apply_directory>/<context_name>/adzdcmped.out.

• ADZDSHOWED.sql - This script is used to display the editions in the system. The output file location is: 
/u01/R122_EBS/fs_ne/EBSapps/log/adop/<adop_sessionID>/<apply_directory>/<context_name>adzdshowed.out.

• ADZDSHOWOBJS.sql - This script is used to display the summary of editioned objects per edition. The output file location is: 
/u01/R122_EBS/fs_ne/EBSapps/log/adop/<adop_sessionID>/<apply_directory>/<context_name>adzdshowobjs.out

• ADZDSHOWSM.sql - This script is used to display the status report for the seed data manager. The output file location is: /u01/R122_EBS/fs_ne/EBSapps/log/adop/<adop_sessionID>/<apply_directory>/<context_name>adzdshowsm.out

cutover

finalize：调用数据库内的Finalize API （你也可以把finalize作为一个单独的adop phase，这里是指你在apply之后直接运行cutover，cutover会自动调用finalize）

1、关闭并发管理器，等待所有并发程序跑完，并发管理器关闭才能执行这个cutover过程，在等待过程中，系统仍然对外可用。

2、关闭应用层服务。

3、数据库edition切换，用adzdpmgr.pl脚本完成patch database edition 到run database edition的切换。

4、应用层Services 切换，停止当前run APPL_TOP,然后启动当前patch APPL_TOP。file system 切换，完成patch file system 到run file systen 的切换，完成环境变量$FILE_EDITION值的切换，现在patch APPL_TOP成为新的run APPL_TOP。

5、禁止访问旧版本数据库（old database editions）

6、结束旧版本数据库session：结束任何连接到旧版本数据库的session。

7、启动新的应用层的服务。

JAR文件和cutover：

在一个adop cycle中，被用到的jar文件，开始被存放在：$APPL_TOP/admin/<SID>out 目录下，在cutover阶段被uploade到数据库内，所以，在cutover没结束之前，千万不要把out目录给删了。。

如果cutover完了后你不想启动应用程序，可以用如下参数：

$ adop phase=cutover  mtrestart=no

cleanup

此phase必须运行 run APPL_TOP，如下动作在cleanup阶段执行：

1、删除covered 对象。

2、删除索引。

3、删除 forward cross-edition 触发器。

4、清除seed data。

ADZDCLEANUPRP.sql - This script is used to display the display the cleanup
status. The output file location is:/u01/R122_EBS/fs_ne/EBSapps/log/adop/<adop_sessionID>/<cleanup_folder>/<context_name>/adzdcleanuprp.out.

在某此运行时，观察到数据库内会进行类似的操作：

delete from APPLSYS.JDR_ATTRIBUTES where zd_edition_name <> 'V_20131209_1455'

这是因为，相对于12.1.3版本的环境，数据库开启了新特性EBR，给相关的表添加了一列叫zd_edition_name，当开始打补丁的时候，就会给这个表的每一行，这一列都插入打补丁那一时刻的时间值，此时系统还对外提供服务，如果补丁对某一行有修改（修改patch edition），或者用户有此时对某一行有修改（修改run edition），修改后会改变这一列的时间戳，我猜测等补丁打完，执行clean up的过程的时候，会把用户的修改（当时的run edition）合并到当前的run edition中，然后删除当时run edition（现在是patch edition的记录）

abort

只要在cutover阶段之前， 若发生了某些错误，就可以执行：adop phase=abort， 需要输入apps的用户和密码。abort做如下动作：

1、检查环境变量是否是run APPL_TOP的。

2、检查是否有未完成的session，检查abort调用是否合法。

3、检查存在的补丁版本，如果存在，删除之。

4、检查并发程序状态，如果有必要取消之前提交的并发程序。

5、删除上次pending session插入到ad_adop_sessions 和 ad_adop_session_patches表里的行。

注意下面的重要点：

1、运行完abort后，必须必须运行一个full cleanup（命令：adop phase=cleanup cleanup_mode=full）,这样就会删除上次未完成补丁插入到数据库表里的列。如果这些数据不删除，再下一个patch cycle中就会报错。

2、如果在多节点应用的环境下，你在一个节点运行了abort，你必须在其他节点上都再运行abort。

3、在多节点环境，并且用的是非共享的文件系统，必须用：adop phase=abort autoskip=yes ；而不能单单指定一个abort参数。

Reporting 

为了帮助诊断错误，或者以更简单的方式获得系统的信息，可以运行Online Patching Diagnostic Reports工具：

$AD_TOP/bin/adopreports.sh

运行方法：$ adopreports apps apps

从当前的run fs同步到patch fs有两种方法：

1、使用prepare过程自动同步；

2、使用fs_clone过程同步。

这两种方法是不一样的，第一种方法，只是用来同步补丁信息，但是客户化的开发，并不会被同步过去，比如你开发一些form，放到了run fs下，当你运行prepare过程时，并不会把这些开发同步过去，除非你修改一个同步的驱动文件：$APPL_TOP_NE/ad/custom/adop_sync.drv，来客户化的定义到底要同步哪些文件。

而第二种方法，就可以完全的，把当前系统所有文件复制到patch fs上面。