Oracle EBS is set of many application. The technology stack consists of Application filesystem, database and IAs server. We often need to patch it either to fix a bug or upgrade it. This article we are presenting the basics of patch and how patching is done in Oracle EBS environment
What is patch ?
When a customer reports a problem or TAR (Technical Assistance Request) a support analyst investigates the problem. If a patch doesn’t exist to fix the problem, the problem is logged as a bug. Development researches the bug and creates a patch.
How the patches are applied in EBS
Patches in Oracle Applications are applied using the adpatch utility, this is referred to as AutoPatch. AutoPatch is also used to apply release updates. Release updates are large patches that fix bugs for all products. Release updates may also add new functionality and the release number is incremented (i.e., 11.5.9 – >11.5.10 or 12.1.2 to R12.1.3). The adpatch utility executes the *.drv files in order to apply the patch.
Autopatches patches has three types of driver files: Copy, Database, and Generation in old release .But now we have single unified driver file which serve all the three portion. The Copy driver copies replacement files and links executable. The Database driver updates the database with SQL scripts and other programs. The Generate driver generates forms, reports, and message files. This is also the order that driver files should be applied: Copy, Database, Generation. Other components of a patch may include: Readme.txt, replacement files, SQL scripts or binary executables. Always read the Readme.txt file. Some patches may include a special version of the admin utilities, such as, adpatch or adadmin.A fourth/another type of driver file is now available with 11i and above This driver simplifies copying Java classes and updates java files. The format is j.zip (Release 11i and above).
The readme file for a patch should include a description of the problem being fixed and how to apply the patch. The readme may require the use of included admin utilities (usually adpatch). The patch driver file includes a list of files that have been altered and a list of patches included in the patch set.
Types of application patches
• Stand-alone (one-off) Patch: Addresses a single fix or enhancement. Stand-alone patches are released only when there is an immediate need for a fix or enhancement that cannot wait until an aggregate bundling is available. Although stand-alone patches are intended to be as small as possible, they usually include any dependent files that have changed since the base release in order to form a complete patch that can be applied by any customer. The actual number of files changed will depend on the current code level on the system to which the patch is being applied.
• Rollup Patch (RUP): An aggregation of patches that may be at the functional level, or at a specific product/family release level. For example, a Flexfields rollup patch contains all the latest patches related to Flexfields at the time the patch was created. A Marketing Family 11.5.9 rollup patch contains all the latest Marketing patches released since, and applicable to, 11.5.9.
• Mini-pack: An aggregation of patches at the product level. For example, Inventory Mini-pack G (11i.INV.G) contains all the latest patches for the Inventory product at the time the mini-pack was created.Mini-packs are cumulative.
• Family Pack: An aggregation of patches at the product family level. For example, HR Family Pack C (11i.HR_PF.C) contains all the latest patches for products in the HR family at the time the family pack was created. Family packs are cumulative.
• Maintenance Pack: An aggregation of patches for all products in the E-Business Suite. For example, Release 11.5.10 Maintenance Pack contains all the latest code level for all products at the time 11.5.10 was created. Maintenance packs are numbered sequentially such as 11.5.8, 11.5.9, 11.5.10, and are cumulative.
Patches can also be organized by purpose.
• Diagnostic Patch: Used to gather additional information when a product failure cannot be reproduced by Oracle. The additional information will assist Oracle Support Services and Oracle Development in resolving the failure.• Interoperability Patch: Allows Oracle Applications to function properly with a newer version of the technology stack. Interoperability patches are typically required with new version of the database or Applications technology stack.
• Translated Patch: A non-English version of a patch. Release 11i supports 30 non-English languages. Customers who are using languages other than English, need to apply the corresponding translated patch(es) for the languages they are using in addition to any base US patch(es).
• Merged Translation Patch: Provided in real time (without requiring a translator) in the event a translated patch is not available when a customer needs it. A merged translation patch is applied just like a fully translated patch. The fully translated patch is escalated and is usually available within 24 hours. It can be applied safely on top of a merged translation patch.
• Translation Fix: Provided in the event a translation word choice is inappropriate. A translation fix is applied just like a translated patch, except there is no corresponding base US patch.
• New Feature Patch: Introduces new functionality and/or products. It is applied using standard patching utilities.
AutoPatch Driver files
• Copy driver (c driver): Named c.drv, and contains commands to change Oracle Applications files. The commands include directives to copy/update files, libraries, and/or Java, and commands for generating JAR files and relink C executables. In a multi-node system, run it on all application tier APPL_TOPs. It does not make use of FND_INSTALL_PROCESSSES
• Database driver (d driver): Named d.drv, and contains commands to change Oracle Applications database objects, such as PL/SQL and table definitions, or to update or migrate data. In a multi-node system, run it only on the application tier APPL_TOP that implements the admin server. It does make use of FND_INSTALL_PROCESSSES
• Generate driver (g driver): Named g.drv, and contains commands to generate forms, reports, and/or graphics files. In a multi-node system, run it on all application tier APPL_TOPs, unless the APPL_TOP only implements the admin server. It does make use of FND_INSTALL_PROCESSSES
• Unified driver (u driver): Named u.drv, it is a consolidated driver containing all copy, database, and generate actions. Apply this driver to all APPL_TOPs on all application tier servers. AutoPatch knows which command should be run on each type of application tier. The unified driver requires only a single execution of AutoPatch. It is currently used only in the Release 11.5.9 Maintenance Pack.It does make use of FND_INSTALL_PROCESSSES
If you merge a patch that contains a unified driver with patches that contain other drivers, the resulting merged patch will contain only a merged unified driver.
Sequence of activities performed by adpatch
Here are action perform by adpatch in U driver . U driver contains all the three portion c,d,g
These are valid for R12.2 also as adop runs adpatch command only . The only difference is that these things are done on Patch edition and patch filesystem.
C Portion
=> Parse & Load the specified patch driver file
=> Check for patch integrity
=> Apply new applprod.txt if any
=> Perform version checking for the patch driver files
=> Copy driver files into installation area
=> Forecopy driver files into installation area (if any)
=> Screen out files that are not valid
=> Determine valid on-site files
=> Check if object modules exist to copy
=> Extract object modules from product libraries
=> Perform Version checking
=> Check if will copy object modules
=> Determine directories to create (if any)
=> Determine what executables to link
=> Determine forms to generate
=> Determine Oracle Report libraries to generate
=> Determine Oracle Reports to generate
=> Copy files into installation area
=> Archive object modules in the product libraries
=> Create directories
=> Relink executables
=> Perform second half of mirrored copies
=> Update Oracle Applications java Files
Explanation of C Portion steps
1)AutoPatch extracts the appropriate files.
2)AutoPatch compares the extracted object modules with their corresponding files in the patch directory. It also makes this type of comparison with files such as forms, reports, and SQL scripts
3) If a file in the patch directory is a more recent version than the product’s current file, AutoPatch backs up the product’s current file.
4) AutoPatch then replaces each product’s outdated files with newer files from the patch directory.
5) copy command in driver file – Compare version of file in patch with on-site and copy from patch directory to target subdirectory if target is older or missing
6) forcecopy command Copy object file into target subdirectory but do not check version number against existing file. The file admvcode.log records these actions.
7) The file log records these actions
8) AutoPatch loads the new object modules into the C libraries.
9) libin – Copy file into product library. The file adlibin.log records these actions.
10)libout – Extract file from product library. The file adlibout.log records these actions.
11) link – Relink executable with Oracle10 Server. The file adrelink.log records these action
12) AutoPatch backs up any files which you listed in adlinkbk.txt and which will be relinked.
13)AutoPatch relinks the products with the Oracle10 Server.
14) adrelink can fail if there is not sufficient space.
15)AutoPatch copies any specified Java, HTML, or media files to their respective destinations.
16) Applies changed Java class files and regenerates JAR files
17) Autopatch runs autoconfig also if the template files are changed
D -Portion
=> Run SQL and EXEC scripts
Explanation of D Driver Actions
1) Gets a list of current invalid objects in the APPS schema.
2) Determines whether the action was performed in a previous patch.
3) Runs SQL scripts and exec commands, which change Oracle Applications database objects.
4) By default, AutoPatch does this in parallel.It uses FND_INSTALL_PROCESSES table to perform this action
Related Article
How FND_INSTALL_PROCESSES created ,used and dropped
5) Performs Invoker Rights processing if the patch contains a package command.
6) Compiles invalid objects in the database using adutlrp
7) Gets a list of current invalid objects in the APPS schema.
G-Portion
=> Generate Forms library files
=> Generate Forms Menu files
=> Generate Forms executables
=> Generate Report libraries
=> Generate Reports
=> Generate Graphics libraries
=> Generate Graphics
=> Generate Messages
=> Generate Workflow resource files
=> Update Patch History database
=> Copy applprod.tmp to applprod.txt (if needed)
Explanation of G driver actions
1) genform command in driver file means Generate Oracle Forms
2) genrpll command in driver file means Generate the specified Oracle Reports PL/SQL library file
3) genrep command in driver file means Generate Oracle Reports report
4) genfpll command in driver file means Generate Oracle Forms PL/SQL library file
5) genmenu command in driver file means Generate Oracle Forms menu file
6) genmesg command in driver file means Generate new messages
7) genwfmsg command in driver file means Generate workflow msg
How the Patching is performed in Oracle EBS
- We usually get the Oracle patch number from Oracle support to fix the issue or to enhance the functionality.
- We first go the Oracle -meta-link and Search the patch and check the read me of the patch
- Read me gives us the details about the patch , prereq required for the patch and any special steps which need to be performed
We check the prereq patches and main patch in our Apps Environment using the below sql
select APPLICATION_SHORT_NAME , substr(BUG_NUMBER,1,10) Patch#,
substr(ARU_RELEASE_NAME,1,10)
Version,last_update_date applied_date from applsys.ad_bugs where BUG_NUMBER= to_char('&patch_no');
If we need to check patch level for the Application , we can use below query
select pi.patch_level, Application_short_name fromfnd_product_installations pi, fnd_application fa where fa.application_id
= pi.application_id and Application_short_name like ‘&App_Short_Name’;select patch_level from apps.fnd_product_installations where patch_level LIKE (‘%&1%’);
4) Download and Unzip the patch.
a)login to oracle metalink.(https://support.oracle.com)
b)Select the patches option then select the search type.
c) Query for patch by writing the patch no. & platform on which you want to download the patch.
d)Click download on your desktop. Or you can use wget option to download the patch directly on the server
e) If you have downloaded the patch at desktop then move it to server and directory where you want it to unzip.
f)) Go to the directory on the server and Unzip the patch.
unzip patch.zip
This will unzip the patch in current directory & will make the required patch directories & sub directories.
5) Shutdown the Services and Enable the Maintenance Mode
$ADMIN_SCRIPTS_HOME/adstopall.sh
Maintenance Mode can be enable can be in two ways
Method -1
a)Set the environment file located in APPL_TOP.
b) Run adadmin. It will ask questions related to admin utility with default answers in brackets.Then it shows following options & ask for the choice:
1.Generate applications file menu.
2.Maintain applications file menu.
3.Compile/Reload Applications Database Entities Menu.
4.Maintain Applications Database Entities Menu.
5.Change Maintenance Mode.
6.Exit ad Administration.
Select option 5. The status of maintenance mode is displayed at the top of change maintenance mode menu.Again it will show following options & ask for choice:
1.Enable Maintenance mode.
2.Disable Maintenance mode.
3.Return to Main Menu.
Select option 1 and press enter
Method-2
You can enable maintenance mode using sqlplus also
sqlplus apps/<apps pass> @$AD_TOP/patch/115/sql/adsetmmd.sql ENABLE
6) Run adpatch on the command line
Two method are there
Method -1 (Interactive )
We run the adpatch command and answer all the prompt. It will ask for log file name, patch directory,driver file name, APPLSYS password ,system password and APPL_TOP information.
Then it will perform all the action written in the driver files . The action items are listed above which will be done by u-driver
Finally you will get the “autopatch is complete” message at the end
Method -2 (Non- interactive)
We can use the defaults file and apply patch in non-interactive way. It will not ask for prompt and apply the patch
adpatch \
logfile=<patchno>_adpatch.log \
patchtop=<patch dir> \
defaultsfile=${APPL_TOP}/admin/${TWO_TASK}/adpatch_${TWO_TASK}.def \
driver=u<patchno>.drv \
workers=<worker no> \
interactive=No
We just need to replace the patch number and specify the workers
If you dont have defaults file in the end and you apply patch using this command , then it will ask for prompt for first time, then defaults file will be created, and next time no prompts
Finally you will get the “autopatch is complete” message at the end
7) If you don’t see the “autopatch is complete” message at the end of the Autopatch log file ,it means Autopatch did not complete successfully and you need to check the logfiles to find the errors
8) Incase adpatch failed , then you can restart the patch by typing the same command and it will start from stage where it failed
Please check below Articles for adpatch failures
Troubleshooting Adpatch failed job
How to restart and skip the job from AD Controller ( ADCTRL)
40 Adpatch question every DBA should know
9) Once the patching is completed. Please disable the Maintenance mode using the steps mentioned above
You can use below sql command to do it also
sqlplus -s apps/appspass @$AD_TOP/patch/115/sql/adsetmmd.sql DISABLE
10) Start the services
$ADMIN_SCRIPTS_HOME/adstartall.sh
Some of the Important FAQ About adpatch
Question 1
What are the patching implications of a multi-node environment?
Answer
For R12, if we have not implemented shared APPL_TOP, patches need to applied on all the server.
Question 2
Can I run multiple AutoPatch sessions at the same time?
Answer
You cannot currently run multiple sessions simultaneously. However, patches can be merged and can be applied in a single patching session.
Question 3
What are AutoPatch restart files?
Answer
Restart files store information about completed processing in the event of a patch or system failure. They allow AutoPatchand AD Administration to continue processing at the point where they stopped. Do not modify or delete restart files unless specifically told to do so by Oracle Support Services.
The restart files reside in $APPL_TOP/admin/<SID>/restart
Question 4
If a worker fails when AutoPatch is running, what should I do?
Answer
When a worker fails its job, the AD utility running the worker will take one of several possible actions:
a)Defer the job to the end of the list of jobs to run, and assign the worker another job
b)Set the worker status to Failed and continue to run jobs in other workers
c) If all other workers are in failed or waiting state, wait for user input (interactive mode) or exit (non-interactive mode)
Question 5 What are various command line options that adpatch supports?
Answer Adpatch supports a generic command-line argument called options. The options argument consists of a comma separated list of keywords instructing AutoPatch to enable or disable certain actions in a patch.If the keyword is preceded by the word no , all actions in the patch corresponding to that keyword are disabled.
adpatch options=hotpatch,nocopy
Here is Quick Reference list of the most frequently used command line options
| [no]libout | libout commands in the driver file |
| [no]libin | libin commands in the driver file |
| [no]copy | copy commands in the driver file |
| [no]forcecopy | forcecopy commands in the driver file |
| [no]jcopy | jcopy commands in the patch driver file |
| [no]genform | genform commands in the driver file |
| [no]link | link commands in the driver file |
| [no]genrpll | genrpll commands in the driver file |
| [no]genfpll | genfpll commands in the driver file |
| [no]genmenu | genmenu commands in the driver file |
| [no]genmesg | genmesg commands in the patch driver file |
| [no]gengpll | gengpll commands in the patch driver file |
| [no]compilejsp | Automatic compile of out of date JSP files. Only runs if the patch has JSP files. Requires the per executable in your PATH. |
| [no]compiledb | Disable with options=nocompiledb. |
| [no]parallel | Running actions using parallel workers |
| [no]sql | sql commands in the driver file |
| [no]validate | validating the password for each ORACLE schema |
| [no]checkfile | Before running any sql or exec actions check whether that version of the file already run or not. |
| [no]prereq | Before applying any patch check whether the prereq patches applied. |
| nocopyportion | Copy driver actions will not be running |
| nodatabaseportion | Database driver actions will not be running |
| nogenerateportion | Generate driver actions wont be run. |
| localworkers | Number of workers to start on the current machine |
| workers | Total number of workers that can be started in this run of adpatch. |
Please read followings link for more about application
adadmin
ADODFCMP
How to reduce the Patching downtime
What is Adop in R12.2
R12.2 adop explained in detail
Distributed AD
Query to find Patch applied in Oracle apps
Patch wizard