Patches
Patches
Structure Of 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.
When you unzip a patch you will see some files types :
readme.txt - This file contain steps to spply patches, List of Prerequisite patch should be
there on apps Instance (If not apply that patch )
cXXXXXXX.drv c stand for copy driver file , this copies patch content to respective
patch location , driver is like bus driver which provides instruction on work adpatch need
to perform.
dXXXXXXX.drv d stand for Database driver & contain content related to database like
creating packages, tables, adding column….
gXXXXXXX.drv This contain files related to forms , reports, graphis or messages
uXXXXXXX.drv Sometime these three types of files are bundled together into single
driver file called Unified driver file .
AUTOPATCH MODES
Patch information is stored in the database only if the update is run in normal mode.
Patch information is not stored immediately in the database when run in pre-install and
not stored at all when run in test mode. If the update does not complete successfully, the
patch information is not uploaded to the database nor is it written to the Patch History
file.
Normal mode
$adpatch
When AutoPatch is run in normal mode, all patch history information is directly uploaded
to the database.
Test mode
$adpatch apply=no
When AutoPatch is run in test mode, no upload of applptch.txt occurs and patch history
information is not stored. The Patch History file is not changed.
Pre-install mode
$adpatch preinstall=y
As AutoPatch does not connect to the database in pre-install mode, the patch information
is not directly uploaded to the database. In pre-install mode AutoPatch writes patch
history information to the Patch History file. The contents of this file are uploaded to the
database the next time AutoPatch is run in normal mode.
Non-interactive mode
The patch history database feature does not distinguish between interactive and non-
interactive mode. Whether or not patch history information is stored in the database is
determined by the operational mode used: Normal, Test, or Preinstall.
STEP 2 :Before applying a patch you must check whether the patch is already there or
not. For this we query the database:
This will unzip the patch in current directory & will make the required patch directories
& sub directories.
STEP 5 : down the application services and Enable the Maintenance Mode.
STEP 5: Run autopatch from the patch directory by entering the following command:
$ adpatch
Location : $APPL_TOP/admin/<SID>/log
$adpatch options=nodatabaseportion,nodatabaseportion,nogenerateportion
Usage of Admerging
1. patchnumber.log ($APPL_TOP/admin/SID/LOG/patchnumber.log)
2. patchnumber.lgi($APPL_TOP/admin/SID/LOG/patchnumber.lgi)
3. adworker.log($APPL_TOP/admin/SID/LOG/adworker001.log
4. l.req($APPL_TOP/admin/SID/LOG/l1248097.req)
5. adrelink.log($APPL_TOP/admin/SID/LOG/adrelink.log)
6. adrelink.lsv($APPL_TOP/admin/SID/LOG/adrelink.lsv)
7.autoconfig.log($APPL_TOP/admin/SID/LOG/autoconfig_3307.log)
Errors;
-- Preinstall steps
1. Create $ORACLE_HOME/appsutil/admin on the
database server.
2. Copy adgrants.sql (UNIX) from this patch
directory to
$ORACLE_HOME/appsutil/admin.
Or, copy adgrants_nt.sql (Windows) from this patch
directory to
%ORACLE_HOME%\appsutil\admin.
[oracle@erp admin]$ mkdir -p
$ORACLE_HOME/appsutil/admin
[oracle@erp admin]$ cp
/d02/oracle/R12_R1206/7305220/admin/adgrants.sql
.
3. Set the environment to point to ORACLE_HOME on
the database
server.
4. Use SQL*Plus to run the script:
UNIX:
$ sqlplus /nolog
SQL> connect / as sysdba
SQL> @$ORACLE_HOME/appsutil/admin/adgrants.sql
<APPLSYS schema
name>
sqlplus "/as sysdba" @adgrants apps