An overview of merging patches in E-Business Suite

A few days ago, a poster on the OTN forums asked a question about merged patches in EBS, wondering if it was possible to identify which individual patches in a merged patch had failed. The short answer, as explained in the thread, is, "no, merged patches don't work that way."

In nutshell, here is what the Oracle Applications patch merge utility, admrgpch, does:

  1. Reads through the drivers of each patch to be merged
  2. Checks the version of each file within the patch to determine if it should be included in the merged patch
  3. Copies the appropriate files to the new merged patch destination directory
  4. Generates a new patch driver that encompasses all of the actions for the individual patches. This driver will be u_merge_name.drv, where merge_name is supplied as an argument to admrgpch. If you elect not to specify a value for merge_name, the default is "merged," which is both boring and potentially confusing to you if you perform multiple merges over the lifetime of your EBS instance.

You can watch these steps unfold for yourself by using the verbose flag when running admrgpch. The default level, 1 (QUIET), is kind of dull, but level 3 (LOUD) can be instructive. In particular, you'll see the decisions made in the course of comparing file versions:

  • "File does not exist in the merged patch, adding...." - new file found
  • "Versions Same" - no need to add this file to the merge, as it was found in an earlier patch
  • "Replacing old entry with new one." -- Current file has a newer revision
  • Presumably, there's also a message for "this version is older than the one in the merge", but my test run didn't include that condition.

Merging patches saves time in two ways. First, since the result of the process is a single new patch, there is no need to run multiple patching sessions. Second, the merged patch will often do less work than applying patches in series, since multiples versions of files are culled, and only the highest version of a given file is applied. Consider the following example, from a merged set of arbitrarily selected patches. This file exists in multiple individual patches, with different versions.

zathras: jpiwowar$ find unmerged -name zxifsrvctypspkgb.pls | xargs grep '$Header' | cut -f4 -d\

120.246.12010000.19
120.246.12010000.9
120.246.12010000.27
120.246.12010000.19
120.246.12010000.45
120.246.12010000.28

If I were to apply each patch individually, adpatch could have to process that PL/SQL file up to 6 times. Perhaps that doesn't seem like a big deal, but there are sure to be similar situations for other files, and that can add up to a significant amount of extra work for large groups of patches. Of course, I could also have the good fortune to apply the patch with the highest version of the file first, and therefore only process that .pls file once, but how often does that ever happen? ;-) In contrast, by creating a merged patch, earlier versions of the file are discarded in favor of the highest version:

zathras:ZX jpiwowar$ find merged_patches -name zxifsrvctypspkgb.pls | xargs grep '$Header' | cut -f4 -d\

120.246.12010000.45

Incidentally, while it may look like the transcription of a stifled sneeze, or the name of an Icelandic volcano, that's actually a real filename.

A final, slightly repetitive point: The result of the patch merging process is a new, single patch. The driver file for the merged patch will indicate that the patch is merged, but the only time this information matters is when the AD_BUGS and AD_APPLIED_PATCHES tables are populated at the end of the adpatch session. When adpatch is running, there are no indications of the source of the individual files being processed. There aren't any intermediate steps wherein adpatch records the completion of individual patches, because there aren't individual patches anymore.

Even though the individual patches have lost their identities during the merge, it is still possible to retrieve information about the bug fixes themselves by joining ad_applied_patches, ad_comprising_patches, ad_patch_drivers, and ad_bugs. Here's a query that associates a merged patch with its individual bug fixes. If you're not in the habit of giving your merged patches unique names, then you'll need to modify the query to use ad_applied_patches.applied_patch_id rather than patch_name. When reviewing the results of the query, remember that patch numbers often, but not always, correspond to bug numbers.

select ap.patch_name
     , ad.orig_patch_name
     , ad.driver_file_name
     , ad.merged_driver_flag
     , ad.merge_date
     , bug.bug_number
     , cp.patch_abstract --remove this line for 11.5.10. Column exists only in R12.
  from ad_applied_patches ap
  join ad_patch_drivers ad using (applied_patch_id)
  join ad_comprising_patches cp using (patch_driver_id)
  join ad_bugs bug using (bug_id)
 where ap.patch_name = '&merge_name'

4 Comments

  1. Posted 29 April 2010 at 22:07 | Permalink

    >...transcription of a stifled sneeze, or the name of an Icelandic volcano

    ROTFL

  2. Posted 29 April 2010 at 22:27 | Permalink

    Thank you, thank you. I'm here all week. :)

  3. Clive
    Posted 27 January 2013 at 22:14 | Permalink

    What is actually missing in this thread is, how to identify a patch as a candidate for merge. Is there a way you could tell if a patch could be merged or not?

  4. Posted 27 February 2013 at 11:21 | Permalink

    Hi Clive,

    Thanks for asking the question (sorry my answer is so late). I cover this question in one of my other blog posts: Why Merge EBS patches?, in the section "First things first." The short answer is that with a few exceptions, just about all patches can be merged (the main exceptions are: don't merge AD patches with other product patches, and don't merge patches if Oracle says that you shouldn't. :) )

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*