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:
Since all Oracle E-Business Suite products are included in every installation, online patching applies to all products.
All Oracle E-Business Suite patches for Release 12.2.2 or later updates to the 12.2 codeline are online patches.
Online patches must be applied using the adop online patching tool (not adpatch).
Online patching is performed in four distinct phases:
Prepare
Patch
Cutover
Cleanup
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.
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:
PUBLIC synonyms to editioned objects
Tables and queues that depend on editioned user defined types (UDTs)
Materialized views that depend on editioned objects
Custom and third-party schemas that depend on editioned objects
Non-APPS synonyms on Oracle E-Business Suite tables
Each of these will be now be considered in turn.
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:
Query PUBLIC synonyms that point at “to-be-editioned” objects.
For each PUBLIC synonym in Step 1, query the oracle users that have code dependencies on that PUBLIC synonym.
For each affected oracle user in Step 2, create the equivalent private synonym.
After all private replacement synonyms have been created, drop all PUBLIC synonyms from step 1.
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:
Copy the UDT type from the APPS user to the non-editioned user APPS_NE.
Stop any affected queues.
Update the column type to use the non-editioned type.
Drop the old type from APPS and create an APPS synonym to the non-editioned type.
Recreate AQ internal derived objects.
Restart any affected queues.
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 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:
fnd_oracle_user_pkg.load_row(
'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.
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.
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.
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
You need to ensure that any customizations you may have are preserved when the run and patch file systems are being synchronized. Examples include:
Compiling user-defined JSPs
Copying some third-party libraries
Executing user-defined SQL files
Compiling user-defined forms
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.