Release 11i Adpatch Basics
발췌 Oracle Support Note ID 181665.1
This is a document that explains the basics of adpatch for REL11i. This does not cover all functions of adpatch, but should cover the primary functions that most people need to understand. For complete information regarding adpatch, reference the Rel11i Maintaining Oracle Applications manual.
Another adpatch document exists that covers adpatch functions for R10 and R11. This document is available on Metalink, Doc ID 130608.1.
I. Types of Patches
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.<character set>, substituting the appropriate character set for your language. For more information on other variables and steps, consult the NLS Installation manual.
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 <return>
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.
ADPATCH PROCESS
Your default directory is ‘/u02/applmgr/PROD’.
Is this the correct APPL_TOP [Yes] ?
This is just confirming your APPL_TOP. Some customers may have multiple APPL_TOPs, for different instances, and this helps prevent someone from accidentally applying a patch to the wrong APPL_TOP.
AutoPatch records your AutoPatch session in a text file you specify. Enter your AutoPatch log file name or press [Return] to accept the default file name shown in brackets.
Filename [adpatch.log]
adpatch.log is the default. However, it is highly recommended that a log name that is specific to the patch you are applying is used ( Examples, are 2145632.log, c2145632.log 2145632_PROD.log). This way you can easily find and review the log file for this specific patch. Otherwise, the log file will be appended to adpatch.log, with all other patch log files.
Do you wish to activate this feature [Yes] ?
This feature is handy if you are applying a very large patch, such as a Mini Pack, that you are not going to be able to sit by and monitor. If you use this feature, adpatch will send an email to you if adpatch fails. The email will include the bottom of the log file, which should have the error message. This feature is not really necessary for smaller patches, or any patch you plan on monitoring the whole time.
If you answer Yes, adpatch will then ask the following question:
You chose to be notified by email when a failure occurs.
Please enter the email id(s) (separated by a space) that notifications should be
sent to [applmgr]:
You can enter one or multiple email addresses (separated by a space) for adpatch to send a message to if it fails.
Please enter the batchsize [1000] :
The patch may contain scripts that update data in batches. This prompt allows you to specify how many rows will be updated at a time. It is recommended that you accept the default unless you know your system well.
Please enter the name of the Oracle Applications Environment that this
APPL_TOP belongs to.
The Applications Environment name must be unique across all Oracle
Applications Environments at your site, must be from 1 to 8 characters
long, and may only contain alphanumeric characters.
Sample Applications Environment names are: "prod", "test", and "demo".
Applications Environment Name [PROD] : PROD *
This question is automatically answered by the patch process.
NOTE: If you do not currently have certain types of files installed in this APPL_TOP, you may not be able to perform certain tasks.
The following examples provided by adpatch are there to help explain the new R11 architecture discussed previously.
Example 1: If you don't have files used for installing or upgrading the database installed in this area, you cannot install or upgrade the database from this $APPL_TOP.
Example 2: If you don't have forms files installed in this area, you cannot generate them or run them from this $APPL_TOP.
Example 3: If you don't have concurrent program files installed in this area, you cannot relink concurrent programs or generate reports from this $APPL_TOP.
As discussed previously, the next 4 questions help determine which server(s) are on the system you are applying the patch to. These questions will be automatically answered by adpatch when it reads the file $APPL_TOP/admin/adconfig.txt.
Do you currently have files used for installing or upgrading the database
installed in this $APPL_TOP [Yes] ?
Do you currently have Java and HTML files for Self-Service Applications
installed in this APPL_TOP [Yes] ?
Do you currently have Oracle Applications forms files installed
in this $APPL_TOP [Yes] ?
Do you currently have concurrent program files installed
in this $APPL_TOP [Yes] ?
Please enter the name Oracle Applications will use to identify this APPL_TOP.
The APPL_TOP name you select must be unique within an Oracle Applications
Environment, must be from 1 to 8 characters long, and may only contain
alphanumeric and underscore characters.
AutoPatch has computed a default APPL_TOP name for you
based on the servers you have implemented in this APPL_TOP.
APPL_TOP Name [appslab31] : tafnw1
This question is also automatically answered by the patch process. This name is not really
used by Applications, but is used by OAM.
You are about to apply a patch to the installation of Oracle Applications
in your ORACLE database 'PROD'
using ORACLE executables in '/u02/oracle/proddb/8.1.6'.
Is this the correct database [Yes] ?
This is confirming that you are applying the patch to the correct database. Some customers may have multiple instances on a server, such as a TEST and PRODUCTION instance. This helps prevent them from accidentally applying a patch to the wrong database.
AutoPatch needs the password for your 'SYSTEM' ORACLE schema
in order to determine your installation configuration.
Enter the password for your 'SYSTEM' ORACLE schema:
Enter the SYSTEM password.
Connecting to SYSTEM......Connected successfully.
The ORACLE username specified below for Application Object Library
uniquely identifies your existing product group: APPLSYS
Enter the ORACLE password of Application Object Library [APPS] :
Enter the APPS password.
Identifier for the current session is 1336
Reading product information from file...
Reading language and territory information from file...
Reading language information from applUS.txt ...
Reading database to see what industry is currently installed.
Reading FND_LANGUAGES to see what is currently installed.
Currently, the following language is installed:
Code Language Status
---- --------------------------------------- ---------
US American English Base
Your base language will be AMERICAN.
Setting up module information.
Adpatch will then spool out a long list as it successfully connects to the different products.
For example:
Connecting to CZ......Connected successfully.
Connecting to PJM......Connected successfully.
Enter the directory where your Oracle Applications patch has been unloaded
The default directory is [/u02/applmgr/PROD/patch/2145632] :
The default directory is the directory where adpatch is executed. If adpatch is started from
the directory where the patch was unbundled, then just press <enter> to accept the default.
If adpatch is started from another directory, such as /tmp, then enter the full path to where the patch is unbundled.
readme.txt file spooled to screen.
If the patch has a readme.txt file, it will now be spooled out to the screen. This is to encourage the user to read this file before applying the patch. This function may go away in the future.
Please enter the name of your AutoPatch driver file:
Type in the name of driver file that needs to be used for this session of adpatch. For example, d2145632.drv, or d2145632.cf, if the check file feature is installed.
Patch validation:
After entering the driver. Adpatch will then do a series of patch validation steps before continuing. Information about the validation will be spooled to the screen. An example of things that may be validated are:
· Verify the patch release matches the release of the instance it is being applied to.
· Verify the platform of the patch against the platform it is being applied to.
· Determine if the files referenced in the driver file either exist in the patch or on the current APPL_TOP.
Do you want to see the list of fixes in this patch [No] ?
Previously, this was automatically spooled out. Now it will ask if you want to see the list of fixes included in the patch. Just press <enter> to continue without viewing the list.
Enter the number of parallel workers [6] :
This determines the number of ‘adworkers’ that will be created to apply the patch. This prompt appears only if the driver contains the line “compatible parallel yes” or “compatible parallel always”, or if the driver file contains at least one ‘exec’ or ‘sql’ command. The default value is equal to the number of CPUs on the database server, plus 2. It is recommended that the default be used, because this makes the patch run faster. If you choose more than the default it may bog your database server down and cause the patch to run slower.
That is the last question. Then adpatch begins to apply the patch.
V. Patch Failure or Successful Completion
How to tell if a patch completed successfully
If adpatch completes successfully, it will display a message like the following.
AutoPatch is complete.
AutoPatch may have written informational messages to the file
/u02/applmgr/PROD/admin/PROD/log/c2145632.lgi
You should check the file
/u02/applmgr/PROD/admin/PROD/log/c2145632.log
for errors.
What to do if a patch fails.
If the patch fails, adpatch may do one of the following. Included under each bullet are the basic steps to restarting adpatch.
· Errors and returns to the o/s prompt
1. Review log file(s) to determine the cause of the error.
2. Fix the cause of the error.
3. Restart adpatch.
4. Answer ‘Yes’ when adpatch asks if you want to continue the previous session.
5. Adpatch will skip already completed jobs, and pick up from where it left off.
· Informs the user that an error occurred and asks if you want to continue
With this type of error there are two options.
Option 1 - Discontinue Patch Session
1. Answer ‘No’, that you do not want to continue.
2. Review log file(s) to determine the cause of the error.
3. Fix the cause of the error.
4. Restart adpatch.
5. Answer ‘Yes’ when adpatch asks if you want to continue the previous session.
6. Adpatch will skip already completed jobs, and pick up from where it left off.
Option 2 - Continue Patch Session
1. Make a note of the failure.
2. Choose to ignore the error and continue with adpatch.
3. After adpatch has completed go back and try to identify the problem and complete the job manually.
4. An example of when this error may occur is 22 out of 23 reports generate successfully, but one fails. Continue with the patch, then try to generate the failed report manually after adpatch has completed.
· Stops running after workers are spawned, and informs the user that workers have failed. It asks for you to fix the problem and restart the workers. Adpatch does not exit to the o/s, it just suspends working until the problem has been fixed and the workers restarted.
Workers can be monitored and maintained using ‘adctrl’. If one worker fails the others may
continue until itAt that point adpatch will inform you
that the errors in the workers must be corrected.
1. Review adworker log file(s) to determine the cause of the error.
2. Fix the cause of the error.
3. In another screen start ‘adctrl’
adctrl <return>
4. Answer the few questions required to start adctrl.
5. Pick option 2 ‘Tell worker to restart a failed job’
6. Type the worker number(s) you need to restart and press return. This will restart the failed worker for adpatch.
For more information on adctrl, consult the Maintaining Oracle Applications manual.
VI. After Applying a Patch.
Oracle recommends that the following steps are completed after each installation of a patch.
1. Review log files for errors.
Details about the different log files that are created by adpatch are listed in #8 in the next section.
2. Review customizations
If customized files have been registered in the file $APPL_TOP/admin/applcust.txt, adpatch will list the files documented in applcust.txt that will be replaced during the install of the patch. This file does not prevent the object or the patch from being applied, it just lists the objects that will be replaced.
If you are concerned about customizations, there are a couple options to consider.
a. unbundle the patch and review the contents of the patch.
b. run the patch in test mode. See page 20 for details.
3. Consider removing backup or obsolete files
AutoPatch performs version checking before copying a file into the necessary directory. If a file in a patch is determined to have a higher version than the existing copy, or it has the same version but different file size, then the file is copied to the appropriate directory, and the existing version is backed up. The backed up file is copied to a directory called ‘backup’ that is created in the unbundled patch directory.
If you are tight on space, you may want to periodically delete these backup files, as it can begin to take up a lot of space. However, you should first confirm that the new files works as you expected.
4. Maintain MultiLingual or Multiple Reporting Currencies Schemas(s)
If either the MRC or MultiLingual functionality is being used, the system needs to be updated after applying a patch. This is done by running the ‘Maintain MultiLingual’ or ‘Maintain Multiple Reporting Currencies’ options from adadmin
5. Pin SGA packages
The Installation Manual also suggests that if database objects are updated by the patch (a ‘D’ driver is run), the scripts ADXGNPIN.sql and ADXGNPNS.sql are run again to pin new packages and sequences in your Oracle System Global Area. Details on this function are also documented in the Installation Manual.
VII. Additional Patch Information
1. Is it OK to apply a patch when users are on the system?
As documented in the Installation Manual, Oracle advises that no users are logged on to the system while a patch is being applied.
2. Retrieving information on patches or files that have been applied via adpatch
The first time you run adpatch, a file named applptch.txt is created. This file is created in $APPL_TOP/admin/<ORACLE_SID>. This file is appended each time a patch is applied. The file contains the following information:
a) Bugs not applied and why
b) Bugs applied. For each bug applied it lists
1. Actions executed
2. Actions not executed
3. From this detail you can see what files were applied to the system
There is also the file $APPL_TOP/admin/applsum.txt which is more of a summary of the same information.
If you have applied a recent AD minipack, certain individual patches, or if you are on a later version of 11i you will have a new adpatch function that stores this information into new tables in the database. Past information from the applptch.txt file will also be loaded into these tables, and then the applptch.txt file will no longer be used.
If your applptch.txt file has been successfully loaded into the database, then you should see a file named something like...
applptch_succ_022602135156.txt
NOTE: If the initial install is a later version of R11i, it may have this function from the start, and would never have an applptch.txt file.
With this new feature, reports can be run from the operating system to pull information from the database. Following is a section that is included in patches that introduce this feature. This explains how to run these reports.
Also, OAM, Oracle Applications Manager, has also been released. Once installed this will allow the customer to easily pull the same information from a web application. OAM also has many other beneficial features and uses that are very useful for a System Administrator. Refer to note 166115.1 for more information on OAM and the installation process.
(1) Patch History report usage:
adphrept <query_depth> < bug_number or ALL> <bug_product or ALL> \
<end_date_from (mm/dd/rr or ALL)> <end_date_to (mm/dd/rr or ALL)> \
<patchname/ALL> <patchtype/ALL> <level/ALL> <language/ALL> \
<appltop/ALL> <limit to forms server? (Y/N)> \
<limit to web server? (Y/N)> \
<limit to node server? (Y/N)> \
<limit to admin server? (Y/N)> \
<only patches that change DB? (Y/N)>
Specify 1 or 2 or 3 for query_depth
1-> Details of patches only
2-> Details of patches and their Bug Fixes only
3-> Details of patches their Bug Fixes and Bug Actions
Example: To get the complete patch details for patches applied in Dec 2000:
On UNIX:
$ cd $AD_TOP/patch/115/sql
$ sqlplus <APPS username>/<APPS password>
SQL> @adphrept.sql 3 ALL ALL 12/01/00 12/31/00 ALL ALL ALL ALL ALL N N N
N N
On NT:
C:\> cd %AD_TOP%\patch\115\sql
C:\> sqlplus <APPS useord>
SQL> @adphrept.sql 3 ALL ALL 12/01/00 12/31/00 ALL ALL ALL ALL ALL N N N
N N
(2) File version history report:
adfhrept <filename> <latest file version only? (Y/N)>
<start date(mm/dd/rr or ALL)> \
<end date (mm/dd/rr or ALL)> <patchtype/ALL> <language/ALL> \
<appltop/ALL> <limit to forms server? (Y/N)> \
<limit to web server?(Y/N)> \
<limit to node server? (Y/N)> \
<limit to admin server?(Y/N)> \
<only patches that change DB? (Y/N)>
Example: To get the complete file version history for admorgb.pls
considering only patches applied in Dec 2000:
On UNIX:
$ cd $AD_TOP/patch/115/sql
$ sqlplus <APPS username>/<APPS password>
SQL>
On NT:
C:\> cd %AD_TOP%\patch\115\sql
C:\> sqlplus <APPS username>/<APPS password>
SQL>
3. Stopping adpatch while the initial questions are being answered
If the final adpatch question has not been answered, then adpatch can be stopped at any time by typing ‘abort’ as the answer for any question. This will stop the adpatch session. The next time adpatch is run, it will ask if you want to continue your last session.
4. Stopping adpatch after it has begun running
If a D driver is being applied, and it has spawned workers, it can be stopped by using the program ‘adctrl’. Adctrl allows you to stop adpatch while it is running. It can also be used to monitor adpatch and restart adworkers after they have failed. For more details consult the Maintaining Oracle Applications Manual.
Otherwise, there is not a way to gracefully stop the adpatch process, other than killing the process, so the best practice is to let it run to completion.
5. Always check for invalids, and recompile if necessary after applying a patch
If a ‘d’ or database driver is used while applying a patch, the database should be checked for invalids afterwards. Many times patches will create invalid objects, and this could prevent the patch from fixing the issue it was correcting, or cause other problems.
A new feature has been added to adpatch in R11i. This feature is not in the base release, but is added by a patch. Any AD.F Mini Pack or greater will introduce this new feature. With the new feature, at the beginning of adpatch it will create a file in the log directory, for example 01361_preenv.lst. This file will list all invalid APPS objects in the database. Then at the end of adpatch, it will create another file that lists the invalid APPS objects after applying the patch.
Checking for Invalids:
Select owner, object_name, object_type from dba_objects where status = ‘INVALID’;
Compiling Invalid Objects:
Following are some options for compiling invalid objects.
· Use adadmin to run ‘Compile Apps Schema’. Good to use if there is a large number of invalid objects, because it compiles invalids for all APPS products.
· $AD_TOP/sql/adcompsc.pls is a script that development will sometimes include as one of the last jobs run by the ‘d’ driver. This script allows you to compile invalid objects in a given schema.
Þ To run the script use the syntax
SQL> @adcompsc.pls <schema_username> <schema_password> <objects starting with>
Examples:
SQL> @adcompsc.pls apps apps PA (This will compile all the objects in Apps starting with PA%)
SQL> @adcompsc.pls ap ap % (This will compile all objects in the AP schema)
· Recompile and recompile.sql. These are custom scripts that were created by a support analyst at Oracle. The script selects all invalid objects and dynamically creates ‘alter’ scripts to compile each of these invalid objects, then runs the scripts. For examples of these scripts look in the reference section, on page 30.
· Use alter command in sql:
ex: alter package ARP_STANARD compile body;
alter package ARP_STANARD compile;
alter view TABLE_V compile;
alter java class “/584c2e1f_FunctionManager1” compile;
If you find an object with the object_type UNDEFINED, then you might want to try...
alter snapshot object_name compile;
· If you have invalid SYSTEM or SYS objects you can use $ORACLE_HOME/rdbms/admin/utlrp.sql to compile just these invalid objects.
6. Where are the log files for the patch process stored?
The log files that are generated during the patch process are stored in $APPL_TOP/admin/<ORACLE_SID>/log
7. Other adpatch application options
There are a few different modes in which adpatch can be run.
Test Mode
Test mode will display all the files adpatch will replace and the actions it will take, but does not actually apply the patch. The syntax for using this mode is:
$ adpatch apply=no
This is useful if the user wants to know exactly what a patch will do before applying the patch. For example, if the user is concerned about customizations being replaced.
Pre-AutoInstall Mode
There are times when Oracle may require the install of a patch before running AutoInstall to install or upgrade Oracle Applications. The patch usually updates AutoInstall itself or one of the utilities it calls during the installation. The syntax for this mode is:
$ adpatch preinstall=y
Non Interactive Mode
As mentioned earlier in the document, this is a mode where you can apply all of the drivers with one adpatch command, rather than running adpatch several times. To do this you must create an AutoPatch defaults file, which contains information for running adpatch against the different drivers. Consult the Maintaining Oracle Applications document for the details on running adpatch in this mode. It is a fairly simple process, but the directions are more than I would like to add to this document.
Options parameter
The options parameter can be used to enable or disable certain functions during application of the patch. For example, you may want to prevent forms and libraries from being generated during the application of a patch. The syntax for this would be:
$ adpatch options=nogenrep,nogenrpll
AD Merge option
AD Merge Patch is a process that merges multiple compatible patches into one integrated patch.
The command that is used is admrgpch. Once again, for details consult the Maintaining Oracle Applications document. This is a very useful feature if a large number of patches need to be applied at one time.
Full details on all of the available options are in Maintaining Oracle Applications manual.
8. IMPORTANT: Other log files generated by adpatch
If a patch process errors, the first step is to find the error that caused the failure. This error may not be in the main log file (the log name that is entered by the user at the start of adpatch). When a patch is applied, it may generate other log files besides the log name that is entered at the start of adpatch.
Following are some log files that may also be updated by the patch.
· adlibin.log (libin commands)
· adlibout.log (libout commands)
· admvcode.log (copying files to destination)
· adrelink.log (relinking executables)
· adwork01.log (adwork02.log, adwork03.log, etc. Depending on # workers used.
Generated by the D and G drivers)
· .req files (Some processes may generate .req files. There are numerous different commands that generate a .req file. Below is one example. This line was found in a adwork01.log file.
/u02/applsean/FRESH/fnd/6.1.1/bin/FNDMDGEN APPS/APPS 0 Y US PO SCRIPT_TO_DB po
patchsc/107/import/po10sc.msg
Log filename : /u02/applsean/FRESH/install/log/l1189.req (Review this file for the error)
Report filename : /u02/applsean/FRESH/install/out/ANONYMOU.1189
Providing log files to Support
If a problem is encountered while applying a patch, be prepared to provide the appropriate log files before calling Oracle Support. This will help expedite the resolution of the issue. Since most of the log files are appended by each patch applied, these log files may be very large. If so, there are ways to extract the section that shows the error.
One option is to pull up the file with vi, or an editor, and cut the appropriate section out into a smaller document. If this method is used, be sure to include about a page before and after the error to assure that all important information is included. Sometimes important information, or other errors are included before or after the most obvious error.
Another nice option is to backup/rename the log file that is needed and reapply the patch to get the error. For example, a patch is failing during relinking.
a. First backup the current log file
mv adrelink.log adrelink.bk
b. Rerun the patch so that it will error again.
c. A new adrelink.log file will be created that only contains info from the current patch.
d. Rename this new log file, then restore the backup.
e. This file will contain only the errors from this patch, and will not be as large as the original log file.
9. What is the j<patchnumber>.zip file that exists in some 11i patches?
You may find this type of zip file when applying Java patches in 11i. These zip files are known as
a Zipped Resource Unit. You do NOT have to unzip this file. It will be applied by the ‘c’ driver when adpatch is run. Somewhere in the ‘c’ driver will be a ‘jcopy’ command. The jcopy command removes the contents of the .zip file and merges them into your apps.zip file, which is located in the $AU_TOP/java directory. This jcopy command replaces the old class files with new ones found in the .zip file from the patch. Your apps.zip file in your $JAVA_TOP will also be updated by the jcopy command.
10. Job Timing Report
Adpatch also creates a ‘Job Timing Report’ which provides time statistics on the application of the
patch. This report includes useful information, such as...
· Which jobs took the longest, and how long each one took.
· Timing information for each patch phase
· Percent usage by product
· Percent usage by phase and product
This report is placed into the $APPL_TOP/admin/<SID>/out directory. You should see a line like the following at the end of the adpatch log file.
A job timing report has been generated for the current session. You should check the file
/u02/applmgr/prodappl/admin/PROD/out/adt01361.lst
11. Auto Restart when workers during D driver fail
Most d drivers will spawn adworkers to run jobs in parallel. As discussed previously, when the
workers fail, you can restart them via adctrl. However, adpatch also has a feature that will restart
the failed jobs for you.
When all the jobs are in a ‘failed’ or ‘waiting’ status, adpatch will automatically restart all the
failed jobs one time. If the jobs then fail again, adpatch will stay in the failed status until the
problem is resolved and the workers are restarted using adctrl.
Sometimes, a job may fail due to a database lock on a table, or because it is dependent on another job that has not completed yet. This auto restart function should correct these type of errors, and allow the patch to continue without user intervention.
VIII. Explanation of Driver Files
Driver files, or .drv files, are files that adpatch uses to determine what jobs to perform. The following section provides a basic explanation on how to read a driver file and understand the jobs it will perform.
A. Copy driver, cXXXXXX.drv
The copy driver is the first driver, which must be run using adpatch. This driver will do the following functions.
a) copy the files from the patch to the appropriate directory
b) relink executables
c) regenerate jar files
The general form of a driver command line is:
<command> <product> <subdirectory> <file> <other arguments…>
Some of the common <command>s that are used are:
Copy copy file into target sub-directory with version checking
forcecopy copy file into target sub-directory without version checking
libout extract object module from library
libin put object module into library
genform generate form
genrep generate report
genrpll generate Oracle Reports PL/SQL file and copy to $AU_TOP/plsql
link relink executable
exec run executable program
sql Run SQL script.
copy ap forms/US APXIISIM.fmb 110.8
Driver will check the versions of APXIISIM.fmb on your system. If it is less than 110.8, then it will
copy this file to the $AU_TOP/forms/US directory.
IMPORTANT NOTE: This file is copied to $AU_TOP, not $AP_TOP, even though it is an AP form. ALL forms, or .fmb files, copied to $AU_TOP/forms. These are the text files. Then when the g driver is run, these binary files are generate, and the form executable or .fmx is generated. This .fmx is then stored in $AP_TOP/forms, or the appropriate $XX_TOP/forms directory.
copy ap patch/110/sql apaiithb.pls 110.2
Driver will check the versions of apaiithb.pls on your system. If it is less than 110.2, then it will copy this file to the $AP_TOP/patch/110/sql directory.
copy fnd resource JE.pll 110.8
Driver will check the versions of JE.pll on your system. If it is less than 110.8, then it will copy this file to the $AU_TOP/resource directory.
IMPORTANT NOTE: Again, note that the file is copied to $AU_TOP, just like the .frm file. However, the difference with form library files, or .pll files, is that when they are generated the executable file, .plx, remains in the same $AU_TOP/resource directory.
libout ar lib arstax.o
copy ar lib arstax.o 70.143
libin ar lib arstax.o
Driver will first extract the .o file from your libar.a file in $AR_TOP/lib (libout). It then performs a
version check. If the current version is less than 70.143 it copies the .o file from the patch to
$AR_TOP/lib (copy). It then inserts the .o file back into libar.a (libin). Later, when the patch relinks
the executables, the libar.a file is used, and the new file will be linked into the executable.
link fnd bin aiad
Relink the executable $FND_TOP/bin/aiad.
link oe bin OEBSHC
Relink the executable $OE_TOP/bin/OEBSHC
Following is a simple explanation of ‘relink’:
Executables are numerous C modules bundled together to create the executable. Linking, or adrelink, is the process that bundles all the necessary C modules together to create the executable. In order for the new C code, or object files (arstax.o for example) to take affect, they not only have to be inserted in the product’s C library (libar.a or libap.a), but the executables that use this C code must be relinked. This command is the same as if you ran the following commands from the o/s.
adrelink force=y “oe oebshc”
jcopy
You might find a jcopy command in a R11i patch if it is updating Java files. This command is explained in the Additional Patch Information section on page 21.
B. Database driver, dXXXXXX.drv
This is the driver that runs .sql, .pls, .odf and other files that update the database. As mentioned previously, some common ways the database is updated by the this driver are:
· 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
The database driver uses the same command structure:
<command> <product> <subdirectory> <file> <other arguments…>
However, as you will see, it uses the <other arguments> section much more. There are numerous different arguments that can be used, but following are some more common examples:
sql Run the script directly from the worker
sqlplus Spawn a new sqlplus session and run the script
package Same as sqlplus but performs package version checking
Another argument you may see at the end of the command string is a ‘phase’ command. Before performing any actions, adpatch divides all actions contained in the patch driver file into phases based on information specified in the patch driver. Adpatch performs all actions grouped in one phase in parallel before proceeding to the next.
Many ‘d’ drivers in patches contain phase definitions that determine what order the files in the driver will run. If the driver does not contain any phase definitions, then the files are executed in the order they appear in the driver.
Following are a few examples of types of phases.
Phase name Action taken
seq Create sequences
tab Create tables and indexes
pls Create package specifications (specs)
vw Create Views
plb Create package bodies
Following are some examples of common commands found in a dXXXXXX.drv driver, and a brief explanation.
sql ar patch/115/sql b512706a.sql !AR_PERIOD_TYPES &un_ar &pw_ar sql &phase=tab
Run the sql script $AR_TOP/patch/115/sql/b512706a.sql using the ar username and password. The
!AR_PERIOD_TYPES is anoy the .sql script. As discussed previously the
&phase argument specifies what type of action this script is doing, and when the script will be executed
by the driver.
sql ar patch/115/sql ARTEHPCS.pls none none none package &phase=pls
Run the script $AR_TOP/patch/115/sql/ARTEHPCS.pls which creates a package (phase=pls).
sql ar patch/115/sql artcall5.sql none none none sqlplus &phase=tbm+5 &un_ar &pw_ar
Run the script $AR_TOP/patch/115/sql/artcall5.sql. The +5 is a way of determining the order a script
will run within a phase. For example, within a phase, commands would be run in the following order:
&phase=tbm
&phase=tbm+5
&phase=tbm+99
exec ad patch/115/odf adutil.odf odf &phase=seq mode=sequences
This command will run the adutil.odf file. .odf files are files that create or update the structure of tables, sequences and views. This command is being run in ‘mode=sequences’, so it will be creating sequences with this command.
C. Generate Driver, gXXXXXX.drv
Following are some examples of commands in a ‘g’ driver. Once again, remember that
· The .fmb files are stored in $AU_TOP, and when generated the executable (.fmx) is stored under the product.
· The .pll is stored under $AU_TOP, and when generated the executable (.plx) is also stored under $AU_TOP.
genform ap forms/US APXIISIM.fmb
Generate the form $AU_TOP/forms/US/APXIISIM.fmb and store the executable in $AP_TOP/forms/US/APXIISIM.fmx
genrep ap reports APXIIADV.rdf
Generate the report $AP_TOP/reports/APXIIADV.rdf, and store the resulting file APXIIADV.rdf in the same directory.
genfpll fnd resource JE.pll
Generate the PL/SQL library $AU_TOP/resource/JE.pll, and store the executable JE.plx in $AU_TOP/resource.
D. Other Commands
Following are some other commands that may be found in a driver file. Once again, this does not cover all commands that may be found in a driver file, but these are some common ones that may be of interest.
compatible release 11.5.0
This command checks the release the customer is on to verify they are applying the correct
patch. Patches are specific to release versions. That is why when you will see separate ARU
checkins by release, and have to specify a release when requesting an ARU.
compatible parallel yes
compatible parallel no
This command determines if parallel mode will be used when applying the patch. Parallel mode
works essentially the same was AutoInstall, where it starts up workers and the workers execute
certain commands.
compatible platform
Prevents customers from applying patches for an incorrect platform.
compatible language
Prevents customers from applying patches for an incorrect language.
compatible translation_required
When applying a US patch, informs users when language patches may be required in addition to the current patch.
X. Recompile and Recompile.sql scripts.
Following are examples of the recompile scripts and instructions on implementing
recompile
sqlplus system/manager
rm -Rf /tmp/recompile-sql.sql recompile.sql column owner format a1 noprint column object_name format a1 noprint column order_col format a1 noprint column cmd format a132 set heading off set pagesize 0 set linesize 180 set echo off set feedback off spool recompile-sql.sql select 'set echo on' from dual; select 'spool recompile.lis' from dual; select distinct 'alter session set current_schema=' || owner || ';' cmd, owner, 1 order_col, NULL object_name from dba_objects where status = 'INVALID' and object_type in ('PACKAGE','PACKAGE BODY','VIEW','PROCEDURE', 'FUNCTION','TRIGGER','TYPE','TYPE BODY','INDEXTYPE', 'JAVA CLASS') union select 'ALTER ' || decode(object_type, 'PACKAGE BODY', 'PACKAGE', 'TYPE BODY', 'TYPE', object_type) || ' ' || owner || '.' || '"' || object_name || '"' || ' COMPILE' || decode(object_type, 'PACKAGE BODY', ' BODY', 'TYPE BODY', ' BODY':p> ';' cmd, owner, 2 order_col, object_name from dba_objects outer where status = 'INVALID' and object_type in ('PACKAGE','PACKAGE BODY','VIEW','PROCEDURE', 'FUNCTION','TRIGGER','TYPE','TYPE BODY','INDEXTYPE', 'JAVA CLASS') and (object_type <> 'PACKAGE BODY' or not exists (select null from dba_objects where owner = outer.owner and object_name = outer.object_name and object_type = 'PACKAGE' and status = 'INVALID')) and (object_type <> 'TYPE BODY' or not exists (select null from dba_objects where owner = outer.owner and object_name = outer.object_name and object_type = 'TYPE' and status = 'INVALID')) order by 2,3,4 / select 'exit;' from dual; spool off; set heading on set feedback on set pagesize 9999 set linesize 80 @recompile-sql Instructions 1. create recompile and recompile.sql scripts from the above examples. 2. Modify recompile file, putting the correct address on your system where you are storing recompile.sql 3. chmod 777 recompile (or make recompile an executable file) 4. run recompile $ recompile [return]