ADOP PREPARE phase, does a series of validations

 In the PREPARE phase, ADOP does a series of validations and then “prepares” the system for an online patching cycle. Here is a rundown of what happens step-by-step when we run adop phase=prepare

First, it preforms the verification of parameters and checks for various minor pre-reeqs

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 statuses. During this time it also throws a warning if number of editions are greater than 20.

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 scrpt 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 begins do do an FS_CLONE internally. It syncs both configuration and FS objects as seen from the below steps. During this, some of the patch edition processes (apps listener, node manager, admin server etc.) are started to enable the sync. At the end of the process, these are gracefully stopped.

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

Synchronizng 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