Oracle Cloud Infrastructure
Coming soon ...
Apps R12.2
  • R12.2 Architecture
  • Cloning Error (RC-50208)
  • Apps R12.1
  • Major changes from 11i
  • R12:HTTP Debug Logging
  • Compile Apps Schema invalid objects in R12
  • Apps 11i
  • Apps Components and Architecture
  • Concurrent managers
  • Patching
  • Using AD Patch
  • Using AD Control
  • FNDCPASS utility
  • Single-node Installation
  • Multi-node Installation
  • Find Apps Version
  • Cloning
  • Upgrade 11.5.9 to 11.5.10.2
  • Upgrade from 11.5.10.2 to R12
  • Upgrading 9i to 10g with 11i
  • 11i/R12 General Topics
  • AppsDBA System Management Utilities Guide
  • Identifying Long Idle Sessions
  • Identifying High Active Sessions
  • Change hostname for EBS
  • Oracle 12c Database
  • Oracle12c PSU Apply
  • Oracle12c Datafile moved Online
  • Oracle 11g Database
  • Upgrade 10g to 11g R1
  • Upgrade 11.2.0.2 to 11.2.0.3
  • Database 9i-10g
  • Top 99 Responsibilities of a DBA
  • General Info
  • Database Patching
  • 10g:ASM
  • 10g:Data Pump
  • 10g:Data Guard Installing
  • 10g:Rollback Monitoring
  • 10g:Flashback Table
  • Tablespace Management
  • Materialized Views
  • 10g:Enterprise Manager
  • 10g:Upgrade
  • Error:Ora-01631
  • DBA Scripts
  • Disk I/O,Events,Waits
  • Tablespace Information
  • Session Statistics
  • Hit/Miss Ratios
  • User Information
  • Rollback Segments
  • Full Table Scans
  • Contention/Locking
  • Redo Log Buffer
  • Data Dictionary Info
  • Oracle10g Application Server
  • Oracle10g Application Installation
  • (Re)Securing OAS Control
  • Oracle AS10g null protocol issue
  • Oracle Backup & Recovery
  • RMAN
  • RMAN Setup
  • Backup Recovery
  • Flash Recovery Area
  • Oracle10g Discoverer with Apps
    Coming soon ..............
    Troubleshooting
  • Discoverer Troubleshooting
  • Access EBS in mozile
  • Linux and Unix Platforms
  • How To configure NFS
  • Unix/Linux Command
  • Change hostname in Linux
  • SENDMAIL configuration
  • This Oracle Application DBA Portal is the biggest knowledge gateway for the people in the world of Oracle...
    Monday, April 6, 2009
    Patching
    Patching

    One of the most important and time-consuming aspects of an Oracle Applications DBA’s job is applying patches to the E-Business Suite. Patches may be required to resolve problems with the application code, to fix production issues, to install new features, or to upgrade components of the technology stack. Patching is not a simple one-step process, but rather requires careful research in order to determine all of the prerequisite steps, patching steps, and post-patching steps required.

    Oracle E-Business Suite patching can be divided into two categories:
    • Oracle Applications patching: This includes all patching that changes
    the underlying Oracle Applications code.
    • Technology stack components patching: This includes all upgrades and fixes for the Oracle Database software, JDK, Oracle Developer 6i (Oracle Forms and Reports), Developer 6i Client library files, Oracle Discoverer, JDBC, Oracle Java Server Page (OJSP), Oracle Application Server (iAS),and iAS Client library files (Required Support Files or RSF).

    The focus of this chapter will be on Oracle Applications patching, and a brief overview of Oracle Database software patching will also be provided. Patching the Applications Technology Stack will not be covered, as this type of patching effort has numerous operating system dependencies.

    Applications Patching
    There are several steps involved in patching Oracle Applications. In this section
    we’ll discuss each of these stages:

    • Preparing to patch: Before patching, it is important to document the requirements and determine what steps and patches are needed. This section will explain how to document and manage the overall process of applying patches, and discuss patch reporting, where you investigate which version, if any, of a patch is currently installed.
    • Applying patches: Applying a patch involves several steps, such as unbundling the patch, enabling maintenance mode, applying the patch with adpatch, and implementing manual steps. This section will discuss each of the steps involved.
    • Monitoring and resolving patching issues: Sometimes there are problems applying patches. This section will explain how to review log files and use the AD Control utility to monitor patch worker processes.
    • Post-patching steps and cleaning up: There are often steps that should be performed after the patching is complete. This section will explain how you can efficiently perform post-patching steps and clean up files no longer required after patching.

    Types of Application Patches
    There are several different types of Oracle Applications patches. These are
    the more common patches:

    • One-off patch: This is the simplest type of patch. It is created to resolve a
    specific bug.
    • Minipack patch: This is a collection of one-off patches and enhancements related to a particular module. Alphabetic characters denote the Minipack version for the module; for example, the product code for the Application DBA utilities is AD, and version Minipack I of this product would be called AD.I.
    • Family Pack patch: This is a collection of Minipack patches for a particular family group of application modules. Alphabetic characters denote the Family Pack version; for example, the J version of the Human Resources Suite Product Family would be HR_PF.J.
    • Maintenance Pack patch: This is a collection of Family Packs that serves as a point-level release upgrade; Oracle Applications Release 11.5.10 is an example of a Maintenance Pack.

    There are also other special types of patches:
    • Consolidated patch: This is a collection of one-off fixes for a Family Pack
    or Maintenance Pack; Oracle Applications 11.5.10 Consolidated Update
    2 (CU2) is an example of a consolidated patch.
    • Interoperability patch: This is a patch that is required for Oracle Applications
    to function with a newer version of a technology stack component; for example, you would apply an interoperability patch when upgrading the database to version 10g.
    • NLS patch: This is a patch that updates language-specific information
    for multi-language installations.
    • Rollup patch: This is a collection of one-off patches that update code
    levels for particular products.
    • Legislative patch: This is a special patch for HR Payroll customers; it
    contains legislative data for multiple countries.

    As the patch group size increases from one-off patches to Maintenance Packs, the complexity of the patch application process also increases. More research is required for Family Packs than is required for a Minipack. Due to the increased complexity, there is more planning required for Maintenance Packs and Family Packs than other patches.

    Preparing to Patch
    Before applying a patch, carefully examine the readme file provided with the
    patch. This document will list all steps required by the patch.

    ■Oracle Application DBA Portal Tip: Before applying a patch, make certain that the readme file has been carefully reviewed.

    The readme file will contain prerequisites, installation steps, postinstallation
    steps, and other information vital to the successful installation of the patch. The prerequisites may consist of other patches or manual steps.

    Here is an example of the readme file contents:

    ---------------------------------------------------------------------
    README CONTENTS:
    ---------------------------------------------------------------------

    A. Prerequisites
    B. Best Practices
    C. Installation Steps
    D. Post-Installation Steps
    E. HRGLOBAL - SPECIAL NOTES AND CHANGE HISTORY
    F. Other Information Sources
    ---------------------------------------------------------------------
    A. PREREQUISITES:
    ---------------------------------------------------------------------
    Apply this patch if you have HR (Product code PER) fully installed.
    Before applying this patch you must have each of these prerequisites:
    1. Oracle Applications Server 11i
    2. Oracle 11i.PER.G, patch 1988754, or later. . . .
    If prerequisites have not been met, you must add these steps or patches to the overall process of applying the patch. Become familiar with all steps required before attempting to apply the patch.

    ■Caution Removing a patch from Oracle Applications after it has been applied is not
    usually a feasible option; therefore, a full system backup should be taken before applying patches to an instance.

    Documenting the Patching Process
    It is recommended that you maintain a spreadsheet detailing all prerequisite
    steps, patching steps, and post-installation steps required for patch application.
    By creating such a document, you can eliminate operator error, such as missed steps or steps completed out of order.

    The columns in the spreadsheet should be customized to match your needs. These columns can include information about the node being patched, details about the patch being applied, or the rationale for the patch. At a minimum, it is useful to have columns for patch number, description, and comments, but it is often also useful to include the actual time required to complete each step based upon trial runs in a sandbox instance. Tracking timings allows for an accurate prediction of production maintenance downtime.

    shows an example of a spreadsheet for patches required by Project A that will require 6 hours and 25 minutes to apply.



    Sample patch documentation spreadsheet

    If timings are included for every step, the Applications DBA can generate a schedule for applying the patches to production by using time functions in the spreadsheet software. This corresponds to the Shift Start Time column in This process is highly recommended for extended patching efforts that will require multiple shifts. Otherwise, a simple summation of the time required for each step should provide an accurate schedule. The times required for applying patches is also tracked by adpatch and can be found in the $APPL_TOP/admin/$CONTEXT_NAME.out/adt*.lst files.

    ■Oracle Application DBA portal Tip: When documenting the patching process for multiple patches, post-installation

    steps like recompiling invalid objects, regenerating JAR files, and running the autoconfig utility can be consolidated and executed at the end of the patching process. This helps to streamline the patch process and reduce downtime.

    Patch Reporting
    Patch reporting is used to determine whether or not a specific patch has already been applied to the instance, or what version of a Family Pack or Minipack is currently installed. The following sections will discuss four methods for determining patching levels:
    • Using the adphrept.sql script
    • Executing the patchsets.sh utility
    • Querying the database
    • Using Oracle Application Manager (OAM)

    Using adphrept.sql
    The $AD_TOP/patch/115/sql/adphrept.sql file is an Oracle-provided script for generating a patch report for an instance. This script provides an easily searchable list of all patches that have been applied to an environment. Keep in mind that the script can take a long time to execute. Additional details regarding adphrept.sql and a description of all parameters can be obtained by viewing MetaLink Note 162498.1.

    Using patchsets.sh
    The Oracle-provided patch-comparison utility, patchsets.sh, is a handy tool for reviewing patchset levels. Family Pack versions, fully installed products, and shared installed products, along with the latest version available, are displayed in the output. Information about the latest version of this utility can be reviewed in MetaLink Note 139684.1.

    Querying the Database for Patches
    In order to determine whether a specific patch has been applied, a query can be executed against the bug_number table. The following SQL will return results if the patches included in the IN clause have been applied to the
    instance:
    SELECT bug_number
    FROM ad_bugs
    WHERE bug_number IN ('patch_number', 'patch_number', . . .)
    ORDER BY bug_number DESC;

    Using OAM
    Oracle Application Manager (OAM) may also be used to query the instance for applied patches.

    Labels:

    posted by Srinivasan .R @ 3:22 AM  
    8 Comments:
    Post a Comment
    << Home
     
    About Me

    Name: Srinivasan .R
    Home: Chennai, India

    About Me:
    I am working as an Oracle Applications DBA specializing in EBS 11i/R12 with Over 14+ years of experience, mainly in different versions of Oracle Database & Application administration on various platforms like HP-UX, SOLARIS, AIX, Red hat Linux & Windows
    See my complete profile
    High Availability
  • Oracle10g RAC Installation
  • A Quick Reference for Oracle Database 10g RAC on Linux and Unix Platforms
  • Implementing Oracle 10g RAC with ASM on AIX
  • Locked objects for whole RAC
  • Monitor Memory RAC
  • Sessions RAC
  • Install Oracle 11g RAC On Linux
  • Migrating Oracle10g DB to ASM
  • Helpful Links
  • Good Metalink Notes
  • Discoverer:Metalink Notes
  • Logs Scripts:Metalink Notes
  • Support:Metalink Notes
  • Previous Post
  • Enterprise Manager 10g
  • Materialized Views
  • RMAN
  • Automatic Storage Management
  • 10g:Flashback Table
  • Tablespace Management
  • 10g:Rollback Monitoring
  • How To configure NFS
  • Find Apps Version (11i/R12/12i)
  • Oracle10g:Grid Control Installing
  • Archives
    Download Software
  • Oracle 11g
  • Oracle 10g
  • 10g Express Edition
  • Oracle 9i
  • Oracle Apps
  • Oracle Linux
  • Oracle VM
  • App Server
  • Solaris
  • Fedora
  • Fedora
  • OpenSUSE
  • Ubuntu
  • Advertisement Links
    INTUIT Technology

    MACHS DATA

    Add Ons
    Locations of visitors to this page

    Add to Google Reader or Homepage

    Template by
    Sreene



    Oracle Application DBA Portal