EBS 12.2 Online Patching

The Online Patching Cycle

• Applying Oracle E-Business Suite patches without a significant system downtime is referred to as online patching, and a new utility, adop, is used to apply patches.

• Online patching is supported by the capability of storing multiple application editions in the database, and the provision of a dual application tier file system. At any given point in time, one of these file systems is designated as 'run' (part of the running system) and the other is the 'patch' (either being patched or awaiting the start of the next patching cycle). Whichever is the current run file system appears to the user in exactly the same way as the single application tier file system did in Oracle E-Business Suite releases prior to 12.2.

• A new environment variable, $FILE_EDITION, shows the current designation of a given dual file system member. Three other new environment variables designate the root directories of the run ($RUN_BASE), patch ($PATCH_BASE), and non-editioned ($NE_BASE) file systems.

The Online Patching Cycle - contd.

• The online patching cycle consists of a number of high level phases:- prepare- apply- finalize- cutover- cleanup

• After an online patching cycle is started, you should not perform any configuration changes in the run edition file system. Any that are made will not be propagated, and will therefore be lost after cutover is complete.

• Customizations are applied to the patch edition during the apply phase, normally after any Oracle E-Business Suite patches have been applied.

The Online Patching Cycle - contd.

• Two additional phases are provided for specialized use. Neither can be run in conjunction with any other phase.

- The abort phase is used to terminate a patching cycle before it is complete, and roll back any changes that have been made.

- The fs_clone phase is a separate command used to synchronize the patch file system with the run file system.

Prepare Phase

• 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.

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

• Checks to see if the database is prepared for online patching:- Checks if the database user is edition-enabled (at least one user, the PL/SQL API, will

return 'true'). If no edition-enabled users exist, adop displays a message to that effect.- 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.

- 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.

Prepare Phase - contd.

• 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, and so on.

• Produces a report showing information about the most important tablespaces is generated. This report is created in $APPL_TOP/admin/$TWO_TASK/out.

• 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).

• Invokes the TXK script $AD_TOP/patch/115/bin/txkADOPPreparePhaseSynchronize.pl to synchronize the patches which have been applied to the run appltop, 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.

Prepare Phase - contd.

• Checks the database for the existence of a patch edition, and creates one if it does not find one.

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

• If any of these checks fail, adop will exit with an error message.• The default delta-style (incremental) method of file system synchronization handles

official patches but will not synchronize any manually applied customizations.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.

Apply Phase

• In the apply phase, adop applies the specified patches to the system. In an online patching cycle, patches are applied to the patch edition of the database and file system.

• You can apply as many patches as you want per patching cycle.• Reports under the $APPL_TOP/admin/<SID>/out directory can help you identify and

diagnose problems that may occur in the online patching cycle. These reports list the proposed changes to database objects, both new and modified. The key files to examine are:- $APPL_TOP/admin/<SID>/out/adzdcmped.out- $APPL_TOP/admin/<SID>/log/u<patch_number>.log

Finalize Phase

• The finalize phase is used to perform any remaining processing that is needed to ensure the system is ready for the fastest possible cutover.

• The key actions of the finalize phase are:- Pre-compute DDL that needs to be run at cutover.- Compile all invalid objects.- Validate that the system is ready for cutover.- If finalize_mode=full, compute statistics for key data dictionary tables for improved

performance.

Cutover Phase

The key actions performed in the cutover phase are:• Shut down internal concurrent manager• Shut down application tier services• Cutover database - Promote patch database edition to become the

new run database edition, using adzdpmgr.pl script.• Cutover file system - Promote patch file system to become the new

run file system, switching the $FILE_EDITION values in the patch and run enviroments.

• Retire old editions• Terminate old database sessions• Start application tier services

Cleanup Phase

Various actions are performed during cleanup, including dropping (removing) obsolete:• Crossedition triggers• Seed data• Editioned code objects (covered objects)• Indexes• Columns• Editions

Abort Phase

• If for some reason either the prepare or apply phase failed or gave problems, you can abort the patching cycle at either of these points.

• In the abort phase, adop does the following:• Checks that there is an in-progress online patching cycle, i.e. whether the abort call

is valid.• Checks for the existence of a patch edition and drops one if it exists.• Cancels the ADZDPATCH concurrent program, if it is running.• Deletes the rows inserted for the pending session ID from the ad_adop_sessions and

ad_adop_session_patches tables.• After running abort, you must always run a full cleanup.• If any attempt was made to apply patches to the patch edition, after abort you must

run the fs_clone phase to recreate the patch file system.

Oracle Patch Application Assistant

