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

Part 1  |  Part 2  |  Part 3  |  Part 4

Post-Patching Steps

Many patches require post-patching steps to be executed to complete the patching process. Also, if the patch was applied using options such as nocompiledb, notautoconfig, nogenerateportion, and others, those stepsneed to be performed now. Typical post-patching steps include generating message files, regenerating JAR files, regenerating menu options, relinking executables, recompiling invalids, and recompiling flexfields. Most of the post-patching requirements can be performed with the AD Administration utility, adadmin.

When executing the adadmin utility, you will be prompted with several questions. These include validating the APPL_TOP and database, entering the apps and system password, and validating the utility’s environment settings, such as log filename. These variables can be set in an input parameter file to make manual responses to the questions unnecessary. This is similar to the steps required for adpatch.

As with other AD utilities, the menu options for the AD Administration utility may vary depending upon the AD patch level in the instance. The menu options for Minipack AD.I are shown in Figure 5-9.

          AD Administration Main Menu 
--------------------------------------------------

1.     Generate Applications Files menu

2.     Maintain Applications Files menu

3.     Compile/Reload Applications Database Entities menu

4.     Maintain Applications Database Entities menu

5.     Change Maintenance Mode

6.     Exit AD Administration

Figure 5-9. The AD Administration Main Menu

From the main menu, select the appropriate item to view its submenu. For example, to perform the post-patching steps of generating message files and product JAR files, select option 1 from the main menu, and select options 1 and 5 from the Generate Applications Files submenu shown in Figure 5-10.

       Generate Applications Files
--------------------------------------------------

1.     Generate message files

2.     Generate form files

3.     Generate report files

4.     Generate graphics files

5.     Generate product JAR files

6.     Return to Main Menu

Figure 5-10. The Generate Applications Files submenu

Other common post-patching steps include recompiling database objects owned by apps and recompiling flexfields. These options are located in other submenus in adadmin. As an Applications DBA, you should be familiar with the menu options available from this utility.

Note: After the patches have completed, check for additional entries in the dba_jobs table. Verify that any newly created jobs are required by your environment.

Patching Cleanup

After a patch has completed, there will be an increase in the used space for the Oracle Applications filesystem. Some of this space can be reclaimed by removing backup copies of application code. For example, located in the $FND_TOP/bin directory are files such as FNDSCH.sav and FNDSCH.xxxxx, where xxxx is a number. These files are copies of the FNDSCH file created by the patch utility.

A list of directories containing backup files can be created using the UNIX find command. From the $APPL_TOP directory, execute the following command to list the directories containing *.sav files:

$find . -name "*.sav"

Those directories will also contain files with numbered extensions. These files can safely be removed from the system.

If there are any concerns about the removal of such files, create a temporary directory and move the files from their $[module]_TOP/bin location. After verifying that the system functions properly, these files can be removed.

Another area of cleanup involves the backup subdirectory of the directory where the patch was unbundled. If you are applying a patch from a common directory to multiple instances, space can be reclaimed in the patch directory by removing files written to the backup subdirectory from previous patch applications.

Database Patching

Database patching consists of either upgrades or interim fixes. Database upgrades are typically complex in nature and require installation of new software when upgrading from one point release to another. Obsolete and new initialization parameters must be reviewed when upgrading to a new release of the database.

Database upgrades can be accomplished manually or by using dbmig, the database migration utility. Since the method for upgrading the database is version and platform dependent, the associated readme file for the upgrade must be reviewed, and the steps required to perform the upgrade should be documented.

Interim patch fixes for the database are applied as the owner of the database install with the opatch utility or by running an operating system script. Details on how to apply database patches are outlined in the patch’s readme.

Before upgrading or applying a patch to the database, the oraInst.loc file must point to the correct Oracle inventory location for the database ORACLE_HOME. It is also important to cleanly shut down the database before proceeding, and to perform a cold database backup.

The opatch utility is downloaded from MetaLink as patch number 2617419. The opatch utility requires Perl and JDK to function, and they must be installed and specified in the path and library environment variables. Once the opatch utility has been downloaded and unbundled, the Opatch directory of the opatch unbundled patch should be added to the PATH, as in the following example:

$export PATH=$PATH:/[path_of_2617419]/Opatch

The library path of Perl must also be specified with the following PERL5LIB environment variable, as in the following example:

$export PERL5LIB=[path_of_PERL]/lib

To validate that opatch is functioning properly, execute the following command with the lsinventory option:

$opatch lsinventory

Once opatch has been successfully set up, the database interim patch fix may be applied. To do this, first review the readme file for the patch. Make certain that all prerequisites have been met. Document any post-patching steps that are required. Download the patch and unbundle it. Change to the directory where the patch has been unbundled. Verify that the database has been shut down. Apply the patch by executing opatch as the database owner with the apply parameter, as in the following example:

$opatch apply

To verify that a patch has successfully been applied, the lsinventory option can again be executed. This will display all patches that have been applied to the database.

Note: If the opatch fails, there may be a patch_locked file located under the hidden directory $ORACLE_HOME/.patch_storage. The opatch utility may not be executed until the patch_locked file is removed.

Patching Best Practices

A proactive approach to patching is highly recommended. Patch fixes and upgrades will not only provide new functionality, but will also fix bugs for issues that may only come to light at the least opportune time. It is advisable to apply Maintenance Pack upgrades routinely and to not fall more than two point releases behind the most current release available. An automated approach to testing will facilitate patching efforts.

Oracle releases critical patches on a quarterly release schedule. The patches released are typically applicable to both the 11i Applications Technology Stack and supported Oracle RDBMS software. It is advisable to download and apply these patches on a scheduled basis, as they will primarily address security risks and Sarbanes-Oxley compliancy.

Technology stack components and product groups such as AD and FND are often prerequisites for future patches, such as Maintenance Packs and mandatory Family Packs. Therefore, it is important to stay current on these items. By applying such upgrades on a proactive basis, the time requirements for later patch sets may be greatly reduced.

Oracle often releases cumulative updates (CUs) or rollup patches (RUPs) for large patches, such as Maintenance Packs and Family Packs. Cumulative updates or rollup patches contain a collection of one-off patches that resolve errors resulting from the larger patch sets. When performing large patching efforts, it is recommended that you download and apply the latest cumulative update available for your environment.

--

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.