Individual Patch, One-off, Standalone
These are terms used to describe an individual patch that is created to fix one particular bug. Currently, most Application products deliver their patches primarily through ‘Mini Packs’. Individual patches are possible, but rules for when one is created varies by product.
Mini Pack
‘Patch Set’ was the original term used in R10. In R11 the same type of patch is now being called a ‘Mini Pack’. Both terms mean a large, cumulative patch, for a particular product, that fixes most or all bugs that have been fixed for that release and product. These patches are….
· Named using a letter.
Þ 11i.PA.D
· Cumulative.
Þ For example, 11i.AP.D, would include fixes in AP.A, AP.B, AP.C, plus bugs fixed between when AP.C was released and when they began building AP.D.
· Created periodically.
Þ How often they are created varies by product.
· Require just one patch.
Þ However, if the install is a multi-node install, then the patch must be installed on each machine.
Þ If different platforms are used, the patch must be ported for each platform.
Family Pack
‘Family Pack’ is a group of Mini Packs for related products that are bundled together, and possibly some additional individual fixes that have been created after the Mini Packs. Some examples of product families are ERP, CRM, Procurement, or Order Management, but there are many others.
The same bulleted information for Mini Packs applies for Family Packs. The only difference is the naming structure. Family Packs will be named similar to:
· 11i.OM_PF.G or 11i.FINAP_PF.A
· The ‘_PF’ in the name indicates it is a Family Pack and not a Mini Pack.
FCUP or Family Consolidated Upgrade Patch
An FCUP (pronounced F-CUP) is a patch that needs to be applied before starting an upgrade. This patch includes performance improvements or bug fixes for processes that run during the upgrade. If an FCUP is required for an upgrade, it will be mentioned in the Release Notes.
Consolidated Patch or Mega Patch
These are unofficial terms that are used to name, or describe, a large patch that is a bundle of important bug fixes in one patch.
Maintenance Pack
Maintenance Pack is the term that Oracle began using for R11, while Release Update was used for R10.
A ‘Maintenance Pack’ is a collection of Mini Packs that are bundled together onto a set of CDs that can be ordered and easily installed by the customer.
· With the full installation of this type of patch, the 3rd digit of Applications Release will change.
Þ An example of a Maintenance Pack is 11.5.3 or 11.5.5
· When applying a Maintenance Pack, a user can choose to apply certain product’s Mini Packs individually, or they can apply all the product’s Mini Packs at once using one set of drivers.
Þ The Application’s version will not be updated, for example to 11.5.5, if the Mini Packs are applied individually.
· As with Mini Packs, Maintenance Packs are cumulative.
Þ So if 11.5.5 is applied, then prior Maintenance Packs do not need to be applied.
(11.5.1, 11.5.2, 11.5.3, 11.5.4).
· The primary purpose of Maintenance Packs is to fix bugs that have been identified. However, on occasion new functionality may be introduced.
NLS Patches
If your install has multiple languages, additional patches may need to be installed for each language. The
American patch needs to be applied first, then an NLS version of the same patch needs to be applied for each language. When applying the NLS patch, be sure to set the NLS_LANG variable to AMERICAN_AMERICA.
Not ALL patches will require an NLS version of a patch. For example, if the patch is only creating a new package, an NLS patch would not be required. However a patch that is replacing a form or report, or all large patches, such as Mini Packs or Maintenance Packs will require an NLS patch. Consult Oracle Support to confirm if an NLS patch is needed when applying a patch.
Adpatch has a function that was introduced in 11i that will alert the customer if an NLS patch may be needed. During patch application, the user will receive a message that an NLS patch may be required, and ask the user if they want to continue with the application of the patch.
Minor Release
Examples of a minor release are 10.7, 11.0, or 11.5. A minor release is not a patch.
· A Minor Release is installed using autoUpgrade, not adpatch, to upgrade to the release.
· The primary purpose of a Minor release is to introduce new functionality.
· Supported versions of Applications are based off of a Minor Release.
II. Basic Explanation of R11 Architecture
In order to understand how R11 patches are applied, the R11 architecture needs to be explained. For a complete picture, reading the manual Oracle Applications Release 11 for UNIX Concepts (Part# A90380) is recommended.
Documented below is a very simple explanation of R11i Architecture. Note, this is not a complete description, and to get a full understanding the Concepts manual should be read.
Beginning with R11, Oracle allows the user to break up their install according to their needs. The user can determine where to install 4 different ‘servers’. The Forms, Web, Concurrent Manager, and Admin servers can be installed all on one machine or broken up onto numerous machines.
Database Tier
Concurrent Processing Server
· Concurrent processes (Ex: reports, executables)
Administration Server
· Files that maintain the database (Ex: patch/110/sql)
Application Tier
Forms Server
· GUI Forms (.fmb and .fmx)
Web Server
· html and java files
Desktop Client Tier
· Contains appletviewer or JInitiator to log on to Applications from the client
Do not interpret the term ‘Server’, such as Forms Server, to mean a machine, such as Solaris or NT. These servers can all be on the same machine (single node install), or divided into numerous machines (multi-node install). For example, the user could have the Concurrent Processing Server and the Administration Server on a Solaris, and the Forms Server and the Web Server on an NT. This is the commonly used ‘two-node’ type of install. Many other combinations can be used, including multiple Forms Servers for Load Balancing or Fault Tolerance.
When a patch was applied in R11.0, the patch process asked 4 questions to determine which of the 4 different servers existed on the machine the patch was being applied to. These questions are listed below. In ( ) under the question is the server that these questions correspond to.
Do you currently have files used for installing or upgrading the database
installed in this $APPL_TOP [Yes] ?
(Administration Server)
Do you currently have Java and HTML files for Self-Service Applications
installed in this $APPL_TOP [Yes] ?
(Web Server)
Do you currently have Oracle Applications forms files installed
in this $APPL_TOP [Yes] ?
(Forms Server)
Do you currently have concurrent program files
installed in this $APPL_TOP [Yes] ?
(Concurrent Processing Server)
After these questions were answered, adpatch would know which files it needed to copy and the jobs it would need to perform.
In R11i, the install process stores the answer to these 4 questions in the file $APPL_TOP/admin/adconfig.txt. Then when adpatch is run, it reads this file and automatically answers the 4 questions for the user. This makes adpatch easier, and helps prevent user error.
Example:
The Applications instance has two machines.
Solaris Machine A, has the Concurrent Manager and Administration servers
NT Machine B, has the Forms and Web servers
The patch, ported for Solaris, would need to be applied to Machine A. The adconfig.txt file would then be read and answer the 4 questions for the user. In this case the answers to the questions should be, ‘Yes’ for questions 1 and 4, and ‘No’ for questions 2 and 3.
The same patch, ported for NT, would then be applied to Machine B, and the questions answered in the reverse. ‘Yes’ to 2 & 3. ‘No’ to 1 & 4.
III. Anatomy of a Patch
All R11 and R11i patches use the zip function instead of ‘tar’, which was used in R10
To unbundle the patch, simply use the unzip command:
unzip p2145632_11i_SOLARIS.zip
When a patch is unbundled it creates a directory that is the same number as the bug number which is included in the patch name. For example, p2145632_11i_SOLARIS.zip will create the directory 2145632. The 2145632 directory will contain the following:
readme.txt This is a text file that contains a brief explanation of what the patch fixes,and instructions on how to apply the patch. It is VERY important to thoroughly read this file, some examples of important information it may contain are:
· Prerequisite patch(s) that must be applied before applying the current patch.
· References to .html file(s) that are also included in the patch, which contains additional installation steps or instructions.
· Manual steps that must be executed before or after applying the patch.
· An explanation of a new feature introduced by the patch.
· Restrictions on who or when the patch can be applied.
· Instructions to run the patch in preinstall mode.
IMPORTANT: It is very important that the instructions in the readme are followed closely. Not following the readme may cause the patch to fail, not correct the problem it was intended to fix, or potentially introduce additional problems.
cXXXXXX.drv The ‘c’ or copy driver, and the first driver file executed. A driver provides adpatch with the instructions on the jobs it needs to perform. This driver copies files from patch to directories, relinks executables, and regenerates jar files.
dXXXXXX.drv The ‘d’ or ‘Database’ driver, which is the second driver file executed, if it exists. A patch will contain a database driver only if the patch contains files that will update the database, such as files in the patch/115/ sub-directories. Some examples, are scripts that…
· Create packages
· Create new error messages
· Add a new table or view to the database
· Add a new column to a table
· Add new seed data to a table
dXXXXXX.cf R11i patches created after December 2001 will include an additional
d driver, but with the .cf extension instead of .drv. This is used by a new adpatch feature, called the checkfile feature, which is introduced in an AD Mini Pack, or with some individual AD patches.
This feature is explained in depth by patches that introduce the feature,
such as 1945611 or the latest AD Mini Pack. But the following is a quick
explanation.
The checkfile feature can reduce the time to apply a d driver by not running
processes that have already been run. Such as FNDLOAD, WFLOAD, akload.class or any process in the d driver. It does this by creating a table, which stores the versions for the files used by these processes, then adpatch will check the version in the patch against the version stored in this table. If the version in the patch is not a higher version, then the process will be skipped. Adpatch is run the exact same way, but the .cf driver file is used instead of the .drv driver.
If a patch is applied using this driver without the new feature installed, the adpatch session will fail at the start.
gXXXXXX.drv The ‘g’ or ‘Generate’ driver, which is the third driver file executed, if it exists. A patch will contain a generate driver only if the patch contains files,such as forms, reports, graphics or messages, that need to be generated.
jXXXXXX.zip This zip file may be included in Java patches. This file is called a
Zipped Resource Unit or ZRU. If a patch contains a ZRU, it does not need to be unzipped. This is a zip file that contains ‘.class’ files and other web related files. The .zip file will be called and applied when adpatch is run with the c driver.
Product directories Each patch will contain at least one product directory (ap, gl, inv, etc.) that will contain sub-directories and the files that are included in the patch. The product directories in the patch will mirror a $XX_TOP structure. Meaning
the files will be in the same directories and sub-directories that are found in the APPL_TOP product directories.
Example of an Unbundled Patch
Following is an example of the directory structure of an unbundled patch. After p2145632_11i_SOLARIS.zip is unzipped, it creates the directory 2145632.
2145632
____________________|________________________
| | | |
ad c2145632.drv d2145632.drv readme.txt
|________________________________
| | |
admin patch lib
| | |
115 115 adadmin.o
| |
driver sql
| |____________
adcon.drv | |
adnuniq.sql aduvers.pls
IV. Installing a Patch
Following are the basic steps to installing a patch on R11i.
1. Have all Oracle Application users log out and shut down the concurrent managers.
2. Run the environment file found in $APPL_TOP to set the environment.
3. Make sure $ORACLE_HOME and $ORACLE_SID or $TWO_TASK are set correctly.
4. unzip the patch.
unzip p2145632_11i_SOLARIS.zip
5. Go to the patch directory created by ‘unzip’.
6. Read the readme and follow the instructions! If there are any steps to execute before starting the patch, they must be executed first. Such as applying a prerequisite patch.
7. To begin applying the patch the first step will be to run the ‘c’ driver, c2145632.drv. To start the adpatch process, just type:
adpatch
8. After the patch completes successfully, adpatch may need to be run again using a ‘d’ (database) and/or ‘g’ (generate) driver that is included with the patch. Consult the readme for specifics.
OPTION: Beginning with R11i AutoPatch has a non-interactive mode. Using this mode, users can run all drivers for a given patch in a single non-interactive AutoPatch session by using a defaults file. This is a very useful feature, simplifying the patch process for the customer. Details on how to use this feature can be found in the R11i ‘Maintaining Oracle Applications’ document.
Following are examples of the questions that are asked when running adpatch. In bold are additional comments that I have added to explain the questions and their answers. Any values in [ ] are the default answer, and will be used if the user just presses the enter or return key.
No comments:
Post a Comment