ADOP Prepare phase in EBS R12.2

In the PREPARE phase, ADOP does a series of validations and then prepares the system for an online patching cycle. Here is a step-by-step details when we run :

adop phase=prepare

• Performing verification of parameters
  • Sourcing the Run Edition environment
  • Validating system setup…
  • Determining admin node
    • Node registry is valid.
  • Performing database sanity checks
  • Acquire lock on sessions table
  • Checking for pending adop sessions
    • active hotpatch session…
    • active cleanup session
    • active FS_CLONE session
  • Staging new adop session…
    • Checking if node “<node_name>” previously failed
    • New row inserted into ad_adop_sessions table with session id : 100
  • Unlocking sessions table
• createPatchCtxFile()
  • check if patch context file exists, else generate it (from where?)
  • Checking the status of phase

select  count(1)
  from  ad_adop_sessions
 where  adop_session_id=100
   and (prepare_status in ('N','R'))
   and  node_name=’node_name’;

It should return 1. Anything else, it will fail.

Then, it validates the configuration on the current node using txkADOPValidation script

$AD_TOP12.0.0/patch/115/bin/txkADOPValidations.pl -contextfile=<context>.xml -patchctxfile=<p_context>.xml -phase=prepare -logloc=file.log -promptmsg=hide

It Creates 3 files txkADOPValidations.log, txkADOPValidations.error & ADOPValidations_detailed.log

Some of the validations done are:

• All the application tier nodes have entry in FND_NODES table
• All application tier context files (on both run and patch file systems) have correct entries in FND_OAM_CONTEXT_FILES table
• Value set for JDK_TOP and FMW_JDK_TOP are valid
• All Oracle inventory checks were successful
• APPL_TOP name is set correctly for the current node
• OHS configuration files are in sync with the latest AutoConfig templates
• Product addition for all custom product tops is correct
• Checks for Admin Server information in context files of both the file systems are validated successfully across all nodes.
• Validated multi-node setup
• Custom Product Tops have been configured properly across all nodes
• All required ports for patch file system are available
• Domain is not locked by any WLS user
• Patch file system WebLogic domain edit lock is not enabled
• The value of s_jdbc_connect_descriptor is not NULL
• The hostname and s_hostname have the same value
• s_ohs_installed is correctly set
• s_current_base is in sync across all nodes
• All managed servers status are valid
• File Edition values are set correctly in context files
• The values of s_current_base and s_other_base are set correctly on both RUN and PATCH filesystems

Next, ADOP Verifies data dictionary and updates status. 

• Executing steps for prepare phase…
• Updating ADOP session status
• Updating session process id

update ad_adop_sessions
   set status='R'
 where adop_session_id = 100 
   and appltop_id = 2103 
   and node_name='<node_name>'

• Updating ADOP session status
• Updating session dates
• Updating session status

  • Updating prepare_status=R for session_id : 100

• Check for number of edition and issue warning if there are more than 20. Below is a sample.

[WARNING]   There are 56 editions. We recommend no more than 20 for performance reasons.
[WARNING]   Please run actualize_all followed by cleanup in full mode to remove unused editions.

The next step is to ensure that the system is ready for PREPARE phase of ADOP. This is done using txkADOPPreparePhaseSanityCheck.pl

• Validating system is ready to prepare
• Validating Configuration

  • $AD_TOP/12.0.0/patch/115/bin/txkADOPPreparePhaseSanityCheck.pl

    • updatePatchApplTop()
    • Validate context file…
    • Validate PATCH context file…
    • Validate APPS schema credentials
    • Validate SYSTEM user credentials
    • Validate mode
    • Validate Action
    • Validate console log key
    • checkPrivileges() – Checking whether Filesystem directories have READ/WRITE access
    • checkFileEdition()
    • checkDiskSpaceOn<OS>()
  • Detecting configuration changes that must be synchronized.

If there are changes since last fs_clone or if the fs_clone was not run after the previous cutover, then now is the time. This is check done using the perl script adConfigChangeDetector.pl

$AD_TOP/12.0.0/patch/115/bin/adConfigChangeDetector.pl -detectConfigChanges
Contextfile = <file_name>.xml
promptmsg = hide
log =<path_to_log>.log
hostname = <host_name>

If configuration changes are detected you will see

“Configuration changes detected.”

If configuration changes are detected, the process then begin do an FS_CLONE internally within the prepare phase.

• Checking if there are pending cleanup actions
• Validating database is ready to prepare
  • Deleting rows from ad_patches_tables table
  • Performing DB Sanity checks
  • Checking if edition enabled users exist

• Generating report for important tablespaces $AD_TOP/12.0.0/sql/ADZDSHOWTS.sql

• Start Apps listener
• Submit ADZDPATCH concurrent program
• Creating Database Patch Edition
• Synchronizing patch filesystem with run filesystem

  • $AD_TOP/12.0.0/patch/115/bin/txkADOPPreparePhaseSynchronize.pl

• Perform CONFIG_CLONE
• Run FS Clone
• Run AutoConfig on Patch Edition file system
• Validate configuration
• Synchronize Snapshots
• Run Edition Reports
• Update ADOP Status in table
• Generate AD_ZD_LOGS Report
• Stop Services on Patch file system

Happy Learning!