From Oracle Applications DBA Field Guide, Berkeley, Apress, March 2006.

Part 1  |  Part 2  |  Part 3  |  Part 4

Applying Patches

After all of the required patching steps have been documented, you can begin the process of applying the patch. This generally involves the following logical steps:

1. Download and unbundle the patch.
2. Identify patch drivers required for the patch.
3. Place the instance in maintenance mode.
4. Use the AD Patch utility to apply patch driver files.
5. Perform any manual steps that may be required.

A sandbox instance is a must for applying patches. This instance gives the Oracle Applications DBA a place to apply patches and resolve issues without impacting production or other test instances. Ensure that the sandbox is a recent clone of production, so that this environment matches the production environment. All steps should be practiced multiple times and be thoroughly tested before applying the patch in production.

Note: The adpatch utility must be run as the owner of the application software.

Unbundling the Patch

The first step is to download the patch and unbundle it using an unzip utility. If errors are encountered while unzipping large zip files, you may require an updated version of the unzip program. Review operating system specifics and release notes regarding the unzip utility.

It is advisable to have a separate filesystem for storing and unbundling patches. When a large patch, such as a maintenance pack, is released, a temporary filesystem may need to be created to store the unbundled patch. When sizing the filesystem, be sure to include an extra 20 percent for backup information that is written to the patch directory.

Tip: Before applying a patch, confirm that there is enough space allocated to the instance filesystem, as well as to the filesystem where the patch has been unbundled. Exhausting filesystem space is a common error that occurs while applying patches.

Identifying Patch Drivers

Patches consist of a combination of a c, d, and/or g driver, or a unified u driver, that is applied to all appropriate nodes using the adpatch utility.

The c driver is the copy driver. This driver is used to update the filesystem with new file versions. The d driver is the database driver. It is used to update database level code and objects. The g driver is the generate driver. It is used to generate forms, PL/SQL libraries, reports, and menus. It is imperative that if a patch contains c, d, or g drivers, that they are applied in alphabetical
order: c, d, g.

