Handling Customizations in an Online Patching-Enabled Environment


This chapter introduces the essentials of Online Patching for developers working on Oracle E-Business Suite customizations. Online Patching greatly reduces (but does not completely eliminate) the often lengthy periods of downtime previously needed to apply patches of various kinds. While a patch is being applied, the production application remains available and fully operational, significantly reducing downtime.

Online Patching is enabled by use of the Oracle 11gR2 Database Edition-Based Redefinition (EBR) feature. In EBR, database patch actions are performed on a patch edition (virtual copy) of the production system.

Three key points are:

Online Patching Considerations

Online patching is performed in four distinct phases:

As well as allowing patch edition copies of application code and data to be created, EBR must also apply the appropriate patch transformations to any data in the run edition that changes while the patch is being applied.

For more information on the online patching cycle, see:Oracle E-Business Suite Concepts.

Database Considerations

As EBR is enabled per database user, the potentially editionable objects in a particular schema are all either editioned or not (internal database users such as SYS, SYSTEM, and PUBLIC cannot be editioned). As not all database objects are editioned, and because the definition of one object may depend on another object, for editioning to be enabled successfully there must be no dependencies of non-editioned objects on editioned objects.

Potential violations here fall into the following categories:

Each of these will be now be considered in turn.

PUBLIC synonyms to editioned objects

The PUBLIC schema is one of several internal database schemas that cannot be editioned, and so no PUBLIC objects are editioned. PUBLIC Synonyms that point to editioned objects must be dropped, and any reference to them must be replaced with equivalent private synonyms in the referencing schemas. This is done as follows:

  1. Query PUBLIC synonyms that point at “to-be-editioned” objects.

  2. For each PUBLIC synonym in Step 1, query the oracle users that have code dependencies on that PUBLIC synonym.

  3. For each affected oracle user in Step 2, create the equivalent private synonym.

  4. After all private replacement synonyms have been created, drop all PUBLIC synonyms from step 1.

Tables and queues that depend on editioned user-defined types

Oracle E-Business Suite includes approximately 20 table/queue columns that are defined using UDTs owned by APPS. You may have additional custom tables with this situation. Editioning constraints prevent a table column from depending on an editioned data type, so these columns must be modified to depend on an equivalent non-editioned type:

  1. Copy the UDT type from the APPS user to the non-editioned user APPS_NE.

  2. Stop any affected queues.

  3. Update the column type to use the non-editioned type.

  4. Drop the old type from APPS and create an APPS synonym to the non-editioned type.

  5. Recreate AQ internal derived objects.

  6. Restart any affected queues.

Materialized views that depend on editioned objects

Materialized views depend on editioned objects such as views and synonyms. As materialized views are non-editioned, they must be converted to an alternative implementation that is edition-legal.

Custom and third party schemas that depend on editioned objects

Custom schemas that depend on editioned Oracle E-Business Suite objects must be registered with Oracle E-Business Suite, and will be themselves editioned. Custom schema registration is performed as follows:

    'SCHEMA_NAME', 'CUSTOM', 'INVALID', NULL, 'N', 'B');  

Registered custom schemas will be included in database preparation processing to automatically fix other types of editioning constraint violations. Custom objects will also need to comply with online patching development standards, which may require manual correction by the custom developer.

Non-APPS synonyms to Oracle E-Business Suite tables

While not strictly an editioning constraint violation, it is no longer safe to reference Oracle E-Business Suite tables directly. All Oracle E-Business Suite table references must go through the APPS synonyms (which may in turn point to the Editioning View for a table), instead of directly at the Oracle E-Business Suite table. All non-APPS synonyms that point directly to Oracle E-Business Suite tables must be updated to point to the equivalent APPS table synonym instead.

Enabling Editioning for Oracle E-Business Suite Database Users except APPS_NE

All database users in Oracle E-Business Suite are recorded in the FND_ORACLE_USERID table. This includes all users shipped with Oracle E-Business Suite, as well as any registered custom database users. All Oracle E-Business Suite users except APPS_NE have the editioning feature enabled as follows:

SQL>alter user USERNAME enable editions force;  

The APPS_NE user is deliberately not editioned, so that it can contain the non-editioned objects for Oracle E-Business Suite.

Applying Customizations

Refer to My Oracle Support Knowledge Document 1577661.1, "Developing and Deploying Customizations in Oracle E-Business Suite Release 12.2," for information on applying customizations.

Related Topics

The Online Patching Cycle, Oracle E-Business Suite Maintenance Guide

The Custom Synchronization Driver File

You need to ensure that any customizations you may have are preserved when the run and patch file systems are being synchronized. Examples include:

To do so, you should add entries for all your custom files to the custom synchronization driver file. See My Oracle Support Knowledge Document 1577661.1, "Developing and Deploying Customizations in Oracle E-Business Suite Release 12.2," for more information.