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上面。