The u driver is a merged driver that is a combined c, d, and/or g driver. Oracle is beginning to release a majority of its patches as unified driver patches. If a patch is a unified driver patch, then only the u driver is applied. The naming convention for patch driver files is u[Patch#].drv.

Once the patch has been downloaded and unbundled, change directory to the location where the patch driver(s) is located in preparation for applying the patch using the adpatch utility. Before you do, though, you should switch the instance to maintenance mode.

Enabling Maintenance Mode

Most patches require the application processes be shut down prior to applying the patch. As of release AD.I the system is required to be in Maintenance Mode prior to applying patches.

The instance can be placed in maintenance mode by running adadmin and selecting the appropriate menu options. Executing the SQL script $AD_TOP/patch/115/sql/adsetmmd.sql with the ENABLE parameter will place the instance in maintenance mode without using adadmin. When the patching has been completed, be sure to take the instance out of Maintenance Mode by executing $AD_TOP/patch/115/sql/adsetmmd.sql with the DISABLE parameter, or by using the adadmin utility.

A patch can also be applied using the hotpatch parameter. This option does not require the instance to be in Maintenance Mode, however Oracle recommends using Maintenance Mode to improve patching performance.

Using AD Patch

The administrative tool used to apply application patches is AD Patch, also referred to by its command line executable, adpatch. Basic information about the AD Patch utility can be found in Oracle MetaLink Note 181665.1, “REL11i ADPATCH BASICS.” The AD Patch utility will spawn off a user-determined number of worker threads or patch worker processes to update application
code by copying later versions of programs to the application tier; updatingdatabase objects, regeneration application forms, and reports; and performing some post-patching steps. The code changes are determined by the patch’s driver files.

Tip: Prior to executing adpatch, disable any password constraints defined within the application or database. These constraints could cause errors if the patch creates a new user account. You may also need to reset some standard Oracle passwords for accounts such as CTXSYS.

An Oracle Applications DBA needs to be familiar with the options available for the AD Patch utility. The parameters supported by the adpatch command differ depending upon the AD Minipack level applied with Oracle Applications. When upgrading the AD product group, be sure to identify and understand any new features of the AD Patch utility. Study the adpatch command parameters for any possible benefits. Use the command adpatch help=y to see the available options.

In order to enable an option with adpatch, use the following syntax:

adpatch options=[option1, option2..]

The adpatch options shown in Table 5-2 are commonly used to accelerate the patching process.

Novalidate

Noprereq

Nocompiledb

Nocompilejsp

Noautoconfig

Nogenerateportion 

Hidepw 

Hotpatch

Table 5-2. Commonly Used adpatch Options

Tip: If you are applying a large number of patches, use the options nocompilejsp, nocompiledb, noprereq, and novalidate to speed up the application of the patches. Recompiling Java Server Pages (JSP) pages and database objects can be performed at the end of the patching process. In this situation, placing the database in noarchivelog mode may also improve patching performance.

Having changed directory to the location where the patch driver(s) is located, you can then start the patching session as the instance owner by executing adpatch with the desired options:

adpatch options=nocompiledb,novalidate

When adpatch is started, the user must respond to several questions. These questions serve to verify application file settings, database connectivity, and patch driver options. For example, the user may set adpatch to send an email upon failure. The following questions from adpatch require additional explanation:

Question: Filename for AutoPatch Log

Recommended response: Rather than use the default name of adpatch.log, use a more descriptive name, such as [c|d|g|u][patch#]. log. For multi-node or multi-language patching, you should consider including the server name and language in the filename. Additional descriptions may also be added depending on your environment.

Question: The default directory is [current working directory]

Recommended response: It is advised that you run the adpatch utility from the directory where the patch has been unbundled. By doing this, the default value for this question can be chosen. Otherwise, enter the directory where the patch was unbundled.

Question: Please enter the name of your AutoPatch driver file

Recommended response: This depends upon the patch being applied. Most patches from Oracle now contain a single u driver. If the patch contains c, d, and/or g drivers, adpatch needs to be run for each driver. The drivers need to be applied in alphabetical order.

Question: Number of parallel workers

Recommended response: This value is environment-specific and should be adjusted accordingly.Using a defaultsfile will allow for noninteractive patching by providing responses to the adpatch questions. The defaultsfile option of adpatch must point to a file in the $APPL_TOP/admin/$CONTEXT_NAME directory. This option is typically used with the mode interactive=no.

Performing Manual Steps

If any part of the patching process requires numerous manual steps, it is useful to create scripts to automate the manual commands. This can not only help reduce the chances of human error during the patching process, but scripting can also speed up the process.

For ease of management, you should create a special directory to be the home directory for such scripts. During the creation of the scripts, be sure to include logging commands as well as parameters for values such as instance name. When you parameterize such variables, the scripts can be executed with each patching effort without requiring modifications.

For example, you may build a script of manual steps that looks similar to the following template:

SCRIPT_TOP=/patch/scripts/project_a
INSTANCE_NAME=$1
LOG_TOP=$SCRIPT_TOP/logs
script_1.sh > $LOG_TOP/post_steps.log
command_1 >>$LOG_TOP/post_steps.log
script_2.sh $INSTANCE_NAME >> $LOG_TOP/post_steps.log
exit

In the preceding example, script_1.sh may be a script that performs a backup of library files, and script_2.sh could be a script that relinks several forms.

When the script has executed, thoroughly review the log files generated by the script. New failures may be encountered on some instances that had not occurred during past patch applications. Resolve any errors before proceeding to the next steps. Scripts created for such steps should contain error handling, such as checking the number and types of parameters Custom scripts should also contain documentation to describe the purpose of the script.

The scripts you create should be included in the spreadsheet as part of the process for applying the patch. Part of the documentation process for the patching effort involves using descriptive script and variable names.

Writing scripts is a useful skill set for Applications DBAs. We recommend you practice coding scripts on test servers while connected as a user with a low level of permissions until you become more comfortable with scripting. Always test your scripts thoroughly before running them on production systems.

--

Elke Phelps is an Oracle Certified Professional with over 12 years’ experience administering Oracle products. She is the Founder and presiding President of the Oracle Applications User Group’s Middleware SIG—formerly the ATS SIG—and is responsible for conducting meetings at the annual OAUG and Oracle Open World conferences. This yields a unique medium for access to the Oracle Applications users and provides name recognition in the user community. Elke is the author of several whitepapers and is a technical presenter at many international conferences.

Paul Jackson has over 10 years’ experience as a developer and Oracle DBA. Paul is the Program Director for the ATS SIG. He is a very active member of the Oracle community through memberships of Ohio Valley Oracle Applications User Group (OVOAUG), International Oracle User Group (IOUG), and the Oracle RAC SIG.