0% found this document useful (0 votes)
55 views

Oracle APPS Patches

hchgvchgvchg

Uploaded by

pravin2projects
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
55 views

Oracle APPS Patches

hchgvchgvchg

Uploaded by

pravin2projects
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 4

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 ) so To wind up things you can say few one off patch make mini pack , few mini pack related to same family bundeled together as family pack & all family pack fixed till that time are bundeled in Maintenance pack . Oh wait I forgot to tell about NLS Patch ( When you have more than one language , like english & arabic or french .. ) then apart from normal patch you have to apply patch for specific language Installed in your system called as NLS patch ( What is NLS or MLS coming soon ..) As Oracle Apps DBA patching is quite basic thing you do regularly so lets continue with basics . If you have not gone through my previous posts please do so now as its quite important to through basics . Apps patches are buldled somthing like p123456_11i_Unix.zip where p menas patch next few digit are patch number Unix is platform or OS on which this patch can be applied. When you unzip a patch you will see some files types which I am explaining here 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 So now you know which type of driver file to apply where ? its common sense if this is d driver you just need to apply once on concurrent manager tier and c & g on all tiers as database is single & if you run it once its enough . If you applied it again by mistake its no harm & will not cause any issues . Similary c & g you need to apply from all tiers , because c will copy your content & g will generate message files. If you are not sure where to apply what just apply it on all tiers & depending on your context file in APPL_TOP/admin/SID_hostname.xml it will apply where to install what by checking xml tag

TIER_ADFORMS , TIER_ADWEB , TIER_ADADMIN open your xml file & see these parameters are there or not ( For xml file your system should be Autoconfig enabled ) all system after 11.5.8 by default are autoconfig enabled . For more info on Autoconfig check

Cloning is the act of creating an identical copy of an already existing Oracle Applications system. Simply copying all of the components from source to target system does not provide us a working Oracle Applications system, there are various configuration files that must be changed & for this purpose we do Cloning. Do keep in mind that the new system & the existing system must have same component versions & operating system type (You cant clone from windows to linux or Solaris). Performing Cloning prerequisites steps: We need to perform certain prerequisites steps before cloning the source system: STEP 1Login as Applications file user & run the environment file. STEP 2 We need to check certain software component versions: (i) Check the version of perl, it should be atleast 5.005 or above. To check perl version, Type the following command$ perl -v Make sure that perl is included in the PATH (environment variable of user; echo $PATH). (ii)Check the version of JRE & JDK which should be atleast 1.1.8 & 1.3.1 or above respectively. for this type: $ java -version (iii) Check the version of zip which should be atleast 2.3 or above.for this type : $ zip If you dont have following versions, upgrade these software components as per the operating system. STEP 3: It is recommendedto apply the latest AD Minipack & the latest AutoConfig Template patch as mentioned in the metalink note 230672.1 but not necessary.

STEP 4:Then we check whether latest Rapid Clone patch is there or not, for this we query the database whether latest Rapid Clone patch and other prerequisite patches as mentioned in the metalink document 230672.1 as follows: $ select * from AD_BUGS where bug_number=&patch number; If it shows no rows selected that means you need to apply the patch. Do ensure that you apply all the patches as per the requirement. STEP 5: If your system is autoconfig enable configure the application tier by running the adautocfg.sh script as follows: $ cd $COMMON_TOP/admin/scripts/<$CONTEXT_NAME>/ $adautocfg.sh If your system is not autoconfig enable then set up the autoconfig on application tier with the help of metalink document 165195.1 ( Migrating to AutoConfig on the Applications Tier). NOTE:

To check whether your system is AutoConfig enable or not , open any configuration file, if you see the text This file is automatically generated by AutoConfig.at the top,this mean your system is autoconfig enabled. Also all the applications after 11.5.7 are autoconfig enabled.

STEP 6:Now we set up AutoConfig on the database tier. For this we need to copy AutoConfig to the RDBMS ORACLE_HOME as follows: login as Applmgr . Set up the environment file & create appsutil.zip file in AD_TOP by typing the following command: $ perl $AD_TOP/bin/admkappsutil.pl This creates appsutil.zip in the $APPL_TOP/admin/out directory. Now login as Oracle on the database tier & copy the appsutil.zip file to the <RDBMS ORACLE_HOME> and unzip it: $ cd <RDBMS ORACLE_HOME> $ cp $APPL_TOP/admin/out/appsutil.zip $ unzip -o appsutil.zip (Option -o will overwrite any existing appsutil directory in database ORACLE_HOME) Now run AutoConfig on the database tier: $ cd <RDBMS ORACLE_HOME>/appsutil/scripts/<context_name>/adautocfg.sh
Based on lot of request I am discussing on Shared APPL_TOP & Shared Application Tier. For next few days I will start with basics of Shared APPL_TOP like what's is Shared APPL_TOP ?

Advantages of Shared APPL_TOP ? Difference between Shared APPL_TOP & Application Tier Difference between Shared APPL_TOP & Staged APPL_TOP How to Implement Shared APPL_TOP in Oracle Apps ? So rather than talking too much lets start with Shared APPL_TOP & Application Tier . In order to understand concept of shared APPL_TOP you first need to know what is APPL_TOP & what are various other TOP's in Oracle Apps . Oracle Apps File System (Software ) is mainly divided in to five top level directories DATA_TOP : For data file (Database Tier ) DB_TOP : Database Software 8i, 9i or 10g ( Database Tier ) APPL_TOP : For various product tops (Application Tier ) COMMON_TOP : for files & directories common to all products ( Application Tier ) ORA_TOP : for iAS, Forms & Reports Component , Tech. Stack ( Application Tier ) Why I need shared APPL_TOP ? If you have two/three (Multiple) Middle Tier for Large User base then you have to install APPL_TOP, COMMON_TOP & ORA_TOP equal to number of Nodes in your configuration. So if you have three middle tier then you need these three top three times & if there are n nodes you need n time these three top's . This result in lots of Space Requirement & bigger problem is patching so If you have 5 nodes you need to apply apps patch 5 times. So Oracle Came Up with solution to have single APPL_TOP which is shared across all nodes in apps. This will save space as well patch timing. This concept of sharing APPL_TOP file system across all Middle Tier Nodes is called as APPL_TOP . You will say if I can share APPL_TOP why Can't I share COMMON_TOP & ORA_TOP as well which are also part of Application Tier , Yes you can & this concept is called as Shared Application Tier. What is Shared Application Tier ? Sharing Application Tier ( including APPL_TOP, COMN_TOP, ORA_TOP) across all Middle Tier Nodes in configuration is called as Shared Application Tier. So I can say shared APPL_TOP is subset of shared Application Tier , initially shared APPL_TOP came out & based on its advantages & popularity later COMMON_TOP & ORA_TOP files were also included & entire concept is called as Shared Application Tier. Limitation with Shared APPL_TOP , Application Tier ? If you are running Apps on Windows you'll be sad to hear that its not certified with Windows Operation System. More over you can share across same operation system like Linux to Linux & Solaris to Solaris.

You might also like