what happens in the adop phase prepare

Adop phase prepare is the first phase in Online patching cycle in R12.2 . Adop perform lots of action items in the phase.Here is the sequence of activities
1.Checks whether to perform a cleanup, which will be needed if the user failed to invoke cleanup after the cutover phase of a previous online patching cycle.

2.Validates system configuration to ensure that the system is ready to start an online patching cycle.

3.Checks to see if the database is prepared for online patching:

a)Checks if the database user is edition-enabled. If not, adop immediately exits with an error.

b) Checks to see if the patch service has been created. adop requires that a special database service exists for the purpose of connecting to the patch edition. This service is created automatically, but its continued existence is validated on each prepare.

c) Checks to see if logon trigger exists and is enabled. If the logon trigger is missing or the patch service has not been created, adop will automatically try to fix the issue so that it can proceed. If it cannot do so, it will exit with an error message.

d)Checks the integrity of the database data dictionary. If any corruption is found, adop exits with an errorease 12.2.

e) Checks that the E-Business Suite Technology Codelevel Checker (ETCC) has has been run, to verify that all required patches have been applied to the database.
4.Checks system configuration on each application tier node. A number of critical settings are validated to ensure that each application tier node is correctly registered, configured, and ready for patching.

Checks the file system, using the TXK script $AD_TOP/patch/115/bin/txkADOPPreparePhaseSanityCheck.pl. This script checks for the file system space, database connections, Apps/System/Weblogic Passwords, Contextfile Validation and so on
And it also Produces a report showing information about the most important tablespaces is generated. This report is created in $APPL_TOP/admin/$TWO_TASK/out.
5.Checks for the existence of the “Online Patching In Progress” (ADZDPATCH) concurrent program. This program prevents certain predefined concurrent programs from being started, and as such needs to be active while a patching cycle is in progress (that is, while a database patch edition exists).

The flow of process is 

a.If the ADZDPATCH program has not yet been requested to run, a request is submitted.If it does not exists ,below error is reported
ERROR at line 1:

ORA-20008: No Concurrent Manager is defined that can run concurrent program

ADZDPATCH

b.The status of ADZDPATCH is determined. If it is pending, it may be waiting for an incompatible program to finish. After the incompatibility is clear, its status will change to running, and it will allow the prepare phase to proceed. A message to this effect is displayed to the user.
c.The next stage depends on whether the concurrent managers are running:

i.If the concurrent managers are all down, the prepare phase continues, with ADZDPATCH entering a status of pending (with the highest priority) until the managers are started.
ii.If the concurrent managers are partially up, but there is no manager defined that can run ADZDPATCH, then the prepare phase will exit with an error.
iii.If the concurrent managers are up, and there is one defined that can run ADZDPATCH, processing will loop until ADZDPATCH changes status from pending to running . The prepare phase then continues.
ADZDPATCH is cancelled when the cutover phase is complete.

If you want any custom program not to run in patching cycle ,you will have to make it incompatible with this program
6.Invokes the TXK script $AD_TOP/patch/115/bin/txkADOPPreparePhaseSynchronize.pl to synchronize the patches which have been applied to the run APPL_TOP, but not the patch APPL_TOP. The script depends on the adop repository for patches that have been applied on the run APPL_TOP but not the patch APPL_TOP.

it Identify the patches that were applied to the run APPL_TOP and apply them to the patch APPL_TOP. The following steps are performed automatically:

a.The patches that need to be applied to the patch APPL_TOP are identified from the database.
b.The merged patches are applied by the adop utility.
The adop utility identifies the delta patches to be applied, and applies them silently to the current patch APPL_TOP. As this procedure only requires the application of delta patches, it requires less time

In some circumstances, the delta-style (incremental) synchronization method may fail when applying a series of patches to the patch edition. This can happen if the previous patching cycle included patches that failed to apply correctly, and was followed by subsequent patches that corrected the issue.

The skipsyncerror parameter enables you to specify that you expect any synchronization errors in the prepare phase to be fixed automatically in the synchronization that takes place with subsequent patches.

If the value of the parameter is passed as ‘yes’, the first patch to be synchronized will be done with the ‘autoskip’ flag set.
Important: It is your responsibility to check the log files and correct any errors in the subsequent apply phase, or to confirm that synchronization with subsequent patches resolved the issue.
An example of using this parameter would be as follows.

a.You run adop phase=prepare.
b.The phase fails with an error when trying to synchronize the run and patch file systems. That is, the attempt to synchronize a patch fails, but it is known that a subsequent patch will correct the problem.
c.You examine the log files and conclude that the synchronization errors will be fixed automatically in the synchronization that takes place with subsequent patches.
d.You run the command adop phase=prepare skipsyncerror=yes to restart the prepare phase. This time, application of the patch that failed in the previous prepare will be retried with the ‘autoskip’ flag set.
Synchronizing Customizations

The default delta-style (incremental) method of file system synchronization handles official patches but will not synchronize any manually applied customization. Examples of patching actions that are not synchronized by default include:

Compiling user-defined JSPs

Copying some third-party libraries

Copying and compiling user-defined concurrent programs

Copying and generating user-defined forms
To include custom patching actions in the default file system synchronization, you must include the required commands in the Custom Synchronization Driver, $APPL_TOP_NE/ad/custom/adop_sync.drv. You will add your customizations to the following section of the file:
#Begin Customization
…
#End Customization

All the actions defined in this file will be performed by adop automatically during the prepare phase. Be aware that there are two categories of custom command in adop_sync.drv: those that are run one time only, and those that are run at each file system synchronization (during the adop prepare phase).
Important: The adop_sync.drv file is not currently reset to its template file at any point. Consequently, after cutover (and before the next prepare phase), you should review the contents of adop_sync.drv and ensure the requirementns for your custom commands continue to be met.
7.Checks the database for the existence of a patch edition, and creates one if it does not find one.

a)A patch edition is created in the database.
b)All code objects in the patch edition begin as pointers to code objects in the run edition. Code objects in the patch edition begin as lightweight “stub objects” that point to the actual object definitions, which are inherited from earlier editions. Stub objects consume minimal space, so the database patch edition is initially very small in size.
c) As patches are applied to the patch edition, code objects are actualized (have a new definition created) in that edition.

8.Calls the $AD_TOP/patch/115/bin/txkADOPPreparePhaseSanityCheck.pl script again to confirm that the database connection to the patch edition is working.

Related articles

Adop Explained in R12.2

R12.2 Online patching sycle Summary