• For patches that have manual steps, the patch readme file instructs you to use Oracle Patch Application Assistant (PAA) by running the admsi.pl script. For merged patches, PAA automatically merges the contents of the individual patch readme files.

• The Patch Application Assistant is started from the command line, and collects your input in a graphical user interface.

• Running Oracle Patch Application Assistant• Set the Environment• Unzip the patch• Review the Readme• Run PAA

The adop Utility

• You use the adop (AD Online Patching) utility to apply patches to the Oracle E-Business Suite file system or database. You can either allow adop to prompt for the information required to apply a patch, or enter the information without being prompted. Whichever method you choose, adop will then perform the tasks required to apply the patch:

• Reads patch metadata to determine patch dependencies and requirements• Uploads patch information from a prior patch session to the database (if applicable)• Reads and validate the patch driver file and reads the product driver files• Compares version numbers of object modules from the product libraries and version

numbers of the existing files against the patch files• Backs up all existing files that will be changed by the patch• Copies files

The adop Utility - contd.

• Archive files in libraries • Relinks executables • Generates forms, reports, messages, graphics, and Java archive (JAR) files• Compiles JSP files and invalid database objects • Updates database objects • Runs AutoConfig to update configuration files if any template files are introduced or

updated by the patch • Saves patch information to the database

adop Parameters

• phase - Used to tell adop which phases it is to run.• loglevel - Used to specify the amount of information logged and displayed as adop

performs its operations.• cleanup_mode - Provides cleanup processing control.• finalize_mode - Used to specify whether the finalize or cutover phases should be

performed in full mode or quick mode.• input_file - Used to specify the name of the input_file supplied to adop.• maxworkers - Used to override the default formula calculation for the number of

workers.• patches - Used to specify the patches adop is to apply.

adop Parameters - contd.

• flags - Specifies whether adop should quit on any driver action failure when applying a patch.

• prompt - Specifies whether adop prompts the user whether to continue after warnings.

• options - Used to specify various options to adop. See the "adop Options" section later in this chapter.

• cm_wait - Can be used when running cutover to specify how long to wait for existing concurrent processes to finish running before shutting down the Internal Concurrent Manager.

• workers - Used to specify the number of parallel workers to be employed.• defaultsfile - Used to specify the path to the custom adop defaults file.• patchtop - Used to specify the location where the patches are unloaded.• merge - Used to merge multiple patches. You can merge the unified driver files into a

single driver file that is passed to adop.

adop Parameters - contd.

• abandon - Specify whether to abandon a previous failed attempt to apply a patch. Use this mode if you want to continue with the online patching actions even though a patch apply has failed.

• restart - Specify if the previous failed patch apply should be restarted. This allows you to retry applying the previous patch from where it left off. This is useful if you were able to correct the cause of the error and want patch application to continue executing.

• action - Used to specify whether to perform database actions.• analytics - Used to generate reports that can be helpful in debugging certain types of

issue. Available with apply, finalize, cutover, and cleanup adop phases.• allowcoredump - Used to specify that a core dump should be generated if adop

crashes.

adop Parameters - contd.

• autoskip - Controls whether failed jobs are automatically skipped during patching. If the value is set to 'yes', failed jobs are skipped and a report of the skipped jobs is generated at the end of the patch apply. If the value is set to 'no', failed jobs will cause the patch to exit with error.

• skipsyncerror - Enables the user to specify that any synchronization errors in the prepare phase are expected to be fixed automatically in the synchronization that takes place with subsequent patches.

• allnodes - Used to specify whether to run adop on all nodes or just a single node.• mtrestart - Used to specify whether to restart application tier services after cutover.

adop Parameter Values

• phase - prepare, apply, finalize, cutover, cleanup, fs_clone, abort, actualize_all• loglevel - STATEMENT, PROCEDURE, EVENT, WARNING, ERROR, UNEXPECTED• cleanup_mode - quick, standard, full• finalize_mode - full, standard, quick• flags - autoskip/noautoskip• prompt - yes/no• merge - yes/no• abandon - yes/no

adop Parameter Values - contd.

• restart - yes/no• action - db, nodb• autoskip - yes/no• skipsyncerror - yes/no• allnodes - yes/no• mtrestart - yes/no• allowcoredump - yes/no• analytics - yes/no

The Input File

• adop also accepts parameters in an input file. From the command line, you specify an input file by using the parameter input_file=<myinput.txt>, where myinput.txt is the name of your input file.

• Major parameters that can be specified in the input file include:• patches, phase, patchtop, merge, defaultsfile, abandon, restart, workers• Input file parameters must appear in name=value format, with one parameter per

line. For example:phase=applypatches=123456workers=8autoskip=yes

