AD PATCH

When a customer reports a problem or SR (Service 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.

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). The adpatch utility executes the *.drv files in order to apply the patch.

server patches may have three types of driver files: Copy, Database, and Generation. The Copy driver copies replacement files and links executables. The Database driver updates the database with SQL scripts and otherprograms. 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 type of driver file is now available with 11i. This driver simplifies copying Java classes and updates java files. The format is j.zip (Release 11i).

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.

Sequence of activities performed by adpatch : 

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

D -Portion
=> Run SQL and EXEC scripts

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)

General sequence of steps for worker processing 

This is the sequence of steps that happen which is not visible in the front screen


Running SQL and EXEC commands in parallel...

1. CREATE TABLE fnd_install_processes
2. CREATE UNIQUE INDEX fnd_install_processes_u1 on fnd_install_processes
3. GRANT ALL ON fnd_install_processes TO APPS WITH GRANT OPTION
4. CREATE SYNONYM fnd_install_processes FOR APPLSYS.fnd_install_processes
5. CREATE TABLE AD_DEFERRED_JOBS(
6. CREATE UNIQUE INDEX AD_DEFERRED_JOBS_U1 on AD_DEFERRED_JOBS
7. GRANT ALL ON AD_DEFERRED_JOBS TO APPS WITH GRANT OPTION
8. CREATE SYNONYM AD_DEFERRED_JOBS FOR APPLSYS.AD_DEFERRED_JOBS
9. INSERT INTO fnd_install_processes (number of times depending on the no. of workers)*.

Reading jobs from FND_INSTALL_PROCESSES table ...
Done reading jobs from FND_INSTALL_PROCESSES table ...
Telling workers to read 'todo' restart file.
Done.

[Worker Processing]

Telling workers to quit...
All workers have quit.

10. DROP SYNONYM fnd_install_processes
11. DROP SYNONYM AD_DEFERRED_JOBS
12. DROP TABLE fnd_install_processes
13. DROP TABLE AD_DEFERRED_JOBS