The Triora Group

Many Apps DBAs already know how to automate patching for the E-Business Suite. But, it has been quite awhile since I saw anything written on this activity for the newer incoming Apps DBAs, so I though I would take a few minutes to cover this. For me, there are also some additional efficiencies to be gained from writing this article, since I frequently get asked how to do this.

First off, Oracle does a good job of documenting this procedure in the aptly named “Oracle Applications Maintenance Procedures” document. The other document you’ll want to read through is “Oracle Applications Maintenance Utilities”. These two discuss similar topics, but the “procedures” documentation specifically discusses how to apply a patch non-interactively.

So, now that I have pointed you to the professional documentation, let’s talk about patching. The patches we will discuss are for the E-Business Suite and will work for both Release 11i and Release 12. That being said, the specific system we used for authoring this article was a Release 11i system. I say this because occasionally there are additional steps required to apply a patch to a Release 12 system that will not be discussed below.

What other patches are there? Well, you may need to apply operating system patches or database patches, to name two. So please do not try to automate an operating system or database patch using the techniques described here.

Application patches are applied to the E-Business Suite using an AD Administration utility called “adpatch”. Patches can be applied interactively, meaning you are prompted for information the system requires for applying the patches, or you can apply them non-interactively, where you are still prompted for the same information, but the system has a file with the stored answers that allow you to run non-interactively. Make sense? It is important to understand this, as there are steps that need to be completed in order to apply a patch non-interactively. If you do not understand this, then you could miss setup steps and end up in a world of frustration.

I recommend that you apply a few patches interactively if you are new to patching so that you can get a feel for how this process works. Good DBAs are even better when they have the foundations down cold!

How do we create a script to run a patch non-interactively? Before we create the actual script, let’s create our flat file that will contain the answers to the system patching prompts; we call this a “defaultsfile”. This file must be created in the $APPL_TOP/admin/<TWO_TASK> directory. The defaults file can be created by running adpatch with the following syntax:

adpatch defaultsfile=$APPL_TOP/admin/<TWO TASK>/<name of file>

For my test system this would look like:

adpatch defaultsfile=/u01/apps/oracle/test01appl/admin/test01/patch_test01_defaults.txt

Executing this syntax will kick off a patching session and you will be prompted for information like confirming the correct APPL_TOP, confirming batch sizes, and entering the SYSTEM and APPS passwords. Your answers to these questions will be recorded in the defaults file for playback during subsequent patching sessions. If you make a mistake, you will need to understand these procedures to know whether you need to start over, or whether you feel comfortable editing the resulting defaultsfile afterwards. For this particular execution, when you get to the prompt asking you for the directory where your patch is, type in “abort” to exit this run. Your defaultsfile should now be created.

Interestingly enough, this now leaves you in a situation where your next adpatch session will be in an inconsistent state, and you will be prompted to either continue the previous patch session or start a new one. You will want to make sure you read on since this scenario could get you stuck, depending on how you set up your patch script!

Now that we have a defaultsfile, let’s create our patch script.

I always recommend having a patch respository that will be used to store the patches to be applied. If you do not have the storage for this, then you can create your patch script wherever you want. If you have enough storage capacity to have a patch repository, then create your patch script in that location. I typically name my patch script, which is going to be a shell script, patch_<TWO_TASK>_<patch number>, which translates to patch_test01_7195040 for our purposes. I use vi to create my file but you can use whichever editing program you are comfortable using. Our next step is to create the script:

vi patch_test01_7195040

The syntax, which will be explained further on, is:

time adpatch defaultsfile=$APPL_TOP/admin/test01/patch_test01_defaults.txt logfile=adpatch_7195040.log patchtop=/dba/patches/11.5.10_Patches/7195040 workers=12 interactive=yes options=novalidate

So, what do these mean?

time => I use this command to track the actual time it takes to apply my patch

adpatch => this is the adpatch command for creating a patching session

defaultsfile=$APPL_TOP/admin/test01/patch_test01_defaults.txt => This is the syntax for letting adpatch know that a defaultsfile will be used for this session

logfile=adpatch_7195040.log => this is the name for the log file created to verify successful patch application

patchtop=/dba/patches/11.5.10_Patches/7195040 => this variable identifies the directory where your patch is located. Make sure it ends with the number of your patch.

workers=12 => this variable specifies the number of workers used for tasks that can be executed in parallel. In this case I used number of CPUs plus 4. You will need to test your system for the best value here.

interactive=yes => funny enough, I use this to get around failed patch sessions

options=novalidate => this variable can be used for any options you want to pass to the adpatch sessions. The list of available “options” that can be used is found in the “Oracle Applications Maintenance Utilities” document.

Each of these variables / arguments have been explained above but let me expand on a few. I love using the Unix “time” command when patching because it gives me the actual run time for the patch, eliminating the need to watch the clock or derive the timing from one of the log files. Also, I like to use the “interactive” argument to allow my script to be re-executed if a patching session fails. If this argument is set to no then you will not be able to answer a prompt from within the execution of this script. Remember the inconsistent state we ended up in from above? Be careful here or you could end up running around in circles.

Oracle provides another variable that can be used for this scenario as well: “restart=yes”. You would need to pass this in on the command line, which means that upon a patch session failure, you would need to copy the contents of the patch script to the command line for execution, rather than executing the script. For me, that’s just more of a hassle. I like to use “interactive=yes” for this situation. You should do what makes you comfortable. Also, please look through the list of options that can be passed via the “options=” argument, as there are time saving options for those running multi-tiered systems, or for those applying a series of patches where certain tasks can be saved for a later patch in the series.

Since we are just talking about automating patching, discussing each of these options is beyond the scope of this article. As a side note, you will notice that I did not use the “driver=” argument within the patch script. I do not use this argument unless I have a specific patch driver that needs to be applied, as in the hrglobal patch driver, or maybe I just want to run the “c” driver on a multi-tiered system with multiple front ends.

As this article is for newbies I should make sure you know that patches for the E-Business Suite contain several different types of drivers. The most common drivers you will see are:

u<patch number>.drv => this is a unified driver and executes all appropriate phases for a patch

c<patch number>.drv => this is a copy driver and is only used for the application tiers’ files

d<patch number>.drv => this is the portion of the patch that makes changes in the database

g<patch number>.drv => this is the generate portion of the patch for generating forms, reports etc

So, now we have a script that can be applied without interactivity between you and the system, assuming no patch failures. Now, all we have to do is set the correct permissions for applying the patch, right? Yep….

How do we check for a successful patch application? I’ll write that one up for another article, since I have some quick ways to check.

If you enjoyed this post, make sure you subscribe to my RSS feed!