The Defaults File

• Parameters can also be passed to adop into adop through a defaults file. From the command line, you can specify a defaults file by using the parameter defaultsfile=<mydefaults.txt>, where mydefaults.txt is the name of your file.

• If adop is being run in hotpatch mode, your own defaults file should be located on the run file system, under $APPL_TOP/admin/$TWO_TASK. Otherwise, the defaults file should be in the same location, but on the patch file system.

• Only one parameter, patchtop, can currently be defined in the defaultsfile. The default patchtop directory is on the non-editioned file system, at $APPL_TOP_NE/EBSapps/patch.

Preparing the System for Patching

• In Release 12.2, it is more appropriate to think in terms of a patching cycle than a single patching operation. The online patching cycle consists of a number of phases:- Prepare - Used to start a new online patching cycle- Apply - Used to apply a patch to the patch edition of a system- Finalize - Used to perform the final patching operations that can be executed while the

application is still online- Cutover - Used to perform the transition to the patched environment- Cleanup - Used to remove old objects that are no longer needed

• Abort phase - Used only if the online patching cycle needs to be terminated before completion. The abort phase can only be run after the prepare phase and before completion of the cutover phase. After the cutover phase completes, it is no longer possible to abort the online patching cycle.

Patch Log Files

• The adop log files are located on the non-editioned file system (fs_ne), under $NE_BASE/EBSapps/log/adop/<adop_session_id>/<phase>_<date>_<time>/<context_name>/log

adop Patching Modes

• The adop utility is normally used execute an online patching cycle, but patches can also be applied in other modes for

special situations.• Downtime Mode - When applying patches in this mode, adop will first confirm that the application tier services are down,

and will then proceed to apply the patch to the run edition of the Oracle E-Business Suite database and file system.

Downtime mode patching does not use an online patching cycle. The process of applying a patch in downtime mode

completes more quickly than in online mode, but at the cost of increased system downtime.• Pre-install Mode - Pre-install mode is generally used during the upgrade process to update AD utilities, apply pre-upgrade

patches, or work around other patching issues. adop asks all startup questions except those relating to the database.• Test Mode - In test mode, adop does not apply the patch. Instead, it lists each file it would have copied, relinked,

executed, or generated and shows exactly what actions it would have performed had it applied the patch. It also runs

AutoConfig in test mode to determine any impending changes to the configuration files. This allows you to see the effects

of the patch on your production system before you apply it.

adop Options

• The "options" argument is used to pass options that control how the patch is applied. It takes the form of a comma-separated list. Enter a single option, or a comma-separated list of options such as adop options=nocopyportion,nogenerateportion.

• actiondetails - Tells adop to print details of actions taken in a patching operation.• autoconfig - Tells adop to run AutoConfig automatically.• checkfile - Tells adop to either skip running EXEC, SQL, and EXECTIER commands if they

are recorded as already run, or to record them as having run after running them.• compiledb - Tells adop to automatically compile invalid objects in the database after

running actions normally found in the database portion of the driver.• compilejsp - Tells adop whether to automatically compile out-of-date JSP files. JSP files

are only compiled if the patch contains copy actions for at least one JSP file.• copyportion - Tells adop whether to run commands normally found in the copy portion of

the driver.

adop Options - contd.

• databaseportion - Tells adop whether to run commands normally found in the database portion of the driver.

• forceapply - Tells adop to reapply a patch that has already been applied.• generateportion - Tells adop whether to run commands normally found in the

generate portion of the driver.• integrity - Tells adop whether to verify that the version of each file referenced in a

copy action matches the version present in the patch.• parallel - Tells adop whether to run actions that update the database in parallel (such

as SQL) and actions that generate files in parallel (such as genform).• phtofile - Tells adop where to place patch history information after applying the

patch.• validate - Tells adop whether to connect to all registered Oracle E-Business Suite

schemas at the start of the patch.

adop Examples

• A simple example of the commands to execute a complete online patching cycle for patch 123456 is as follows:- . <EBS_ROOT>/EBSapps.env run- adop phase=prepare- adop phase=apply patches=123456- adop phase=finalize- adop phase=cutover- . <EBS_ROOT>/EBSapps.env run- adop phase=cleanup

• You can obtain a brief report for the current patching session by running the command: adop –status

Founded 1999

Financial Profile Privately Held

Headquarters Troy, MI

Business Focus 100% Oracle Services

Services • Managed Services• Professional Services• Staffing• Oracle Licensing

Employees 140+ Oracle Consultants

USA

MichiganTroy

Company Overview

INDIAANDHRA PRADESH

Hyderabad

CANADA

ONTARIO

Toronto