11i Ptaching

Patch is program (set of instructions) to fix a particular problem or enhance/ add a particular feature in existing program/product/software.

In Oracle Applications 11i to apply database patch you use opatch where as in order to apply applications patch you use ad utility adpatch

These are major classification of oracle apps patch

• Standalone/Oneoff patches This is used to define patch created to fix single/particular problem.
•  Mini Pack This is group of oneoff patches for a particular product like INV, GL, AP and named like 11i.GL.E ( means this group of patches contain fix for 11i GL product (General Ledger till time E is released ) This is cummutative which means it will include 11i.GL.A, 11i.GL.B ....11iGL.D till 11i.GL.E earlier in 10.7 it used to called as patchset.
•  Family Pack Group of mini packs in one family buldeled together is called as family pack. they are usually named as 11i_PF. Few example of falilies are SCM ( 11i.SCM_PF.G ), ATG ( 11i.ATG_PF.H ) _PF indicate Product Family Pack
•  Maintenance Pack Group of family pack together is called as maintenance pack. So if you say your Verison is 11.5.10 then its maintenance pack 10 ( 3rd digit is maintenance pack )

What are c,d,g and Unified Driver in a Patch

The unzipped patch contains three drivers “c,d,g” or “u”. These are called copy,database,generate drivers or Unified drivers. The unified driver is the combination of all the three c,d,g drivers.

Now we will try to understand the drivers one by one.

Always read the readme.txt.  In general for Release 11, patches can include three different drivers: "c", "d" and "g". The "C" drivers (copy) are file system drivers, these are used to update the file system with the new versions of certain files.  The "D" drivers are database drivers and they run SQL scripts that update database tables and objects.  The "G" (generate) drivers are also file system drivers, they generate forms and reports. These drivers are run in alphabetical order c, d, then g.  If they are run out of order, rerun them in the correct order.

C driver:

The "c" (copy) driver updates the file system.  Below is a portion of a patch and an explanation of the activities  within the patch.

               copy            fnd    admin/sql   fnddold.sql  110.4
               copy            fnd    forms/US    FNDADDTC.fmb 110.4
               libout          fnd    lib               afdict.o
               copy            fnd    lib               afdict.o110.1
               libin             fnd    lib              afdict.o
               forcecopy    fnd    media        FNDIEROR.gif
               link              fnd    bin             FNDCLOAD  

copy            fnd    admin/sql   fnddold.sql  110.4
copy            fnd    forms/US    FNDADDTC.fmb 110.4

ADPATCH performs version checks allowing it to not overlay a higher version object or sql files.  If the version on the file system is the same or higher it skips the copy. In the above example, notice the version to the right of the filename.  It uses this version to do the compare.  The "fnd" next to the copy tells ADPATCH what applications top to use and "forms" points adpatch to the proper directory. With the above statement ADPATCH will copy the file FNDADDTC.fmb (from patch directory) to $FND_TOP/forms.The copy actually moves the existing FNDADDTC.fmb file to FNDADDTC.fmbO and then physically copies the new file version to FNDADDTC.fmb.  The file FNDADDTC.fmbO will

remain on the file system. 

forcecopy    fnd  media  FNDIEROR.gif

Similar to copy, but no version checking is done. Forcecopy copies the target file irregardless of the presence or version of the file currently on the target system.

link  fnd  bin  FNDCLOAD

The link process is similar to a compile.  It links new object files together with the other objects files to create the executable.  The command that the above link is using:

 adrelink force=y "fnd FNDCLOAD"

The "fnd" is the top that the executable is being relinked in.  The executable FNDCLOAD has to be in the proper case that it would normally appear in the $FND_TOP/bin directory

D driver:

The "d" (database) drivers alter the tables in the database. These patches can create tables, add indexes and alter the APPS schema. The only way to back-out a 'd' driver is with a database backup. Even if the executables are restored (on the file system), they will not work because information in the database has changed.

G driver:

The "g" (generate) drivers generate forms, .plls (PL/SQL libraries) reports and menus.

The following is an excerpt from a "g" driver:

                 genform      fnd    forms/US         FNDWFNOT.fmb
                 genrep        fnd    reports            FNDCPWKM.rdf
                 genfpll        fnd    resource          JL.pll 

                 genmenu    fnd    resource/US    FNDMENU.mmb

genform uses f60gen to generate forms.

 Syntax is:
                 f60gen userid=APPS/APPS module=<form name>.fmb
                 output_file=<full path of schema top>/forms/US/<form name>.fmx 

                 module_type=form batch=no compile_all=special

genrep uses rwcon60 to generate reports

Syntax is:
     rwcon60 userid=APPS/APPS
     source=/<full path of schema top>/reports/<report name>.rdf
     dest=/<full path of schema top>/reports/<report name>.rdf stype=rdffile 

     dtype=rdffile logfile=<report name>.log overwrite=yes batch=yes dunit=character

genfpll uses f60gen to generate .plls (forms libraries)

Syntax is:
          f60gen userid= APPS/APPS module=<library name>.pll module_type=library  
          output_file=/<full path of schema top> /resource/<library name>.pll

          compile_all=Yes

genmenu uses FNDMDGEN to generate menus

Syntax is:
                 FNDMDGEN APPS/APPS 0 Y <language codename>

                 DB_TO_RUNTIME  <application shortname> <message filename>.msb

Which patches can be backed out should there be a problem?

It is always recommended that you perform a cold backup of a system prior to applying any patch.  It is also recommended that you apply patches to a test system first.  However, for those cases where you have not done these two steps; you should know that database drivers 'd' CANNOT be backed out without a system backup. If the "c" or "g" drivers need to be backed out, reverse the steps from the "c" driver and relink, then reverse the steps from the "g" driver. This will require you to manually review the driver files and create commands that will do the opposite of the process.  There is no utility that you can use to reverse the patch. For the section of the above patch, you need to do the following:

        libout  fnd    lib    afdict.o
        copy    fnd    lib    afdict.o    110
        libin     fnd    lib    afdict.o

   Dearchive afdict.o from libfnd.a, then copy rename afdict.oO to afdict.o  and then archive afdict.o into the library file. 

libout    fnd   lib  afdict.o

      ar -dv  libfnd.a  afdict.o

copy   fnd   lib  afdict.o  110

      To reverse this:

      cp afdict.o0  afdict.o

libin   fnd    lib  afdict.o

      ar -rv libfnd.a afdict.o

      This will place the old object file back into the library file.

link  fnd  bin  FNDCLOAD

       Now the executable needs to be relinked.

       adrelink force=y ranlib=y "fnd FNDCLOAD

copy fnd  forms/US  FNDADDTC.fmb 110.4

       This was the set that copied the file from the patch directory to  $FND_TOP/forms. 

       To reverse it:

        cp  FNDADDTC.fmbO  FNDADDTC.fmb

       Adpatch command to generate the form:

       genform   fnd  forms   FNDADDTC.fmb

       To reverse it:

        f45gen userid=APPS/APPS module= FNDADDTC.fmb
        output_file=$FND_TOP/forms/US/ FNDADDTC.fmx 

        module_type=form batch=no compile_all=special

What log files are generated by ADPATCH and how are they named?

The log file created by ADPATCH is named by the user when they start ADPATCH. So the log filename is user defined.  If the person applying patches does not give it a unique name each time, the log information is appended to the end of the existing file.  That file is located in $APPL_TOP/admin/log and is named adpatch.log. This means that the ADPATCH log file could have references to many patches. Some patches may spawn workers and log file will be generated for each worker. These log files are named in the following way: 

       adwork01.log, adwork02.log, etc... and are located in $APPL_TOP/admin/log.

You have decided to start all over and resubmit ADPATCH from the beginning, but you get the error that FND_INSTALL_PROCESSES already exits.

How is FND_INSTALL_PROCESSES related and why does ADPATCH have a problem with it?

 FND_INSTALL_PROCESSES is a table that is created by RAPID INSTALL, ADPATCH and ADADMIN  utilities. Normally the above utilities will remove this table after they complete. This table might exist if you are running any of the above processes. So, if you are also applying  another application patch at the same time, the table might exist for the other patch. Dropping the FND_INSTALL_PROCESSES table should only be done if you are NOT in the middle of running ADADMIN or applying another patch. Consider this scenario:  You are running the install and you get instructions to obtain a patch (usually this would be an FND patch) and you attempt to use ADPATCH

 to install the patch. If you  were to drop  FND_INSTALL_PROCESSES at this point, you would have to start your install over.  However, you could backup FND_INSTALL_PROCESSES and the restart files.  Then run adpatch to install the patch.  Then restore FND_INSTALL_PROCESSES and the restart files, and continue the installation. If you want to drop the table, you will need to login as the owner of the FND tables.  Normally this is APPLSYS. Then type the following:

               

sql>drop table fnd_install_processes;  

ADPATCH has failed and it indicated there was an error with a worker. What steps can be taken to investigate this problem?

        When ADPATCH is using workers, it (ADPATCH) keeps track of what jobs the workers are doing with a table in the database called FND_INSTALL_PROCESSES. Look at the bottom of the log file associated with the worker that failed (i.e. adwork01.log or adwork02.log  or adwork03.log) There is a utility ADCTRL that can be used to update FND_INSTALL_PROCESSES. This utility will allow you to reset a flag in FND_INSTALL_PROCESSES.  This will allow ADPATCH to restart the failed step.  ADCTRL has a menu with 7 options. ( 8th option is Hidden and it is to skip a worker ) Choose option one on the ADCTRL menu to review the worker status. Other workers will wait for the failed  worker.    Choose option two on the menu to fix the worker.  Place in the worker number and hit return. Check the status of worker again using option one.  The status should have changed to "fixed restart." Try restarting the patch again.  (This assumes you have fixed the problem that caused the worker to fail, increased rollback segments, max extents, etc...)

ADPATCH continues to fail and you have successfully completed the sql statement from the command line. Is there any way to direct the patch to skip this sql and continue?

        Insert the following at the very top of the script that failed:

             exit ;

        Go into ADCTRL and set the worker that failed to fixed/restart (as  above).

        Then restart ADPATCH.

 You want to know if you can reapply a patch.  Will this cause problems?

 You can almost always reapply patches without a problem.  If a patch can not be reapplied, there will be a warning in the README.  However, problems may exist if you are trying to reapply a patch where you have already applied a later version of the same patch.  One example is applying FND Patchset of lower version,then FND Patchset of higher verion and then trying to reapply FND of Patchset lower version. 

 How to find Apps Patchset level in 11i ?

You can use shell script developed called patchsets.sh. Download it from 
ftp://oracle-ftp.oracle.com/apps/patchsets/PATCHSET_COMPARE_TOOL/patchsets.sh 
Usage: patchsets.sh connect=apps/pw [htmlout=file_name] 
Typical Output : Applied Patchsets that Match ARU:
APPLIED PATCHSETS 
Prod Patchset Bug RELEASED Release Status Distribution
=================================================
abm 11i.ABM.D 1741310 31-MAY-01 Patchset Superseded By_Dev 
ad 11i.AD.A 1351004 07-OCT-00 Patchset Superseded By_Metalink
ad 11i.AD.C 1475426 19-JAN-01 Patchset Superseded By_Metalink
To know more about this utility check Metalink Note # 139684.1 Oracle Applications Current Patchset Comparison Utility - patchsets.sh

Q. How to find Apps Version in 11i ?
Run following SQL from apps user ; 
SQL> select RELEASE_NAME from fnd_product_groups; 
You should see output like
RELEASE_NAME
-----------------------
11.5.10.2
Which means you are on Apps Version 11.5.10.2

 Q. How to check if a patch is applied or not ?
Patch information in 11i is stored in AD_BUGS & AD_APPLIED_PATCHES table . You can query like 
SQL> select bug_number from AD_BUGS where bug_number ='&patch_no';
Alternatively you can check patch information from OAM (Oracle Application Manager).

Q. Where to find adpatch log files ?
Patch log files will be in directory $APPL_TOP/admin/$SID/log 
like adpatchXXX.log ( file name you mentioned while patching ), adworkXXX.log for worker log files,

How to Apply an 11i Patch When adpatch is Already Running

1.  Using the adctrl utility, shutdown the workers.
    a. adctrl
    b. Select option 3 "Tell worker to shutdown/quit"
2.  Backup the FND_INSTALL_PROCESSES table which is owned by the APPLSYS schema
    a. sqlplus applsys/<password>
    b. create table fnd_Install_processes_back
       as select * from fnd_Install_processes;
    c. The 2 tables should have the same number of records.
       select count(*) from fnd_Install_processes_back;
       select count(*) from fnd_Install_processes;
3.  Backup the AD_DEFERRED_JOBS table.
    a. sqlplus applsys/<password>
    b. create table AD_DEFERRED_JOBS_back
       as select * from AD_DEFERRED_JOBS;
    c. The 2 tables should have the same number of records.
       select count(*) from AD_DEFERRED_JOBS_back;
       select count(*) from AD_DEFERRED_JOBS;
4.  Backup the .rf9 files located in $APPL_TOP/admin/<SID>/restart directory.
    At this point, the adpatch session should have ended and the cursor should 
    be back at the Unix prompt.
    a. cd $APPL_TOP/admin/<SID>
    b. mv restart restart_back
    c. mkdir restart
5.  Drop the FND_INSTALL_PROCESSES table and the AD_DEFERRED_JOBS table.
    a. sqlplus applsys/<password>
    b. drop table FND_INSTALL_PROCESSES;
    c. drop table AD_DEFERRED_JOBS;
6.  Apply the new patch.
7.  Restore the .rf9 files located in $APPL_TOP/admin/<SID>/restart_back
    directory.
    a. cd $APPL_TOP/admin/<SID>
    b. mv restart restart_<patchnumber>
    c. mv restart_back restart 
8. Restore the FND_INSTALL_PROCESSES table which is owned by the APPLSYS
    schema.
    a. sqlplus applsys/<password>
    b. create table fnd_Install_processes
       as select * from fnd_Install_processes_back;
    c. The 2 tables should have the same number of records.
       select count(*) from fnd_Install_processes;
       select count(*) from fnd_Install_processes_back;
9. Restore the AD_DEFERRED_JOBS table.
    a. sqlplus applsys/<password>
    b. create table AD_DEFERRED_JOBS
       as select * from AD_DEFERRED_JOBS_back;
    c. The 2 tables should have the same number of records.
       select count(*) from AD_DEFERRED_JOBS_back;
       select count(*) from AD_DEFERRED_JOBS;
10. Re-create synonyms
    a. sqlplus apps/apps
    b. create synonym AD_DEFERRED_JOBS for APPLSYS.AD_DEFERRED_JOBS;
    c. create synonym FND_INSTALL_PROCESSES FOR APPLSYS.FND_INSTALL_PROCESSES;
11. Start adpatch, it will resume where it stopped previously.