Adpatch Basic Release 11i

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


(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


(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


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


Do you currently have concurrent program files installed


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.


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.


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 ModeAs 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 optionAD 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]

Adpatch Basic Release 11i

Documents

Transcript of Adpatch Basic Release 11i