Planning

Oracle E-Business Suite
Technical Planning Guide, First Edition

Release 12.2
Part No. E35675-10
April 2016
Oracle E-Business Suite Technical Planning Guide, First Edition, Release 12.2
Part No. E35675-10
Copyright 2012, 2016, Oracle and/or its affiliates. All rights reserved.
Primary Author: Mildred Wang, Robert Farrington
Contributing Author: Samer Barakat, Santiago Bastidas, Deepak Bhatnagar, George Buzsaki, Steven Chan,
Kevin Hudson, Lisa Parekh, Scot Robson
Contributor: Kevin Brown, Clara Jaeckel
This software and related documentation are provided under a license agreement containing restrictions on
use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your
license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license,
transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse
engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is
prohibited.
The information contained herein is subject to change without notice and is not warranted to be error-free. If
you find any errors, please report them to us in writing.
If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on
behalf of the U.S. Government, the following notice is applicable:
U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software,
any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are
"commercial computer software" pursuant to the applicable Federal Acquisition Regulation and
agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation
of the programs, including any operating system, integrated software, any programs installed on the
hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the
programs. No other rights are granted to the U.S. Government.
This software or hardware is developed for general use in a variety of information management applications.
It is not developed or intended for use in any inherently dangerous applications, including applications that
may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you
shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its
safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this
software or hardware in dangerous applications.
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of
their respective owners.
Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are
used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron,
the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro
Devices. UNIX is a registered trademark of The Open Group.
This software or hardware and documentation may provide access to or information about content, products,
and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly
disclaim all warranties of any kind with respect to third-party content, products, and services unless
otherwise set forth in an applicable agreement between you and Oracle. Oracle Corporation and its affiliates
will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party
content, products, or services, except as set forth in an applicable agreement between you and Oracle.

Contents
Send Us Your Comments

Preface
1
Introduction
Purpose of this Book................................................................................................................. 1-1
Hardware Resources
Hardware Sizing Requirements................................................................................................ 2-1
CPU Requirements...............................................................................................................2-1
Memory Requirements........................................................................................................ 2-2
Disk Space Requirements..................................................................................................... 2-3
Additional Guidelines for Database and Application Tier Sizing ......................................... 2-5
Technology Stack Considerations

Upgrade Checklist..................................................................................................................... 3-1
Introduction to Online Patching

Online Patching Concepts......................................................................................................... 4-1
Preparing for Online Patching

Introduction............................................................................................................................... 5-1
Preparing the Environment....................................................................................................... 5-4
Running the Readiness Reports................................................................................................ 5-5
Running the Online Patching Database Standards Checker................................................... 5-6
iii
Running the Global Standards Compliance Checker (GSCC)................................................ 5-6
Development Standards for Online Patching

Introduction............................................................................................................................... 6-1
Editioned Objects...................................................................................................................... 6-3
Effectively-Editioned Objects................................................................................................... 6-9
Non-Editioned Objects............................................................................................................ 6-27
Example of Disabling Functionality During Online Patching.............................................. 6-31
Blocking a Concurrent Program while Online Patching........................................................6-31
Examples of SQL Replacements for PL/SQL Functions......................................................... 6-32
LONG to CLOB Conversion Procedures................................................................................ 6-34
Index
iv

Send Us Your Comments
Oracle E-Business Suite Technical Planning Guide, First Edition, Release 12.2
Part No. E35675-10
Oracle welcomes customers' comments and suggestions on the quality and usefulness of this document.
Your feedback is important, and helps us to best meet your needs as a user of our products. For example:
Are the implementation steps correct and complete?

Did you understand the context of the procedures?
Did you find any errors in the information?
Does the structure of the information help you with your tasks?
Do you need different information or graphics? If so, where, and in what format?
Are the examples correct? Do you need more examples?
If you find any errors or have any other suggestions for improvement, then please tell us your name, the
name of the company who has licensed our products, the title and part number of the documentation and
the chapter, section, and page number (if available).
Note: Before sending us your comments, you might like to check that you have the latest version of the
document and if any concerns are already addressed. To do this, access the new Oracle E-Business Suite
Release Online Documentation CD available on My Oracle Support and www.oracle.com. It contains the
most current Documentation Library plus all documents revised or released recently.
Send your comments to us using the electronic mail address: appsdoc_us@oracle.com
Please give your name, address, electronic mail address, and telephone number (optional).
If you need assistance with Oracle software, then please contact your support representative or Oracle
Support Services.
If you require training or instruction in using Oracle software, then please contact your Oracle local office
and inquire about our Oracle University offerings. A list of Oracle offices is available on our Web site at
www.oracle.com.

Preface
Intended Audience
Welcome to Release 12.2 of the Oracle E-Business Suite Technical Planning Guide, First
Edition.
This guide assumes you have a working knowledge of the following:
The principles and customary practices of your business area.
Computer desktop application usage and terminology.
If you have never used Oracle E-Business Suite, we suggest you attend one or more of
the Oracle E-Business Suite training classes available through Oracle University.
See Related Information Sources on page viii for more Oracle E-Business Suite product
information.
Documentation Accessibility
For information about Oracle's commitment to accessibility, visit the Oracle
Accessibility Program website at
http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.
Access to Oracle Support

Oracle customers that have purchased support have access to electronic support
through My Oracle Support. For information, visit
http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info or visit
http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs if you are hearing impaired.
Structure
1 Introduction
vii
2 Hardware Resources
3 Technology Stack Considerations
4 Introduction to Online Patching
5 Preparing for Online Patching
6 Development Standards for Online Patching
Related Information Sources

Online Documentation
All Oracle E-Business Suite documentation is available online (HTML or PDF).
Online Help - Online help patches (HTML) are available on My Oracle Support.
PDF Documentation - See the Oracle E-Business Suite Documentation Library for
current PDF documentation for your product with each release.
Release Notes - For information about changes in this release, including new
features, known issues, and other details, see the release notes for the relevant
product, available on My Oracle Support.
Oracle Electronic Technical Reference Manual - The Oracle Electronic Technical

Reference Manual (eTRM) contains database diagrams and a detailed description of
database tables, forms, reports, and programs for each Oracle E-Business Suite
product. This information helps you convert data from your existing applications
and integrate Oracle E-Business Suite data with non-Oracle applications, and write
custom reports for Oracle E-Business Suite products. The Oracle eTRM is available
on My Oracle Support.
Integration Repository
The Oracle Integration Repository is a compilation of information about the service
endpoints exposed by the Oracle E-Business Suite of applications. It provides a
complete catalog of Oracle E-Business Suite's business service interfaces. The tool lets
users easily discover and deploy the appropriate business service interface for
integration with any system, application, or business partner.
The Oracle Integration Repository is shipped as part of the Oracle E-Business Suite. As
your instance is patched, the repository is automatically updated with content
appropriate for the precise revisions of interfaces in your environment.
Do Not Use Database Tools to Modify Oracle E-Business Suite Data

Oracle STRONGLY RECOMMENDS that you never use SQL*Plus, Oracle Data
Browser, database triggers, or any other tool to modify Oracle E-Business Suite data
unless otherwise instructed.
Oracle provides powerful tools you can use to create, store, change, retrieve, and
viii
maintain information in an Oracle database. But if you use Oracle tools such as
SQL*Plus to modify Oracle E-Business Suite data, you risk destroying the integrity of
your data and you lose the ability to audit changes to your data.
Because Oracle E-Business Suite tables are interrelated, any change you make using an
Oracle E-Business Suite form can update many tables at once. But when you modify
Oracle E-Business Suite data using anything other than Oracle E-Business Suite, you
may change a row in one table without making corresponding changes in related tables.
If your tables get out of synchronization with each other, you risk retrieving erroneous
information and you risk unpredictable results throughout Oracle E-Business Suite.
When you use Oracle E-Business Suite to modify your data, Oracle E-Business Suite
automatically checks that your changes are valid. Oracle E-Business Suite also keeps
track of who changes information. If you enter information into database tables using
database tools, you may store invalid information. You also lose the ability to track who
has changed your information because SQL*Plus and other database tools do not keep a
record of changes.
ix
1
Introduction
Purpose of this Book

This book was created to provide a starting point for moving to Oracle E-Business Suite
Release 12.2. Its purpose is to collect the essential information needed to start planning
for this move. Much of the content of this guide has been drawn from other Release 12.2
books, to provide a convenient high-level summary for DBAs and developers before
they move on to the more detailed descriptions in those books. It is not intended to
replace or be a substitute for any of those books.
Among the many new features of Oracle E-Business Suite Release 12.2, one of the most
significant is the move to online patching, which greatly reduces the periods of
downtime needed when applying patches. Such a significant transition does, however,
require an understanding of the new patching model, including the new terminology
and tools that underpin online patching operation, as well as the database and file
system features and organization. Online patching is discussed in detail in a later
chapter.
Another key change in Release 12.2 is the employment of Oracle WebLogic Server for
many system management and configuration tasks. This supplements (but does not
replace) the traditional AutoConfig tool that has been used for some time. Together,
these tools provide comprehensive management capabilities for a Release 12.2 system.
It is important to understand the role of each, and how they complement one another.
In summary, this Planning Guide is designed to help you identify what you need to
think about as you prepare to install (or upgrade to) Oracle E-Business Suite Release
12.2 and its online patching environment.
Introduction 1-1
2
Hardware Resources
Hardware Sizing Requirements

Because there are different product combinations, different user profiles, and different
configurations, there is no one sizing answer for all hardware platforms. Some
hardware vendors have sizing worksheets that model the CPU and memory
requirements of Oracle E-Business Suite on their hardware.
The most reliable strategy to ensure that the hardware is sized appropriately is to install
a test environment, and then conduct a benchmark test with a configuration, product
mix, and user load that simulates your own current and expected workloads. These
conditions can help verify performance before you install your production-ready
environment. An alternative is to ask Oracle Consulting Services or your hardware
vendor to find another Oracle E-Business Suite system running a product mix and user
profile similar to yours.
CPU Requirements
Note: Unless explicitly noted otherwise, Oracle E-Business Suite
documentation uses the term "CPU" to mean an actual CPU core rather
than a logical core.
CPU requirements for running Oracle E-Business Suite for the Database and
Applications tiers depend on the following factors, which are listed in no particular
order:
Required response times of the business
Number of concurrent users and their usage profiles
Number of concurrent manager processes and the types of jobs that they are
running
Hardware Resources 2-1
Load for activities other than Oracle E-Business Suite Size of the database
The chosen deployment topology
The number of CPUs and cores needed to support Oracle E-Business Suite depends on
the specific platform implementation, and whether or not hyperthreading is in use.
Two useful formulae are:
Actual Cores Count = Processor Count * CoresCountPerProcessor
Logical Processor Count = Actual CoresCount * ThreadCount
You should also consult your platform vendor as required.
Memory Requirements
The Oracle E-Business Suite Database requires adequate memory to support the specific
needs of a given installation. To determine the total memory requirements on the
machine where the database is installed, you must take the following into account:
Oracle Database overhead
Size of System Global Area (SGA)
Number of concurrent users
Any non-Oracle software that has to run on the machine (this is not recommended)
When sizing the environment in which you will install Oracle E-Business Suite, you
should aim to allow for any expected growth in usage over the planned lifetime of your
system. It is, however, possible to scale up a system later to meet additional
requirements subsequent to installation, either by adding nodes (machines) to the
application tier or employing Oracle Real Application Clusters (Oracle RAC) on the
database tier.
Important: To help determine your memory requirements for the
various Oracle E-Business Suite Database components, refer to My

Oracle Support Knowledge Document 396009.1, Database Initialization
Parameters for Oracle E-Business Suite Release 12.
Minimum Memory for an Oracle E-Business Suite Installation

The minimum amount of memory needed to run Oracle E-Business Suite is about 6 GB
for the database tier machine, and 10 GB for a single application tier machine. This
configuration would typically support no more than ten users.
2-2 Oracle E-Business Suite Technical Planning Guide, First Edition
Important: For detailed guidance and recommendations on this subject,
refer to the section, "Database and Application Tier Sizing."
Single-User Single-Machine Non-Production System

For the special case of a system that will only be employed by a single user to develop
or test patches, the minimum memory requirement is 8 GB.
Important: This figure represents the minimum amount of memory that
can be employed, and may rise either to meet the needs of new releases
or the deployment of components such as additional managed servers.
Disk Space Requirements

Rapid Install installs the file system and database files for all products, regardless of
their licensed status. The approximate file system disk space requirements for a
standard installation are:
File System Space Requirements for Standard Installation
Node
Space Required
Database node file system (Fresh install)
90 GB (includes database files and 12cR1

database Oracle Home).
Database node file system (Vision Demo

database)
200 GB (includes database files and 12cR1

database Oracle Home).
Applications node file system (OracleAS 10.1.2

Oracle Home, Oracle FMW Oracle Home,
COMMON_TOP, APPL_TOP, and
INST_TOP)
64 GB (for dual file system). Also, see Note

below for language (NLS) considerations.
Note: The minimum recommended space required for each active
language is 16 GB in the file system (for both APPL_TOPs), and 3 GB in

the database. For more information, refer to My Oracle Support
Knowledge Document 1314621.1, Oracle E-Business Suite NLS Release
Notes, Release 12.2.
Stage area
For a production database installation, running Rapid Install from a stage area requires
at least 48 GB to accommodate the file system and database files in the stage area.
Important: Because the size of the staging area mainly depends on the
database size, care should be taken to size it according to the enterprise

needs and database footprint.
Oracle E-Business Suite log and output files

Many Oracle E-Business Suite products generate log and output files during runtime.
The disk space needed varies with the number of users and transactions, and depends
on how frequently you purge these files.
Tip: Log and output files are not automatically purged. Determine a
strategy for archiving and purging these files after the installation, and
monitor the disk space they consume to determine how much space
you may need in the future.
Temporary directories and files

For install time temporary disk space, Rapid Install uses the directory defined by the
TMPDIR variable (on UNIX) or TEMP and TMP variables (on Windows). You should
ensure there is adequate (typically, at least 5 GB) of free temporary space for use by
Rapid Install before starting an installation.
At runtime, Oracle E-Business Suite requires temporary disk space. For example, each
concurrent manager writes temporary parameter files, Oracle Reports writes temporary
format files, and Oracle Forms writes temporary buffer records. Rapid Install sets the
temporary directory based on the value you supply on node-specific settings screens.
The directory defined by the TMPDIR variable is also used for some temporary files,
such as certain patches.
The amount of temporary space will depend on the number of forms and concurrent
manager sessions writing on the temporary file system. It is recommended that you use
separate disk partitions for operating system and user data (that is, separate partitions
for /home, /tmp, /var/tmp, /oracle, and so on). This strategy can prevent a "file system
full" issue from impacting operations. Establishing disk quotas can also prevent a user
from accidentally or intentionally filling up a file system.
Updates and patches

You will need disk space for applying updates, patches, maintenance packs, family
packs, and minipacks, and for any backup files that may be created.
Other files
The total disk space estimate must account for the requirements of files other than those
directly related to Oracle E-Business Suite. For example:
Operating system software
Online backups
Custom applications development files
Files for any other software that you use
Additional Guidelines for Database and Application Tier Sizing

General Sizing Guidelines
Below are some general sizing guidelines for Oracle E-Business Suite Release 12.2.5.
Be aware of the following important points:
These guidelines were derived using Oracle's hardware and networking

infrastructure, and should only be used as a starting guide.
You should always size your systems based on tests using representative data and
workloads for your own environment. The most reliable strategy to ensure that the
hardware is sized appropriately is to install a test environment, and then conduct a
benchmark test with a configuration, product mix, and user load that simulates
your own current and expected workloads. These conditions can help verify
performance before you install your production-ready environment.
In addition to the memory needed based on the sizing guidelines below, you
should allow an extra 2 GB of free memory for the database tier machine and an
extra 3 GB of free memory for the middle tier machine for Online Patching.
The sizing of various transactions depend on the transaction type (such as Oracle
Application Framework, Forms, or batch programs), and the transaction workload
(light, medium, or heavy). Some transactions may require more memory (such as
those for Oracle Configurator).
Oracle Application Framework Transactions

The following table shows the memory used for Oracle Application Framework-type
transactions with light to medium workload characteristics.
Note: The figures in the table do not take into account any Online
Patching requirements.
Number of
Concurrent
Users
Database
Machine
Memory
Number of
Database
Machine CPUs
Application Tier
Machine
Memory
Number of
Application Tier
Machine CPUs
0-10
4 GB
6 GB
100-200
8 GB
8 GB
200-400
12 GB
10 GB
400-800
20 GB
14 GB
You should plan your resources using the above figures as guidelines.
Important: Figures of this kind represent a minimum amount of
memory, and your specific requirements may need more.
Oracle Forms Transactions

On the application tier, each Oracle Forms process requires approximately 40 MB of
memory. So the total memory required is given by the formula:
(Number of concurrent Oracle Forms users) x 40 MB
The following table lists the additional machine memory needed for different numbers
of users:
Number of Users
Required Machine Memory
100
4 GB
200
8 GB
400
16 GB
800
32 GB
On the database tier, there is one Oracle Forms session per open form, and each of these
sessions requires approximately 30 MB of PGA memory.
The following table lists the memory required for different numbers of sessions:
Number of Oracle Forms Sessions
Required Machine Memory
100
3 GB
200
6 GB
400
12 GB
800
24 GB
Application Tier Memory

The total RAM memory for the application tier (also known as the middle tier) is the
sum of:
Technology Stack Memory
JVM Memory
Forms Memory
Concurrent Manager Memory
Other Running Processes
Resident Memory
OS Kernel Memory
Aside from the stack, the two main contributors to the middle tier memory are the JVM
memory and Forms memory (the frmweb process). The JVM heap size is equal to
(Number of Self-Service users / 150 ) x 1 GB. The Forms Processes memory is equal to
the (Number of Forms users) x 40 MB. Thus, for 100 concurrent users spanning
self-service applications and Forms, an additional 4 GB of memory and 1 CPU is
needed.
Example Upgrade
This section provides sample figures for an upgrade from Oracle E-Business Suite
Release 12.1.3 to Release 12.2.5. The figures were derived using Oracle's hardware and
networking infrastructure, and are provided for general guidance only.
Automatic Workload Repository Advisory sections from test runs should be used to
size relevant database memory components for the actual upgrade.
Important: To minimize unforeseen contigencies, prior to the actual
upgrade it is essential to perform pre-production testing and validation

on a comparable system to the production system.
Example Upgrade - Environment Details

The environment details for this upgrade were as follows:
Operating system: Oracle Linux Enterprise Edition Server Release 5.8
Server memory: 141 GB
Number of CPUs: 24
Oracle Database Release: 12.1.0.2
Oracle E-Business Suite Release: 12.1.3

Note: The database tier and application tier are on the same machine in
this example.
Database configuration was as follows:
SGA: 10 GB
Shared pool: 1 GB
PGA: 10 GB
Log buffer: 30 MB
job_queue_processes: 24
For more information on performing upgrades, refer to: Oracle E-Business Suite Upgrade
Guide, Release 12.0 and 12.1 to 12.2 and Oracle E-Business Suite Upgrade Guide, Release 11i
to 12.2.Also refer to My Oracle Support Knowledge Document 1597531.1, Oracle
E-Business Suite Release 12.2: Upgrade Sizing and Best Practices.
Note: During the upgrade of the Admin Tier, batchsize and number of
workers used were 1000 and 24 respectively.
Example Upgrade - Database Size

The following table shows the data for the example upgrade from Release 12.1.3 to
Release 12.2.5:
Before Upgrade
Database Size (GB)
After Upgrade
Database Size (GB)
Delta (GB)
% Growth
146
121
-25
-17.12
The reduction in database size is a result of multiple obsolete schemas and objects being
removed from the upgraded system.
Example Upgrade - Application Tier Size
Oracle E-Business Suite Release 12.2 is installed with three file systems, to accommodate
the Online Patching feature.
fs1 (production file system) - Used by the current users of the system.
fs2 (copy of production file system) - Used by the patching tools.
fs_ne (non-editioned file system) - Used to store data that is kept in the file system
(such as data import and export files, reports, and output and log files).
In addition, the pre-upgrade file system has a requirement for an INST_TOP.

All three file systems in the Release 12.2 installation serve a single database. The file
system in use by the running application is never patched. All patches are applied to
the secondary file system.
The following table shows the data for the example upgrade from Release 12.1.3 to
Release 12.2.5:
Component
Size Before Upgrade
Size After Upgrade
ORACLE_HOME
9 GB
9.3 GB
APPL_TOP
51 GB
N/A
INST_TOP
27 MB
N/A
fs1 (APPL_TOP+ INST_TOP)
N/A
41 GB
fs2 (APPL_TOP+ INST_TOP)
N/A
34 GB
fs_ne
N/A
1 GB
3
Technology Stack Considerations
Upgrade Checklist
In preparation for upgrading to Oracle E-Business Suite Release 12.2, you should do the
following:
1.
Migrate your database to Oracle Database 11.2.0.4 (Database 11gR2) or 12.1.0.2 (for
Database 12cR1).
Upgrading to Oracle E-Business Suite Release 12.2 requires your database to be at
the minimum version 11.2.0.4. Oracle strongly recommends that all Oracle
E-Business Suite customers upgrade their current environments to one of the above
releases. If you have not already upgraded your Oracle E-Business Suite database to
11.2.0.4 or 12.1.0.2, you should do so now. You will not only benefit by receiving the
latest updates for security, performance, and stability before you move to Release
12.2, but will have one fewer step to perform when you upgrade to Release 12.2.
Note: Consult Certify on My Oracle Support for the latest certified
version.
Note: Database de-support schedules have important operational
and planning implications for Oracle E-Business Suite

environments. Oracle recommends that you review the following
document that details the latest database support policies and
de-support schedules: Release Schedule of Current Database Releases,
My Oracle Support Knowledge Document 742060.1.
Note: See Database Preparation Guidelines for an Oracle E-Business
Suite Release 12.2 Upgrade, My Oracle Support Knowledge

Document 1349240.1, for more information.
Technology Stack Considerations 3-1
2.
If you are on Release 11i, prepare an upgrade plan to move to Release 12.X.
The benefits here are similar to those in point 1 above, but in this case for Oracle
E-Business Suite instead of Oracle Database. A large number of significant product
enhancements were introduced in Oracle E-Business Suite Release 12.X, including
features such as subledger accounting, support for a shared services model,
multiple-organization access control, and extensive new reports. Many customers
have found that these Release 12.X enhancements provide an opportunity to update
existing business processes, introduce new business models, and retire redundant
customizations.
3.
Switch from Oracle Single Sign-On to Oracle Access Manager.

Oracle E-Business Suite Release 12.2 is certified only with Oracle Access Manager
11g and higher. If you are running Oracle Single Sign-On, you should migrate to
Oracle Access Manager before upgrading to Release 12.2.
4.
Switch from Oracle Portal to Oracle WebCenter Portal.

Oracle Portal is deprecated in Oracle E-Business Suite Release 12.2. If you are using
Oracle Portal, you should migrate to Oracle WebCenter Portal before upgrading to
Release 12.2.
5.
Create an inventory of all customizations.

All Oracle E-Business Suite customers should compile a comprehensive inventory
of their existing customizations. Enhancements delivered with Release 12.2 may
make some of these customizations unnecessary.
Later chapters in this book provide information on how to ensure custom code
complies with new Release 12.2 coding standards. In particular, you should run
both the Online Patching Readiness Report and Global Standards Compliance
Checker to help ensure that your code is compliant.
4
Introduction to Online Patching
Online Patching Concepts

Traditionally, Oracle E-Business Suite has needed to be shut down to apply patches and
bug fixes of various kinds. Scheduling the sometimes lengthy downtimes needed can
prove difficult to combine with requirements for the highest possible availability of
business-critical systems. This is exacerbated by the increasing move to consolidate
systems into a single instance that may support worldwide operations, and which
consequently does not have a natural downtime window.
Oracle E-Business Suite Release 12.2 introduces online patching, which greatly reduces
the need for such downtime. All patching in Release 12.2 is performed using this new
model.
Key features of online patching include:
Oracle E-Business Suite patching operations are carried out while the applications
are in use and users are online. This is accomplished by means of a copy of the
application components that are stored in the database and file system (data stored
in transaction tables is not copied).
Oracle E-Business Suite patching is performed using the new adop (AD Online
Patching) utility.
A short period of downtime is required, but this amounts to little more than a
restart of the application tier services: the time the applications are unavailable is
measured in minutes rather than hours, and this can be set to be at the most
convenient time, for example outside normal business hours.
Maintenance Mode is not needed or used in Release 12.2.
The patching model used before Release 12.2 was designed to minimize downtime by
performing its operations in the shortest time possible, using whatever resources are
needed. In contrast, the online patching model is designed to minimize downtime by
Introduction to Online Patching 4-1
allowing patching operations to be performed while users remain on the system.
Overview
In traditional patching, application of a patch is a single logical operation. In online
patching, it can be thought of as a series of related steps:
1.
A copy is made of the code of the running system that resides in both the file
system and database.
2.
Patches are applied to the copy while users continue to access the running system.
3.
The copy becomes the new running system.
4.
The original running system (now obsolete) is recycled for use in future patching
cycles.
These steps constitute the online patching cycle. To implement this mechanism, various
changes have been made to the Oracle E-Business Suite infrastructure.
Any method used to create a copy of the running application must take into account
that an Oracle E-Business Suite application comprises both code and data, stored in the
database and the file system. A key concept is the edition as a copy of the application
code: the running application executes on the run edition, while any patching activity
takes place in the patch edition. The implementation mechanism uses the Oracle
Database Edition-Based Redefinition (EBR) feature to cater for database objects, and a
dual file system to cater for objects stored in the file system.
Two complete file systems are always present in an Oracle E-Business Suite Release 12.2
system. As noted above, the run file system is the one currently in use by the running
application, while the patch file system is the either being patched or awaiting the start
of the next online patching cycle. In other words, the two file systems swap roles with
every online patching cycle.
In the database, there is also a run edition and patch edition, but they do not swap roles
back and forth as in the file system: the patch edition only comes into existence during a
patching cycle, and becomes the new run edition at the end of the cycle. The former
database run edition (the old edition) and the obsolete objects it contains are discarded
at the end of an online patching cycle, and the space reclaimed during the cleanup
phase.
These concepts will all be described in more detail after a discussion of the way they are
used in the online patching cycle.
The Online Patching Cycle

The online patching cycle is divided into five phases:
Patching Cycle Overview

The key actions in the various stages of the online patching cycle can be summarized as
follows:
Prepare
Synchronizes patch edition and run edition on the file system.
Creates a new patch edition in the database.
Apply
Executes patch drivers to update patch edition.
Patches applied: can be one or many, including customizations.
Finalize
Compiles invalid objects.
Generates derived objects.
Cutover
Configures patch edition file system to be the new run edition file system.
Configures patch edition of database to be the new run edition.
Restarts application tier services.
Cleanup
Delete obsolete code and seed data to recover space.
Each of the phases will now be discussed in more detail.

Prepare
The following actions are taken in this phase.
On the file system:
1.
The patch file system is synchronized with the run file system.
2.
The patch edition files become an exact copy of the run edition files.
Note: By default, synchronization is incremental: that is, only files that
were changed in the last patch application are copied.
In the database:
1.
A patch edition is created in the database.
2.
All code objects in the patch edition begin as pointers to code objects in the run
edition. Code objects in the patch edition begin as lightweight "stub objects" that
point to the actual object definitions, which are inherited from earlier editions. Stub
objects consume minimal space, so the database patch edition is initially very small
in size.
3.
As patches are applied to the patch edition, code objects are actualized (have a new
definition created) in that edition.
Note: Storage objects (such as transaction tables) are not copied.
Apply
The following actions are taken in this phase:
1.
Patches are applied to the patch edition. During this process, any changed stub
objects will become actual code objects in the patch edition.
2.
The changes introduced by the patches are made in the isolation of the patch
edition.
Changes to code objects are only visible in the patch edition of the file system
and database.
Changes to tables are stored in new columns or rows that are only visible to the
patch edition.
Note: At this point, users still remain connected to the application and
performing their work.
Finalize
This phase is used to perform the final operations that can be executed while the
application is online:
1.
Invalid objects are compiled.
2.
Derived objects are generated.
3.
Any actions that must be performed at cutover are pre-computed and stored for
quick execution at that time.
Cutover
This phase involves:
1.
Shutdown of application tier services.
2.
Execution of any required cutover actions to maintain non-editioned objects and

data.
3.
Configuration of the patch edition of the file system as the new run edition.
4.
Configuration of the patch edition of the database as the new run edition.
5.
Restart of application tier services on the new run edition.
Although the cutover phase does require a short period of application tier services
downtime, the online patching cycle can be paused for as long as required prior to
running this phase. You could, for example, add such a pause to ensure that the
downtime period will be outside business hours.
Note: The database remains open throughout the entire online patching
cycle, including cutover.
Cleanup
The following database actions are taken in this phase, which occurs after users have
been brought back online to the newly-patched application:
1.
Old code objects that are no longer visible in the run edition are dropped.
2.
Old data (rows or columns) that is no longer visible in the run edition is deleted or
dropped.
3.
Old database editions that no longer contain actual objects are dropped.
Database Implementation
Creating a copy of the database part of the running system has been accomplished by
taking advantage of the Oracle Database Edition-Based Redefinition (EBR) feature. This
allows an application to efficiently store multiple copies of its application definition in
the same database, and thereby enables online upgrade of the database tier.
The term edition refers to the isolation mechanism that allows pre-upgrade and
post-upgrade schemas to co-exist. The simplest way to think of an edition is as a
separate (isolated) copy of all database code objects that are changed by a patch.
The three types of database edition are:
Run: Online users connect to this edition, which is always the default database
edition. The run edition will always exist.
Patch: Patching tools connect to this edition. A child of the run edition, the patch
edition exists only while a patching cycle is in progress.
Old: When a patch edition is promoted to be the run edition, the previous run
edition is now regarded as an old edition. There may be zero or more old editions at
a given time. They are discarded when a full cleanup (described later) is performed.
You cannot connect to an old edition.
Editioned and Non-Editioned Objects

EBR automatically manages versioning of objects that support editioning, such as code
objects. However, not all objects can be editioned: most notably, this includes
transactional data, of which there is only ever one copy.
Oracle E-Business Suite Release 12.2 introduces a new concept, the logical view of the
data model. This is implemented via synonyms and editioning views, which isolate the
running application from changes to the data model that may be introduced by a patch.
That is to say, data model changes are guaranteed to not affect the running application.
Data model changes are implemented as new columns on the table, which are exposed
to the patch edition of the application via the editioning view. New tables can be
introduced by an extension of the same principle.
Crossedition Triggers
A new type of object, the crossedition trigger, is used to synchronize data as part of the
online patching process. These triggers provide the logic to synchronize and transform
data between the run edition and patch edition storage columns. The result is that new
transactions entered into the system are patched in place.

More specifically, crossedition triggers allow the run edition to signal that a data update
is required. They fire in response to an insert into, delete from, or update of,
FND_TABLE. For example, suppose that a patch updates a column called
DESCRIPTION from upper case to mixed case. Editioning views project different views
of the table to the run and patch editions, so the running application still sees the
column data as upper case, while the patched application sees the column data as
mixed case. The updated column is maintained by a crossedition trigger.
In summary, crossedition triggers are used to upgrade both existing data and ongoing
changes that occur while the run edition remains in use.
Editioning Views and the Application Data Model
Editioning views can be thought of as providing a cover layer, or logical representation
of the data, on top of the physical representation. All code (Oracle E-Business Suite,
custom, or third-party) must access Oracle E-Business Suite data via the cover layer:
accessing the data model via the physical layer may result in obsolete data been
returned.
Note: The implementation of EBR for Oracle E-Business Suite requires
all code to access the data model via the APPS synonym, which points
to the editioning view (logical model).
Important: Any code accessing the physical model risks accessing
obsolete columns.
Online Patching and Seed Data

Oracle E-Business Suite seed data is data stored in database tables that affects the
behavior of the applications, and is patched as needed by Oracle E-Business Suite
Development. In an online patch environment, patches cannot be allowed to modify the
seed data that is visible to the running application.
Online patches are prevented from modifying runtime seed data by the use of editioned
data storage. This involves creation of a (patch) copy of the seed data, which is stored in
the same table. The patches that are applied interact only with this copy, while the run
edition only interacts with a private copy (which is eventually deleted as part of the
cleanup phase).
The running application uses the run edition copy of seed data, while patches may
update the patch edition copy of seed data in isolation. The two copies are isolated,
except that seed data changes made by the running application are synchronized to the
patch edition copy.
In terms of editions and seed data, the run edition:
Always operates on a private copy of the seed data
Is never modified by patch application
In contrast, the patch edition:
Runs the seed data loader
Prepares the relevant table for patching
Copies all table rows
Loads seed data changes into the (patch) copy
Updates to seed data in the run edition are automatically propagated to the patch
edition by the use of crossedition triggers.
File System Implementation

Creating and using two file systems allows one (run file system) to be part of the
running system, while the other (patch file system) is either being patched or waiting to
be patched during the next patching cycle.
Note: The file systems are designated File System 1 and File System 2 in
Rapid Install. These are abbreviated to fs1 and fs2 respectively.
The two file systems are sometimes referred to as a dual file system, and swap roles at the
end of each patching cycle. That is, the file system that has just been patched is put into
use as part of the running system (becoming the new run file system), and the previous
run file system now takes over the the role of patch file system (in readiness for
commencement of the next patching cycle).
Important: The existence of the dual file system has significant
implications for general (non-patching) maintenance activities.
However, two file systems are not sufficient to meet all the practical needs of an online
patching environment for Oracle E-Business Suite. A third file system, described in the
next section, is also required.
Non-Editioned File System

The dual file system approach caters for application code, but applications also use the
file system to read and write business data. In Release 12.2, application data files are
stored in a third area, the non-editioned file system (fs_ne), which is used to store data that
is needed across all file systems. Non-editioned files are not copied or moved during
patching: their location remains constant across online patching cycles.
The Three File Systems: fs1, fs2, and fs_ne
The non-editioned file system is therefore completely separate from file system 1 and
file system 2.
Context Variables for Online Patching File Systems
Several AutoConfig context variables support the file systems used in online patching.
For example, the s_ne_base context variable stores the location of the non-editioned file
system, and AutoConfig sets the environment variable $NE_BASE to the corresponding
value. AutoConfig also sets the environment variables $RUN_BASE and

$PATCH_BASE, so you can easily tell which is currently the run file system and which
the patch file system.
Files Stored in the Non-Editioned File System
The non-editioned file system is designed to store files that contain transactional data
and reference data. Examples include: import, export files, general log files, and
concurrent manager log and out files.These are all examples of files that are not
modified during an online patching cycle.
More specialized examples include:
Batch upload and download files.
Files used to transfer transactional data from processes external to Oracle

E-Business Suite (for example, where a third party order entry system delivers
orders via order import files).
Files containing transactions that are needed across all file systems.
Note: The non-editioned file system is not designed to store shared
files, because initially identical files can become non-identical during

patching life cycles. Nor is it designed to store code, which is editioned
(one copy can be in the run file system while the other is in the patch
file system).
Online Patching Tools

Patching is performed by running the new adop (AD Online Patching) utility. You must
run adop instead of the adpatch utility that was used in previous releases.
The adop tool orchestrates the entire patching cycle, and can be executed by specifying
phases individually or collectively. For example, adop phase=prepare, adop
phase=apply, and adop phase=cutover is the equivalent of adop
phase=prepare,apply,cutover.
5
Preparing for Online Patching
Introduction
Oracle E-Business Suite includes a utility, the Online Patching Readiness Report, to help
you identify database components that need updates in preparation for Release 12.2
and Online Patching enablement. This utility is to be run in a Release 11i, 12.0, 12.1, or
12.2 environment (before Online Patching is enabled).
This utility is available independent of Release 12.2 for customers preparing to upgrade
prior to acquiring Release 12.2. It is also available for Release 12.2. Download the
appropriate patch for your release (Release 11i, 12.0, 12.1, or 12.2). To find the patch
number, refer to My Oracle Support Knowledge Document 1531121.1, "Using the
Online Patching Readiness Report in Oracle E-Business Suite Release 12.2." The patch
README file has the most up-to-date information on this utility.
Important: You must fix all violations that are reported by this utility
before enabling online patching.
Executing the Summary Readiness Report and the Manual Fix Readiness Report
You must run the readiness reports described in the sections below from the application
tier APPL_TOP. This reports lists objects that do not comply with the edition-based
redefinition (EBR) rule that noneditionable objects may not refer to editionable objects
(editionable objects are synonyms, views, and PL/SQL objects). This report also lists
several naming standard violations that must be fixed prior to applying the online
patching enablement patch.
In addition, you must run the Global Standards Compliance Checker (GSCC) script and
address errors that are reported by this script. For up-to-date information on this script,
refer to My Oracle Support Knowledge Document 1531121.1, "Using the Online
Patching Readiness Report in Oracle E-Business Suite Release 12.2," as well as the
related patch README file.
Preparing for Online Patching 5-1
The steps involved with running the report are illustrated in the following diagram:
Running the Summary Readiness Report and the Manual Fix Readiness Report
1.
Execute the Summary Readiness Report (ADZDPSUM.sql).

If there are no unregistered custom schemas, proceed to Step 3. Otherwise, go to
Step 2.
2.
Register schemas for enablement.

Run the Summary Readiness Report again.
Repeat Steps 1 and 2 until there are no unregistered schemas. Then proceed to Step
3.
3.
Execute the Manual Fix Readiness Report (ADZDPMAN.sql), the Online Patching
Database Compliance Checker, and the Global Standards Compliance Checker.
If there are no exceptions reported, go to Step 5. Otherwise, go to Step 4.
4.
Fix any exceptions found by running the utilities in Step 3.

Run the utilities in Step 3 again until there are no exceptions found.
5.
Enable Online Patching.
Ensuring Custom Code Complies with New Standards

You must ensure your custom code complies with the new standards that ensure the
relevant database objects and code can successfully be patched online.
Use the tools provided to review your customizations for violations of Oracle
E-Business Suite Online Patching standards:
Database Standards Checker (ADZDDBCC.sql) - This utility scans the data

dictionary for objects and code that violate the standards.
File system check report (gscc.pl) - This script scans the file system for source files
that violate the standards.
The readiness reports described earlier and the Database Standards Checker (also called
the Database Compliance Checker, or DBCC) are designed to be executed on a system
that has not yet been online patching-enabled. They can and should be run after
enablement as a final check. The sequence for the procedure after online patching has
been enabled is as follows:
1.
Upgrade to Release 12.2.
2.
Run readiness reports.
3.
Fix errors and repeat Step 2.
4.
Run the Database Standards Checker (ADZDDBCC.sql).
5.
Fix errors found in Step 4. Repeat Step 4.

Note: The DBCC utility cannot give a complete report until the
system has online patching enabled.
6.
Enable online patching.
7.
Rerun readiness reports. No errors or issues should be reported.
8.
Rerun the Database Standards Checker (ADZDDBCC.sql).
9.
Fix any errors and repeat Step 8 until no errors are reported.
Checking Compliance with the Database Standards Checker
Preparing the Environment

Prepare the environment to run the utilities.
1.
Initialize the run file system environment:

source <RUN APPL_TOP>/<Instance SID>_<hostname>.env
Note: The subsequent steps assume that you are running in the
same session which was initialized with this environment file. If

you need additional operating system level sessions, remember to
initialize the environment with this same environment file.
2.
Create the online patching log file location and set it as the current directory:
mkdir $LOG_HOME/appl/op
cd $LOG_HOME/appl/op
Note: The $LOG_HOME directory will be under the instance top
of the run file system.
Running the Readiness Reports

Run the following scripts:
ADZDPSUM.sql - Provides a summary of the schemas that will be editioned and

the schemas with objects that depend on Oracle E-Business Suite code that are
recommended to be editioned. You can register these schemas with the application
by running the commands that will be listed in the last section of this report. Oracle
recommends that you run this report again after the custom schemas are registered
with the application.
Refer to the patch README for instructions on running this script. Review the
generated report and perform the recommended actions. Rerun the report until you
have no more pending actions.
ADZDPMAN.sql - Lists objects with different categories of EBR rule violations;

these objects must be fixed prior to running the process enable Online Patching to
avoid errors. Oracle recommends that you run this report after all custom schemas
are registered with the application according to instructions in the above report
ADZDPSUM.sql.
Refer to the patch README for instructions on running this script. Review the
generated report and perform the recommended actions. Rerun the report until you
have no more pending actions.
ADZDPAUT.sql - Lists all the objects with violations to the EBR rules that will be
fixed automatically from the enablement process. This report is provided for
information purposes and no action should be taken for this report.
Note: Many violations in the readiness report can be automatically
fixed by registering your custom schemas. Review the last section of the
Summary Readiness Report (ADZDPSUM.sql) for sample commands
on how to register your custom schemas, as well as any schema
installed as part of an Oracle technology such as APEX, XDB, and
OWBSYS. You must register any custom or third-party schema that
does not support Oracle E-Business Suite Online Patching. The
following schemas should NOT be registered:
SYS
SYSTEM
CTXSYS
Any dependency between these schemas and editioned objects is a

coding standards violation and must be fixed manually.
Oracle recommends that you perform the chosen fixes by customizing the template file
$AD_TOP/sql/ADZDPCUST.sql. The reports provide more details on this step.
Running the Online Patching Database Standards Checker

Run the Online Patching Database Standards Checker Report (ADZDDBCC.sql) to
check for coding standards violations.
This utility reports violations to the Online Patching development standards. Refer to
the database object standards later in this book for more information on these
standards. You must fix any object listed in this report that is part of your custom code.
If you do not fix the violation, then you cannot use the online patching infrastructure to
patch the objects listed in this report.
Note: The consequences of failing to fix a violation depend on the type
of violation. Objects that do not comply with Online Patching

development standards may behave incorrectly or become invalid
during or after online patching.
Note: Some SQL statements in this report have a dependency on Oracle
E-Business Suite Release 12.2 which requires the Oracle 11gR2 database
or higher. If you are running the report prior to a Release 12.2 upgrade
and have not upgraded your database to 11gR2 or higher, then any
SQL failures can be ignored. The report should then be rerun after the
Oracle E-Business Suite Release 12.2 upgrade is complete or the
database has been upgraded to 11gR2 or higher, and any errors
corrected then.
Running the Global Standards Compliance Checker (GSCC)

Run the Global Standards Compliance Checker (or GSCC, or gscc.pl script) to check for
common standards issues.
The implementation of Online Patching in Oracle E-Business Suite Release 12.2 relies on
the Oracle Database Edition-Based Redefinition feature, and adds a new logical view
over the database objects in schemas registered with Oracle E-Business Suite. Access to
these database objects must be through the logical layer, and new coding standards
help to ensure that code does this correctly. The implementation of the logical layer has
been done such that the majority of application code already follows the new standards;
however, this script is provided to scan and identify many compliance issues if they
exist. To learn more about this script, refer to My Oracle Support Knowledge Document
1531121.1, "Using the Online Patching Readiness Report in Oracle E-Business Suite
Release 12.2," and the readme for the patch referenced in that document.
The Global Standards Compliance Checker (GSCC) consists of a main engine script
$FND_TOP/bin/gscc.pl plus various enforcement code (EFC) modules in

$FND_TOP/perl/GSCC/OpenEFC that check for common standards issues. Refer to
the readme of the patch for instructions on running the GSCC and interpreting the
output. Correct the errors reported by this script.
6
Development Standards for Online Patching
Introduction
This chapter documents new or modified standards designed specifically for database
object development and online patching in Oracle E-Business Suite Release 12.2. Other
development standards are not covered.
For more information on these and other standards, refer to My Oracle Support
Knowledge Document 1577661.1, Developing and Deploying Customizations in Oracle
E-Business Suite Release 12.2 and the Oracle E-Business Suite Developer's Guide.
Note: These standards only apply to objects and data that can be
directly managed by application developers. The database may

generate internal/hidden tables, indexes, types, and other objects. The
development standards do not apply to these generated objects.
Note: Any reference to an explicit schema name in these standards (for
example, "APPS") should be taken as conceptual, and not necessarily

the actual schema name. Schema names should not be included in the
software code, as a different name for a schema might be chosen at
installation. The only exception to this rule is the APPS_NE schema,
which is guaranteed to have this name in all installations.
Sections in this chapter are organized by object type. For each object type, the following
types of standards are given.
Definition Standards - These are rules that must be followed concerning the
definition of the object. These rules apply to all objects in the base release of Oracle
E-Business Suite Release 12.2.
Usage Standards - These are rules that must be followed when using the object
during application runtime.
Development Standards for Online Patching 6-1
Dynamic DDL Standards - These are rules that must be followed when generating
or altering the object definition during application runtime.
The Online Patching Database Compliance Checker Report

This utility reports many violations to the Online Patching development standards for
database objects. You must fix any object listed in this report that is part of your custom
code. If you do not fix the violations, then you cannot use the online patching
infrastructure to patch the objects listed in this report.
Check for violations of online patching database standards by running the Online
Patching Database Compliance Checker with the following command:
sqlplus <apps_username>/<apps_password>@DB @$AD_TOP/sql/ADZDDBCC.sql
Note: For more information on this utility, refer to My Oracle Support
Knowledge Document 1531121.1, "Using the Online Patching Readiness

Report in Oracle E-Business Suite Release 12.2," as well as the README
for the patch referenced in that document.
Requirements of Online Patching

The two main requirements of online patching can be stated in two simple rules:
An online patch must not break the running application
The running application must not break the online patch
The basis of Online Patching is an Oracle Database feature known as Edition-Based

Redefinition (EBR). This means that the Oracle E-Business Suite installation supports
two editions (versions) of the application on a single system. The application runs on a
set of files and database objects known as the "Run Edition". An online patch is applied
to a copy of the Run Edition known as the "Patch Edition". Database tables, indexes, and
other non-editioned objects are shared across both editions.
The requirements for Online Patching imply the following general development
standards:
An online patch must only change editioned objects in the Patch Edition.
An online patch must not make incompatible changes to non-editioned objects or

data used by the running application.
The running application must replicate dynamic changes to editioned objects to the
Patch Edition.
The running application must not make changes to non-editioned objects

maintained by Online Patching.
The remaining development standards provide guidance to help ensure you meet the
above criteria for each type of database object.
Editioned Objects
Editioned objects may have a different definition in each database edition. Editioned
objects can be patched in the patch edition without affecting the running application.
View (Ordinary)
Definition Standards
A view name must be a non-quoted identifier.

Note: Non-quoted identifiers may only use the following
characters: A-Z 0-9 _ # $. Quoted identifiers are reserved for use by

the technology components.
A join view should define a ROW_ID column mapped to the ROWID of the base
table.
Usage Standards
Do not reference the implicit ROWID pseudo-column of a join view. The availability of
implicit ROWID from a join view may change without warning. Instead, use the explicit
ROW_ID column that should be present in all join views.
Dynamic DDL Standards
If the running application creates, replaces or drops a view while a patch edition exists,
then the same action must be executed in the patch edition. This requirement can be
satisfied in either of two ways:
1.
Replicate the run edition dynamic DDL in the patch edition.

Use AD_DDL, which will replicate run edition DDL for views in the patch edition
automatically.
Example:
/* Code example:
Create a view using AD_DDL */
declare
L_APP
varchar2(8);
L_NAME varchar2(30);
L_STMT varchar2(32000);
begin
l_app := 'FND';
l_name := 'FND_EXAMPLE_V';
l_stmt :=
'create or replace view '||l_name||' as '||
'select user_id, user_name from fnd_user '||
'where user_id < 10000';
ad_ddl.do_ddl(
ad_zd.applsys_schema,
l_app,
product
ad_ddl.create_view,
l_stmt,
l_name
);
end;
/
2.
-- applsys schema name

-- application short name for your
-- statement type
-- statement text
-- view name
Disable or block application processing that executes dynamic DDL during online
patching.
This approach can only be used if the dependent functionality can be unavailable
for days at a time without disrupting normal customer operations.
This approach is meant only as a temporary workaround.
See:
Disabling Functionality while Online Patching, page 6-31
Blocking a Concurrent Program while Online Patching, page 6-31
PL/SQL Package
The package name must be a non-quoted identifier.
Note: Non-quoted identifiers may only use the following characters:
A-Z 0-9 _ # $. Quoted identifiers are reserved for use by the technology
components.
Usage Standards
No special considerations.

If the running application creates, replaces, or drops PL/SQL while a patch edition
exists, then the same action must be executed in the patch edition. This requirement can
be satisfied in either of two ways:
1.

Use AD_DDL, which will replicate the run edition DDL for PL/SQL in the patch
edition automatically.
For example:
-- Example of using AD_DDL to create a PL/SQL package
DECLARE
l_applsys_schema varchar2(30);
BEGIN
-- Get applsys schema name
SELECT user
INTO l_applsys_schema
FROM dual;
-- Build and create Package Spec
ad_ddl.build_package('create package FND_GB_TEST as', 1);
ad_ddl.build_package(' procedure test;', 2);
ad_ddl.build_package('end;', 3);
ad_ddl.create_package(l_applsys_schema, 'FND', 'FND_GB_TEST',
'FALSE', 1, 3);
-- Build and create Package Body
ad_ddl.build_package('create package body FND_GB_TEST as', 1);
ad_ddl.build_package(' procedure test is', 2);
ad_ddl.build_package(' begin null; end;', 3);
ad_ddl.build_package('end;', 4);
ad_ddl.create_package(l_applsys_schema, 'FND', 'FND_GB_TEST',
'TRUE', 1, 4);
END;
/
2.
Disable or block application processing that executes Dynamic DDL during online
patching.
for days at a time without disrupting normal customer operations.
See:
User-Defined Type (Editioned)

Same as PL/SQL packages.
Usage Standards
Editioned User-Defined Types may not be used as Column Types or Advanced Queue
(AQ) Payload Types.
To create a User-Defined Type for use as a column type, refer to the section on
Non-Editioned User-Defined Types later in this chapter.
Same as PL/SQL packages.
Due to database limitation, an existing Editioned User Defined Type may not be
evolved. This means that you cannot alter the structure of the type using the "ALTER
TYPE ..." statement. Use "CREATE OR REPLACE TYPE ..." instead. See: Oracle Database
PL/SQL Language Reference for more information on these statements.
PL/SQL Trigger
The trigger name must be a non-quoted identifier.

Note: Non-quoted identifiers may only use the following
characters: A-Z 0-9 _ # $. Quoted identifiers are reserved for use by

the technology components.
A table trigger must be on the editioning view (EV), not the table.
Triggers on tables will be automatically moved to the corresponding editioning
view during the Release 12.2 upgrade. For information on editioning views, see:
Oracle Database Advanced Application Developer's Guide.
Tip: The simplest way to comply with this standard is to create
triggers "on" the APPS table synonym. The trigger will be created
on whatever the synonym points to, which will be the editioning
view if it exists or the table if there is no editioning view.
Note: EV triggers reference logical columns via the editioning view.
The editioning view maps logical columns to the correct physical
table columns in each edition.

If the runtime application creates, replaces, or drops triggers while a patch edition
1.

Use AD_DDL, which will replicate run edition DDL for triggers in the patch edition
automatically.
For example:
/* Code example:
Create a trigger using AD_DDL */
declare
L_APP
varchar2(8);
begin
l_app := 'FND';
l_name := 'FND_EXAMPLE_TRG';
l_stmt :=
'create or replace trigger '||l_name||' '||
'before insert or update on fnd_user for each row '||
'begin '||
' ad_zd_log.message(''test'', ''STATEMENT'', ''hello!''); '||
'end;';
ad_ddl.do_ddl(
l_app,
product
ad_ddl.create_trigger,
l_stmt,
l_name
);
end;
/
2.

-- statement type
-- statement text
-- trigger name
patching. This approach can only be used if the dependent functionality can be
unavailable for days at a time without disrupting normal customer operations.
See:
Synonym
Most APPS synonyms are automatically created by the patching tool. Do not
replace or drop automatically managed synonyms unless directed by this standard.
A table synonym must point to the editioning view, not the table, if the editioning
view exists.
A synonym must point to an object.
Do not create public synonyms.
Usage Standards
Use APPS synonyms to reference objects in EBS product schemas. Do not reference
objects in Oracle E-Business Suite product schemas directly.
Note: The APPS synonym layer provides a Logical Schema view over
the physical objects in the Oracle E-Business Suite product schemas.

The logical schema is considered the stable public interface, while the
physical implementation may change without warning.
The Logical name for an object is its APPS synonym name.
The APPS synonym points to the Oracle E-Business Suite product

schema object that physically implements the logical name.
The APPS synonym is editioned and may point to different objects

in different editions of the application.
The APPS synonym for a table points to the editioning view instead
of the table, if the editioning view exists.

If the running application creates, replaces, or drops a synonym while a patch edition
1.

Use AD_DDL, which will replicate run edition DDL for synonyms into the patch
edition automatically.
Example:
/* Code example:
Create a synonym using AD_DDL */
declare
L_APP
varchar2(8);
begin
l_app := 'FND';
l_name := 'FND_USERS';
l_stmt :=
'create or replace synonym '||l_name||' for fnd_user';
ad_ddl.do_ddl(
l_app,
product
ad_ddl.create_synonym,
l_stmt,
l_name
);
end;
/
2.

-- statement type
-- statement text
-- view name
patching.
for days at a time without disrupting normal operations.
See:
Virtual Private Database (VPD) Policy

A VPD Policy must be on the editioning view or table synonym, not the table, if the
editioning view exists.
VPD Policies on tables will be automatically moved to the corresponding editioning
view during the Release 12.2 upgrade.
Effectively-Editioned Objects
These object types are non-editioned at the database level, meaning they have a single
definition that is visible to all database editions. But for each object in this category, the
Online Patching tools implement special support so that the object can be patched
without impacting the running application. New restrictions and standards apply to
each effectively-editioned object type.
Table (Ordinary)
An ordinary table is created, altered or dropped during application patching. In
contrast, a dynamic table is created, altered, or dropped by the application at runtime.
The standards in this section apply to ordinary tables only.
In order to implement effectively-editioned support for ordinary tables, the online
patching technology installs and maintains a new editioning view layer over each table.
The editioning view maps logical column names used by the application to the actual
storage columns used to hold those attributes in each edition. Although the editioning
view is maintained automatically during online patching, developers who create or
alter tables by hand in a development database must follow new procedures to
maintain the editioning view.
A table name must not end with the '#' character. (GSCC File.Gen.34)
A table name must be unique within the first 29 bytes.
A table must be owned by an Oracle E-Business Suite product schema or custom

product schema, not APPS. (GSCC File.Gen.35)
A table must have an editioning view.

Note that tables created via patching tools such as XDF/ODF will get an editioning
view automatically.
Also note that tables created via direct DDL get the editioning view by calling
AD_ZD_TABLE.UPGRADE.
An APPS synonym (serving as the logical table name) must point to the editioning
view.
The synonym is automatically installed by the AD_ZD_TABLE.UPGRADE
procedure.
A table must not be "index-organized" (create table ... ORGANIZATION INDEX).

Index-organized tables cannot be patched using online patching.
A column name must be a nonquoted identifier. For information on nonquoted

identifiers, see: Oracle Database SQL Language Reference.
A base column name may only use '#' as the last character. (GSCC File.Gen.36)
The base column name is the original column name before any revised columns are
created. The base column name is used as the logical column name exposed
through the editioning view.
A base column name should be 28 bytes or fewer. (GSCC File.Xdf.4)

Note: Online patching currently does not support patching
columns that violate this standard. If a violating column must be

patched, then it must be replaced with compliant column (that is,
with a shorter name) as part of the patch. Application code will
need to be updated to reference the new shorter column name.
The column type must be a built-in type or a user-defined type owned by a

non-editioned user. (GSCC File.Gen.37)
The column type must not be LONG or LONG RAW. See: LONG to CLOB
Conversion Procedures, page 6-34. (GSCC File.Xdf.4)
The column type should not be ROWID. (GSCC File.Xdf.4)

ROWID references can become invalid if the target table is patched, loaded, or
rebuilt. It is not safe to store ROWID references across an online patching cutover
boundary.
If adding a column with a default value, the column must be not null. Oracle
Database Advanced Compression requires that new columns with a default value
be not null.
Query/DML statements must access tables via the table synonym or editioning
view. (GSCC File.Gen.41)
If you query, display, or store table column names in your application runtime
code, you should use logical column names rather than physical column names in
most cases.
Usage Standards
Follow the Logical versus Physical Column Guidelines, page 6-23 for runtime
application code.
Warning: Some dictionary views (such as
ALL_TAB_COLUMNS) contain information for both Logical

and Physical table columns, depending on whether you query
the editioning view or base table data. Consult Logical versus
Physical Column Guidelines, page 6-23 for details.
Ensure your query obtains the logical or physical column information you
need.
DDL statements such as TRUNCATE will not work on an APPS table synonym that
points to an editioning view. To truncate a table, you must supply the actual base
table (owner.table_name) in the truncate command.
Tip: Generate truncate command dynamically based on the APPS
table synonym name as follows:

select 'truncate table
'||table_owner||'.'||ad_zd_table.ev_table(table_owner,t
able_name) from user_synonyms where
synonym_name=input_synonym_name;
Do not rely on the ordering of columns within the table, and do not assume that
additional columns are not present.
Specify an explicit column list when selecting
Bad: select * from table
Good: select col1, col2, ... from table
Specify an explicit column list when inserting
Bad: insert into table values (val1, val2, ...)
Good: insert into table (col1, col2, ...) values (val1, val2, ...)

Application-managed tables are tables that are created and maintained by
application logic during normal application runtime:
Application-managed (dynamic) tables must not have an editioning view.
Do not modify application-managed tables in an online patch. (GSCC

File.Gen.38)
Ordinary tables are created and maintained by online patching (and will have an
editioning view).
If the application logic modifies an ordinary table at runtime, it must use the
AD_DDL interface to execute the dynamic DDL.
Do not modify ordinary tables in the run edition while a patch edition exists.
Do not generate dynamic staging tables for the purpose of partition exchange
with a partitioned table. A dynamically-created staging table structure may fall
out of synchronization with the partitioned table during online patching.
Partitioned Tables may only exchange partitions with a permanent staging table
that is maintained with the same structure as the partitioned table during
online patching. For more information on Partition Exchange, see: My Oracle
Support Knowledge Document 1577661.1, Developing and Deploying
Customizations in Oracle E-Business Suite Release 12.2.
Seed Data Table

Seed Data Tables contain data owned by the application, and so the contents of these
tables may be changed during online patching. Seed data tables must implement the
Editioned Data Storage architecture, which allows the table to store separate run and
patch edition copies of seed data, so that changes from online patching do not affect
application runtime.
A seed data table must satisfy all requirements of an ordinary table.

A seed data table must implement editioned data storage.
Upgrade an ordinary table to editioned data storage upgrade by calling the

Seed Data Manager UPGRADE procedure
(AD_ZD_SEED.UPGRADE('TABLE_SYNONYM')). The upgrade API will make
the following changes automatically:
Add a new column: ZD_EDITION_NAME NOT NULL VARCHAR2(30)
Include ZD_EDITION_NAME column in all unique indexes and unique

constraints for the table.
Drop any foreign key constraints that reference the table.
Add EV trigger to populate ZD_EDITION_NAME column.
Add EV VPD Policy to filter rows based on ZD_EDITION_NAME column.
Block modification of run edition seed data content from the patch edition.
Seed data tables in Oracle E-Business Suite Release 12.2 must be upgraded to
editioned data storage during the upgrade to Release 12.2.
Each product must create a seed data table upgrade script using the
template below. Add one call to AD_ZD_SEED.UPGRADE for each seed
data table owned by the product.
Important: Do not call the UPGRADE procedure for tables
outside of your product; products must only upgrade the

tables that they actually own.
Template Seed Data Table Upgrade Script:

REM $Header: $
REM dbdrv: sql ~PROD ~PATH ~FILE none none none sqlplus
&phase=last+95 \
REM dbdrv: checkfile:~PROD:~PATH:~FILE
REM
/*============================================================
===========+
REM |
Copyright (c) 2012 Oracle, California, USA
|
REM |
All rights reserved.
|
REM
+=============================================================
==========+
REM | Seed Data Table Upgrade for Online Patching:
REM | Converts Seed Data Tables to support Editioned Data
Storage
REM
+=============================================================
==========*/
SET VERIFY OFF
WHENEVER SQLERROR EXIT FAILURE ROLLBACK;
WHENEVER OSERROR EXIT FAILURE ROLLBACK;
exec AD_ZD_SEED.UPGRADE('<seed_data_table_name>')
...
commit;
exit;
Example Seed Data Table Upgrade Script:
REM $Header: $
REM dbdrv: sql ~PROD ~PATH ~FILE none none none sqlplus
&phase=last+95 \
REM dbdrv: checkfile:~PROD:~PATH:~FILE
REM
/*============================================================
===========+
REM |
Copyright (c) 2012 Oracle, California, USA
|
REM |
|
REM
+=============================================================
==========+
REM | Seed Data Table Upgrade for Online Patching:
REM | Converts Seed Data Tables to support Editioned Data
Storage
REM
+=============================================================
==========*/
SET VERIFY OFF
WHENEVER SQLERROR EXIT FAILURE ROLLBACK;
WHENEVER OSERROR EXIT FAILURE ROLLBACK;
exec AD_ZD_SEED.UPGRADE('FND_NEW_MESSAGES')
exec AD_ZD_SEED.UPGRADE('FND_APPLICATION')
exec AD_ZD_SEED.UPGRADE('FND_APPLICATION_TL')
commit;
exit;
A seed data table must have a unique index.
Without a unique index, run edition updates to seed data cannot be

synchronized to the patch edition copy and will be lost.
This standard does not apply if the table is read-only to the runtime application.
Usage Standards
Ordinary table definition standards also apply to seed data tables.
"INSERT ALL" (as documented in Oracle Database SQL Language Reference) is no

longer supported against seed data tables. Re-code this statement as separate insert
statements.
Avoid use of the ZD_EDITION_NAME column in application logic:
Do not select, insert or update the ZD_EDITION_NAME column, or reference

the column value in any way.
Do not include ZD_EDITION_NAME in views, APIs, or any application logic.
Do not include ZD_EDITION_NAME in user interfaces, reports, or any other

user display.
Do not include ZD_EDITION_NAME in BC4J entity objects, view objects, or

any other automatically generated artifact. You might need to explicitly remove
the ZD_EDITION_NAME column from generated code.
Do not access seed data rows by ROWID (where rowid = <local_variable>)

from any code that can run in the patch edition.
Code that can run in the patch edition includes crossedition trigger logic, seed
data loader logic, SQL scripts in patches, and any code executed by the
patching tool itself.
In the patch edition, any locally held seed data ROWID may become invalid at
any time, if the related seed data table is prepared in a different session.
Do not under any circumstances disable the ZD_SEED VPD policy or generated
maintenance trigger on a seed data table.

Not applicable.
Seed Data Loader

FNDLOAD Configuration Files (LCT files) must include a PREPARE statement for
each entity listing the seed data tables that the UPLOAD command loads into.
Syntax:
PREPARE <entity>
TABLE <seed_data_table_name1>
TABLE <seed_data_table_name2>
...
<seed_data_table_name> is the name of the APPS synonym for the seed data table.
The ordering of UPLOAD / DOWNLOAD / PREPARE statements in an LCT file is
not important.
Note that an entity does not require a PREPARE statement if any of the following is
true:
The entity is not stored in a seed data table.
The entity is not patched during online patching or does not support UPLOAD.
The seed data tables loaded by a child entity are prepared by the parent entity.
The PREPARE call is already handled by the upload logic.
You should only list seed data tables that will be loaded. For example, if the upload
logic initially stores data in temporary tables, the temporary tables should not be
listed in the PREPARE statement. Only seed data tables can be prepared.
Example:
# $Header: wfmlrp.lct 120.0 2005/05/07 16:19:43 appldev ship $
COMMENT = "dbdrv: exec fnd bin FNDLOAD bin &phase=daa+52
checkfile:~PROD:~PATH:~FILE &ui_apps 0 Y UPLOAD
@FND:patch/115/import/wfmlrp.lct @~PROD:~PATH/~FILE"
DEFINE MAILERPARAMS
KEY NAME
VARCHAR2(12)
KEY PARAMETER
VARCHAR2(30)
BASE VALUE
VARCHAR2(200)
BASE REQUIRED
VARCHAR2(1)
BASE CALLBACK
VARCHAR2(60)
BASE ALLOWRELOAD VARCHAR2(1)
END MAILERPARAMS
DOWNLOAD MAILERPARAMS
"select NAME, PARAMETER, VALUE, REQUIRED, CB, ALLOW_RELOAD
from WF_MAILER_PARAMETERS
where NAME = :NAME"
###
### Do NOT call AD_ZD_SEED.PREPARE from the UPLOAD statement of an
LCT file.
### Use the LCT PREPARE statement instead (see below)
###
UPLOAD MAILERPARAMS
"begin
wf_mailer_parameter.PutParameter(:NAME, :PARAMETER,:VALUE,
:REQUIRED, :CALLBACK, :ALLOWRELOAD);
end;"
###
### New for Online Patching
###
PREPARE MAILERPARAMS
TABLE WF_MAILER_PARAMETERS
Other (non-FNDLOAD) Seed Data Loaders that will be used for online patching
must call the Seed Data Manager PREPARE procedure before loading data into a
table. Note that this requirement does NOT apply to scripts and loaders that will
only be used for the Oracle E-Business Suite Release 12.2 upgrade.
Syntax: AD_ZD_SEED.PREPARE('<table_name>');
Note: <seed_data_table_name> is the name of the APPS synonym for the seed data
table.
The AD_ZD_SEED.PREPARE procedure cannot be called from scripts using the
"dbdrv: sql ... sql" execute method. Use "dbdrv sql ... sqlplus" instead.
Bad Example: dbdrv: sql ~PROD ~PATH ~FILE none none none sql
&phase=upg+14 ...
Good Example: dbdrv: sql ~PROD ~PATH ~FILE none none none
sqlplus &phase=upg+14 ...
Execute the PREPARE call BEFORE loading data into the table. "Loading" includes
any modification of seed data content (insert, update, delete).
Example SQL script with AD_ZD_SEED.PREPARE procedure call:
REM $Header: $
REM dbdrv: sql ~PROD ~PATH ~FILE none none none sqlplus_single
&phase=daa \
REM dbdrv: checkfile(115.2=120.1):~PROD:~PATH:~FILE &un_fnd &pw_fnd
REM
/*==================================================================
=====+
REM |
Copyright (c) 2012 Oracle, Belmont, California, USA
|
REM |
|
REM
+===================================================================
====+
REM |
REM | NAME
REM |
ldrexample.sql
REM |
REM | DESCRIPTION
REM | This script adds a policy to the wf_signature_policies
REM
+===================================================================
====*/
SET VERIFY OFF;
WHENEVER SQLERROR EXIT FAILURE ROLLBACK
WHENEVER OSERROR EXIT FAILURE ROLLBACK
--- NEW FOR ONLINE PATCHING
-exec ad_zd_seed.prepare('WF_SIGNATURE_POLICIES')
insert into WF_SIGNATURE_POLICIES
(SIG_POLICY, SIG_REQUIRED, FWK_SIG_FLAVOR,
EMAIL_SIG_FLAVOR, RENDER_HINT, DEFAULT_POLICY)
select 'DEFAULT', 'N', Null, Null, Null, 'Y'
from dual
where not exists
(select 1
from WF_SIGNATURE_POLICIES
where SIG_POLICY = 'DEFAULT');
commit;
exit;
Seed data upload logic executed during online patching must not reference
materialized views, since materialized views are non-editioned objects and will be
defined according to the run edition rather than the patch edition.
Seed data upload logic may not reference seed data rows by ROWID.
Usage Standards
Not applicable.
Index
The index name must contain an underscore ('_'). (GSCC File.Gen.39)

The unique index on a seed data table must include ZD_EDITION_NAME.
Note: This rule will be implemented automatically when you call
"ad_zd_seed.upgrade" on your seed data table, but if you add a

new unique index to an existing seed data table you will need to
include the ZD_EDITION_NAME column in your index definition.
The unique index on a seed data table should have at least one not-null column
besides ZD_EDITION_NAME.
Note: If the unique index has all nullable columns, then each row in
the table must have at least one non-null column value for the
indexed columns. You must ensure that this is true as part of the
Oracle E-Business Suite 12.2 upgrade (select rows where all
indexed columns are null and either delete or update as needed to
meet this standard).
The index key length should be less than 3125 bytes.

The index key length is the sum of the column lengths for each column in the index,
plus one byte for each column.
If the index key length is greater than 3125 bytes, then the index cannot be revised
using online index definition, and a full table lock will be held during index
revision.
A function-based index must not reference editioned Oracle E-Business Suite

objects (built-in database functions such as "UPPER()" are acceptable).

The "CREATE INDEX ... ON ..." statement must specify the fully qualified table name,
not the APPS table synonym.
Good Example: create index SOME_TABLE_N1 on SCHEMA.SOME_TABLE

...
Bad Example: create index SOME_TABLE_N1 on SOME_TABLE ...
Integrity Constraint
The constraint name must contain an underscore ('_').

Do not create a primary key constraint on a table. Create a unique index or unique
constraint instead.
An existing primary key constraint will work, but it is not possible to create a
revised primary key constraint in an online patch.
Do not create a unique key constraint on a table. Create a unique index instead.
An existing unique key constraint will work, but if the key is ever revised the
unique key constraint will be dropped along with any foreign key constraints that
reference it. Unique constraints are not automatically revised by online patching.
Do not create a foreign key constraint on a table. If the referenced primary or

unique key is dropped, then the foreign key will also be dropped. Foreign key
constraints are not automatically revised by online patching.
A foreign key constraint cannot be created to a seed data table.

Materialized View (MV)

A materialized view is a non-editioned object type, and therefore a materialized view
cannot directly reference editioned objects. To avoid this limitation, Oracle E-Business
Suite online patching technology implements a new effectively-editioned materialized
view compound object. Application developers create and maintain the materialized
view definition (query) in an ordinary view. The online patching technology then
automatically maintains a corresponding materialized view implementation that is legal
for editioned databases.

Note: Oracle Database 12.1.0.2 introduces a new feature to materialized
view create syntax called the Evaluation Edition clause. This feature
allows a native materialized view definition to reference editioned
objects in the specified evaluation edition. Customers who wish to
create custom materialized views may use native materialized views
with the evaluation edition clause instead of following the
"effectively-editioned materialized view" standards in this section.
Definition Standards:
A materialized view name must be unique within the first 29 bytes.
A materialized view definition must be stored in an ordinary view called

MV_NAME||'#'.
Create or replace the materialized view definition as an ordinary view called

mv_name||'#'.
Test the materialized view definition for accuracy before generating the
materialized view implementation.
For example:
create or replace view FND_EXAMPLE_MV# as select ... ;
select * from fnd_example_mv#;
The materialized view implementation is automatically generated from the

materialized view definition using the AD_ZD_MVIEW.UPGRADE procedure.
Syntax is exec ad_zd_mview.upgrade(<MV_OWNER>, <MV_NAME>)
Do not attempt to directly create or replace the materialized view implementation.
To recreate an MV implementation, call the AD_ZD_MVIEW.UPGRADE
procedure.
A materialized view definition must specify a column alias for each item in the
select list.
Failure to specify a column alias may cause the error ORA-00998 "must name
this expression with a column alias".
Example: change select sum(EMP.SALARY), ... to select

sum(EMP.SALARY) SUM_EMP_SALARY, ...
A materialized view definition must not reference editioned PL/SQL functions.
If the materialized view definition references an editioned PL/SQL function,

then the materialized view implementation will fail to generate and the
materialized view will be unusable.
For examples of replacing PL/SQL function calls with equivalent SQL in

materialized views, see: Examples of SQL Replacements for PL/SQL Functions,
page 6-32.
A materialized view should use 'REFRESH FORCE' instead of 'REFRESH FAST'.

The 'FORCE' option allows the materialized view to fall back to using a complete
refresh in situations where the fast refresh is not possible.
See: Oracle Database SQL Language Reference for more information on the "REFRESH
FORCE" option.
If the materialized view implementation content must be automatically refreshed

after patching, then you must include the '/*AUTOREFRESH*/' comment tag in the
materialized view definition query.
Do not specify the /*AUTOREFRESH*/ tag for large materialized views that will
take a long time to refresh. For these cases use a concurrent program to refresh
the materialized view after patching cutover.
Example: create or replace view FND_EXAMPLE_MV# as select

/*AUTOREFRESH*/ ... ;
Usage Standards
Do not assume that fast refresh is always possible. After an online patch, complete
refresh may be required. When refreshing a materialized view, us the 'FORCE' clause
instead of 'FAST'.
See: Oracle Database SQL Language Reference for more information on the 'FORCE'
option.
Use AD_MV to execute dynamic DDL for materialized views. Here is an example of
creating a materialized view using the AD_MV package:
--- Code Example: Create a materialized view using AD_MV interface.

--- Note:
-when executed in the Run Edition, the MV is created immediately.
-when executed in the Patch Edition, the MV is generated at
CUTOVER.
-begin
-- Create MV
ad_mv.create_mv('FND_EXAMPLE_MV',
'create materialized view FND_EXAMPLE_MV '||
' tablespace '||ad_mv.g_mv_data_tablespace||' '||
' build deferred refresh on demand as '||
'select '||
'
upper(oracle_username) USERNAME '||
' ,
decode(read_only_flag,''C'',''pub'',''E'',''applsys'',''U'',''apps'')
USERTYPE '||
'from fnd_oracle_userid '||
'where read_only_flag in (''C'',''E'',''U'') ');
end;
Logical versus Physical Table Columns

In Oracle E-Business Suite Release 12.2, the online patching architecture introduces a
new editioning view (EV) layer over developer-managed tables. The EV layer provides
a stable logical view of the table information to the application, even though the names
of the physical storage columns will change with online patching. The EV maps each
logical column name to the latest revised storage column for that attribute. The runtime
application is expected to access table data via this logical view.
Effectively-editioned tables are patched using online patching techniques that will
cause the physical storage column names to be different from the logical column names
over time. This logical-to-physical column name mapping is transparent to the
application for normal query and DML statements, but if the application queries
database data dictionary views, then it must take care select the correct (logical or
physical) column names depending on the purpose for getting the names.
If column names are selected for the purpose of constructing query or DML
statements (select, insert, update, or delete) then you must select logical column
names.
If column names are selected for the purpose of constructing table DDL statements
(for example, to create an index), then you must select physical column names.
Normally, application runtime code should not be modifying tables that are
managed through online patching, so this should be a rare situation.
Note that the distinction between logical and physical columns only exists for table
columns where the table has an editioning view. If you are getting column information
for any object that does not have an editioning view then you do not need to make any
changes. Queries that do not need to be changed include:
Queries that run as part of the Oracle E-Business Suite Release 12.2 upgrade.
During the main upgrade phase editioning views are not yet installed, and so all
existing upgrade scripts will work correctly.
Queries for view column information.
Queries for table column information, where the table does not have an editioning
view. This category includes:
Temporary tables.
Application-managed (dynamically generated) tables. Application-managed

tables are database tables that are dynamically created and managed by
application logic during runtime. Whenever the application generates such
tables, it is expected that the application will also modify, replace or drop the
tables as needed during application runtime. It is also expected that
application-managed tables will not be directly modified by online patches.
Advanced Queue tables.
Materialized view container tables.
Index-organized tables.
Any other exception tables that do not have an editioning view.
Database Data Dictionary Views involving Columns

MIXED USE Dictionary Views
Dictionary views in this category contain information for both logical and physical table
columns, depending on how the view is queried. You must examine each reference to
these dictionary views and determine whether you intend to select logical or physical
column information.
ALL_TAB_COLUMNS, DBA_TAB_COLUMNS, USER_TAB_COLUMNS
ALL_TAB_COLS, DBA_TAB_COLS, USER_TAB_COLS
ALL_COL_COMMENTS, DBA_COL_COMMENTS, USER_COL_COMMENTS
ALL_OBJ_COLATTRS, DBA_OBJ_COLATTRS, USER_OBJ_COLATTRS
ALL_TRIGGER_COLS, DBA_TRIGGER_COLS, USER_TRIGGER_COLS
ALL_UPDATABLE_COLUMNS, DBA_UPDATABLE_COLUMNS,
USER_UPDATABLE_COLUMNS
To select physical (table) column names, select from the dictionary view for a specific
physical table name (where table_name = x_table_name). You can use where
table_name not like '%# to search across all tables while excluding logical views.
To select logical (EV) column names, select from the dictionary view for a specific
editioning view name, where table_name = ad_zd_table.ev_view(x_table_name).
Another way to get the logical view information is to start with the APPS synonym and
join the synonym table_name to the dictionary view to get the correct logical view
information. The APPS synonym will point to the EV if one exists, or directly the
physical table if there is no EV. This will provide correct logical column results in either
case.
/*
** This query returns logical columns for the table pointed to by APPS
** table synonym X_SYNONYM_NAME. Compatible with old releases.
*/
select col.column_name
from user_synonyms syn, all_tab_columns col
where syn.synonym_name = x_synonym_name
and col.owner
= syn.table_owner
and col.table_name = syn.table_name
order by col.column_id
/
If you do not know whether you are querying a table or a view, you can union the
results from the two possible queries:
/*
** This query returns logical columns for X_OBJECT_NAME, and works
whether
** the object is an APPS table synonym or view. Compatible with old
releases.
*/
select col.column_name, col.data_type
from user_synonyms syn, all_tab_columns col
where syn.synonym_name = x_object_name
and col.owner
= syn.table_owner
and col.table_name = syn.table_name
union
select col.column_name, col.data_type
from user_tab_columns col
where col.table_name = x_object_name
/
If the application logic must use a physical table name as the input rather than the APPS
object name, and you are sure that the table has an editioning view, then you can just
convert the table name to the editioning view name with a utility function:
*
** This query returns logical columns for effectively editioned table
** X_OWNER.X_TABLE_NAME. Use this only if you cannot start from
** the APPS synonym name and are sure that the table has an EV.
** This query works on Oracle E-Business Suite Release 12.2 only.
*/
select col.column_name
from all_tab_columns col
where col.owner
= x_owner
and col.table_name = ad_zd_table.ev_view(x_table_name)
order by col.column_id
/
In the most general (worst) case, your application code may not be able to guarantee
that the input table name has an EV. In this case you can outer-join to the EV
information to provide logical column names if they exist, or physical columns if they
do not:
/*
** This query returns the logical columns for table
X_OWNER.X_TABLE_NAME.
** If the table has an editioning view, then the editioning view columns
are
** returned, otherwise the physical table columns are returned.
** ONLY use this query if you must query by physical table name rather
** than APPS synonym name and the table might not have an EV.
** This query works on Oracle E-Business Suite Release 12.2 only.
*/
select
col.owner
, col.table_name
, decode(ev.view_name, NULL, col.column_name, evc.view_column_name)
logical_column_name
, col.column_name physical_column_name
from
all_tab_columns col
, all_editioning_views ev
, all_editioning_view_cols evc
where col.owner
=
x_owner
and col.table_name
= x_table_name
and ev.owner(+)
= col.owner
and ev.table_name(+) = col.table_name
and evc.owner(+)
= ev.owner
and evc.view_name(+) = ev.view_name
and (ev.view_name is null or evc.table_column_name = col.column_name)
order by col.owner, col.table_name, evc.view_column_id
/
Logical (EV) Column Information Only

Dictionary views in this category only provide information about logical columns. You
will only need to join to these views if you are trying to map physical column names to
logical column names yourself.
ALL_EDITIONING_VIEW_COLS, DBA_EDITIONING_VIEW_COLS,
USER_EDITIONING_VIEW_COLS
ALL_EDITIONING_VIEW_COLS_AE, DBA_EDITIONING_VIEW_COLS_AE,
USER_EDITIONING_VIEW_COLS_AE
Physical (Table) Column Information Only

The following dictionary views provide information about physical table columns. Any
use of these views is likely for the purpose of managing the actual physical tables, and it
is not expected that such references need to be converted to use logical column names.
But it is worth checking.
ALL_AUDIT_POLICY_COLUMNS, DBA_AUDIT_POLICY_COLUMNS,
USER_AUDIT_POLICY_COLUMNS
ALL_CONS_COLUMNS, DBA_CONS_COLUMNS, USER_CONS_COLUMNS
ALL_IND_COLUMNS, DBA_IND_COLUMNS, USER_IND_COLUMNS
ALL_IND_EXPRESSIONS, DBA_IND_EXPRESSIONS, USER_IND_EXPRESSIONS
ALL_LOBS, DBA_LOBS, USER_LOBS
ALL_LOB_PARTITIONS, DBA_LOB_PARTITIONS, USER_LOB_PARTITIONS
ALL_LOB_SUBPARTITIONS, DBA_LOB_SUBPARTITIONS,
USER_LOB_SUBPARTITIONS
ALL_PART_KEY_COLUMNS, DBA_PART_KEY_COLUMNS,
USER_PART_KEY_COLUMNS
ALL_PART_LOBS, DBA_PART_LOBS, USER_PART_LOBS
ALL_STREAMS_COLUMNS, DBA_STREAMS_COLUMNS,
USER_STREAMS_COLUMNS
ALL_SUBPART_KEY_COLUMNS, DBA_SUBPART_KEY_COLUMNS,
USER_SUBPART_KEY_COLUMNS
ALL_UNUSED_COL_TABS, DBA_UNUSED_COL_TABS,
USER_UNUSED_COL_TABS
ALL_XML_TAB_COLS, DBA_XML_TAB_COLS, USER_XML_TAB_COLS
Non-Editioned Objects
Non-editioned objects have the same definition shared across application editions. Such
objects must be patched carefully to avoid affecting the running application. In general,
you must not change the definition of an existing non-editioned object during an online
patch. Instead, create a new object with a different name, and change the original APPS
synonym to point at the new non-editioned object.
Sequence
Usage Standards
User-Defined Type (UDT) (Non-Editioned)

The type owner must be the "non-editioned APPS" user: APPS_NE

Create an APPS synonym that points to the APPS_NE type.
Note: Existing User-Defined Types that are referenced by table columns
or AQs will be automatically upgraded to conform to Non-Editioned

UDT standards during the Release 12.2 upgrade.
Usage Standards
Non-editioned objects (Columns or Advanced Queue payload definitions) must

reference a non-editioned UDT using its fully-qualified name:
APPS_NE.<type_name>
Editioned objects should reference a non-editioned UDT using its APPS synonym.

Not applicable.
Temporary Table
A Temporary Table must be owned by an Oracle E-Business Suite product schema, not
APPS.
An APPS synonym (serving as the logical table name) must point to the temporary
table.
Note: Unlike ordinary tables, temporary tables do not have editioning
views.
Usage Standards
Advanced Queue (AQ)

AQ Payload type must be a non-editioned UDT owned by APPS_NE and referenced by
its fully qualified name; for example: APPS_NE.<type_name>.
Note: Existing AQ Payload types that reference editioned User-Defined
Types will be automatically upgraded to reference the corresponding

Non-Editioned User-Defined Type during the Release 12.2 upgrade.
Note that AQ Tables do not get an editioning view.

Usage Standards
Application Context
Usage Standards
XML Schema
The XMLSCHEMA owner must be the "non-editioned APPS" user: APPS_NE.

Existing XMLSCHEMA types will be automatically upgraded to comply with this
standard during the Release 12.2 upgrade.
Reference the XMLSCHEMA using its fully qualified name:
APPS_NE.<xmlschema_name>.
Usage Standards
Database Link
Not applicable.
Usage Standards
Accessing objects over a database link always uses the run edition of the target
database, even if the access originates from the patch edition.
External Data File

An external data file is user or business data stored on the file system rather than in the
database. Examples of external data files include concurrent report output, log files,
data import/export files, and file-based system integration. External data files are either
human readable or have a structure that is mostly independent of the application code
level. These files are not directly patched by Oracle E-Business Suite and (like other
types of business data) they should not be editioned.
In Oracle E-Business Suite Release 12.2, the APPL_TOP file system is now editioned,
and is no longer suitable for storing external data files. The online patching architecture
therefore introduces a new non-editioned file system for the purpose of holding
external data files and any other non-editioned files.
Configure your application to store or access external data files in the non-editioned file
system: APPL_TOP_NE.
Non-editioned file types include:
Report, output, and log files
Import and export files
File-based system integration
Any other data files that are dynamically generated or consumed by the
runtime application
APPL_TOP_NE has the same structure as a classic APPL_TOP:
$APPL_TOP_NE/<product_short_name>/<directory_name_used_bef
ore>/
Subdirectories are sparsely populated (only created as needed).
Usage Standards
Reference the non-editioned APPL_TOP using the 'APPL_TOP_NE' environment
variable.
For example, $APPL_TOP_NE/fnd/import
Example of Disabling Functionality During Online Patching

Here is a code example for disabling functionality while online patching.
--- Test if online patching is in progress, if so, block execution
-if ad_zd.get_edition('PATCH') is not null then
-- an online patch is in progress, return error
fnd_message.set_name('FND', 'AD_ZD_DISABLED_FEATURE');
raise_application_error ('-20000', fnd_message.get);
end if;
Blocking a Concurrent Program while Online Patching

To block a concurrent program from executing while Online Patching is in progress,
you must define an incompatibility rule for the concurrent program, as follows:
1.
Use the Concurrent Program window or page to edit your concurrent program
definition.
2.
Select the Incompatibilities button to open the Incompatible Programs window.
3.
Add a new global incompatibility rule for your program with the following
program:
Application Name: Applications DBA
Program Name: Online Patching In Progress (internal name: ADZDPATCH)

concurrent program
Examples of SQL Replacements for PL/SQL Functions

To "edition-enable" the APPS schema, non-editionable objects must not depend on
editionable objects. To meet this requirement, the database object development
standards specify that materialized views (which are non-editionable) must not call
PL/SQL functions (which are editionable).
The examples below demonstrate how to replace frequently-used Oracle Applications
Technology PL/SQL function calls with an equivalent SQL in materialized views. You
may continue to call built-in PL/SQL functions such as "upper()".
Replacing fnd_profile.value() with an SQL sub-select

Before:
fnd_profile.value('MSC_HUB_REGION_INSTANCE')
After:
(select profile_option_value from fnd_profile_option_values
where level_id = 10001 and (profile_option_id, application_id) =
(select profile_option_id, application_id from fnd_profile_options
where profile_option_name = 'MSC_HUB_REGION_INSTANCE'))
Notes:
This replacement is valid only in a materialized view. For other uses of

fnd_profile.value(), continue using the normal PL/SQL call.
The general case for fetching profile option values is very complex, that is why
there is a PL/SQL package dedicated to doing it. But materialized views results
have to be valid in any context, so profile options referenced in materialized views
should only have site level values, and the replacement SQL only needs to support
fetching the site level value.
This replacement SQL will only use the profile option value set at site level.
Replacing fnd_message.get_string() with an SQL sub-select

Before:
fnd_message.get_string('MSC','MSC_HUB_UNASSIGNED')
After:
(select substrb(REPLACE(message_text, '&&', '&'),1,2000)
from fnd_new_messages m, fnd_application a
where m.message_name = 'MSC_HUB_UNASSIGNED'
and m.language_code = 'US'
and a.application_short_name = 'MSC'
and m.application_id = a.application_id)
Notes:
This replacement is valid only in a materialized view. For other uses of

fnd_message.get_string(), continue using the normal PL/SQL call.
This replacement SQL will only retrieve the US language message text and is not
sensitive to any session language settings.
Materialized view queries cannot contain a sub-SELECT within the main SELECT
clause; therefore, the replacement SQL needs to be more sophisticated if the
function call was used in the MV SELECT clause.
Before:
select fnd_message.get_string('FND', 'CANCEL')
from dual
where 1=1
/
After:
select fmgs.result
from dual
, (select substrb(REPLACE(message_text, '&&', '&'),1,2000) result
from fnd_new_messages m, fnd_application a
where m.message_name = 'CANCEL'
and m.language_code = 'US'
and a.application_short_name = 'FND'
and m.application_id = a.application_id) fmgs
where 1=1
/
Replacing fnd_global.lookup_security_group() with an SQL sub-select

Before:
fnd_global.lookup_security_group('INTEREST_STATUS', 279)
After:
(select nvl(max(lt.security_group_id), 0)
from fnd_lookup_types lt
where lt.view_application_id = 279
and lt.lookup_type = 'INTEREST_STATUS'
and lt.security_group_id in (
0,
to_number(decode(substrb(userenv('CLIENT_INFO'),55,1),
' ', '0',
null, '0',
substrb(userenv('CLIENT_INFO'),55,10)))))
Note: This replacement is valid only in a materialized view. For other uses of
fnd_global.security_group(), continue using the normal PL/SQL call.
LONG to CLOB Conversion Procedures

As stated earlier, table column cannot be of type LONG or LONG RAW in Oracle
E-Business Suite Release 12.2. With Online Patching, LONG and LONG RAW columns
cannot be referenced in a database trigger. This restriction means that: LONG and
LONG RAW columns cannot be patched via an online patch as the feature uses
crossedition triggers to upgrade data. Changes to seed data in the RUN edition cannot
be propagated to the PATCH edition because crossedition triggers are used to
synchronize the changes.
This section describes some of the conversion procedures to change usages of LONG to
CLOB.
Oracle Forms
For each table column that has been changed from LONG to CLOB, any form block item
that has references to the column will need to have its Oracle Forms data type changed
from 'Char' to 'Long'. Remember that CLOB is the database column type and 'Long' is
the Forms item data type. To change the form's data type, open your form in the Forms
Builder and open the property sheet (Property Palette) for the item that references the
CLOB.
Scan your form and form library code for any references to the modified form item.
Since the form item is now a Forms Long data type, functions like LENGTH(),
LENGTHB(), SUBSTR() may behave differently. Thoroughly test your form to exercise
the logic referencing the Forms Long data type.
Pro*C / C
If you are binding a LONG or LONG RAW that is being changed to a CLOB, then you
should change the bind from SQLT_LNG to SQLT_CLOB. Otherwise, an unknown
datatype error will be thrown.
If you are using UPI code, ensure that you have applied the RDBMS patch 13259364.
PL/SQL
Check all packages to ensure that all affected variables are changed from LONG to
CLOB.
Examples (with updated variables):
PROCEDURE insert_flex_validation_events( flex_value_set_id IN NUMBER,
event_code IN varchar2, user_exit IN CLOB)
document_long_text CLOB;
document_long_text fnd_documents_long_text.long_text%type;
Java
In JDBC 2.0 and 3.01, you should fetch the data from a CLOB column using
ResultSet.getClob() to obtain a reference to the column, and then obtain a
character input stream object to read the contents of the CLOB field in a parallel fashion.
Because Oracle Database 11.2.0.4 (and later) JDBC drivers fully implement
getString() for CLOBs, no program conversion should be necessary.
Oracle Application Framework

BC4J and UIX data binding is very sensitive to data types. As such, the recommendation
is to perform the following steps for queries that are affected by the data type change.
Model
Entity Objects (EO) - The datatype of the attributes should be changed.
Attribute type - Should be changed to CLOBDOMAIN.
Database column field for the attribute - The type should be changed to
CLOB.
Read-only View Objects (VO) (not associated to an EO): The datatype of the
attributes should be changed.
Attribute type - Should be changed to CLOBDOMAIN.
Database column field for the attribute - The type should be changed to
CLOB.
VOImpl.java, EOImpl.java, AMImpl.java - Changes should be made to custom

methods (that are not part of the standard definition of the superclass object).
This convention is in case attributes are manipulated and the real datatype
(CLOBDOMAIN) needs to be used.
After your modifications, perform suitable tests using the BC4J tester object.
View
Attribute type of the item (messageTextInput) was changed from VARCHAR2

(compatible with LONG) to CLOB.
Controllers were modified to replace references to datatypes when there is

string manipulation.
Export button - If there is any manipulation of standard data handling with the
export bean, it should be modified to reference the correct data types.
Refer to the Oracle Application Framework documentation for more information on

Oracle Application Framework development.

Index
A
adop
online patching tool, 4-12
online patching utility, 4-1
ADZDPAUT.sql, 5-5
ADZDPMAN.sql, 5-5
ADZDPSUM.sql, 5-5
fs_ne
See non-editioned file system
C
cover layer
in online patching of data, 4-7
CPU
requirements, 2-1
crossedition trigger
in online patching, 4-6
D
Database
memory requirements, 2-2
dual file system
definition, 4-10
E
edition
Edition-Based Redefinition, 4-6
editioned data storage
editioning view
definition, 4-6
G
Global Standards Compliance Checker (GSCC),
5-6
L
log files
disk space, 2-4
purging, 2-4
logical view
of data model, 4-6
M
Memory requirement for Oracle E-Business
Suite, 2-2
N
non-editioned file system
used in online patching, 4-10
O
old edition
online patching, 4-1
Online patching, 4-1
Online Patching
introduction, 1-1
Index-1
online patching cycle

introduction, 4-2
other files
disk space, 2-4
output files
purging, 2-4
output files
disk space, 2-4
P
patch edition
patches
disk space, 2-4
patch file system, 4-10
phases
of online patching, 4-2
R
run edition
run file system, 4-10
S
seed data
sizing
suggestions, 2-1
T
temporary directories
disk space, 2-4
temporary files
disk space, 2-4
temporary space
required for installation, 2-4
Index-2

Planning

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Planning

Încărcat de

Drepturi de autor:

Formate disponibile

Oracle E-Business Suite

Technical Planning Guide, First Edition

Send Us Your Comments

Technology Stack Considerations

Introduction to Online Patching

Preparing for Online Patching

Running the Global Standards Compliance Checker (GSCC)................................................ 5-6

Development Standards for Online Patching

Are the implementation steps correct and complete?

The principles and customary practices of your business area.

Computer desktop application usage and terminology.

Access to Oracle Support

Related Information Sources

Oracle Electronic Technical Reference Manual - The Oracle Electronic Technical

Do Not Use Database Tools to Modify Oracle E-Business Suite Data

Purpose of this Book

Hardware Sizing Requirements

Required response times of the business

Number of concurrent users and their usage profiles

Hardware Resources 2-1

The chosen deployment topology

Actual Cores Count = Processor Count * CoresCountPerProcessor

Logical Processor Count = Actual CoresCount * ThreadCount

You should also consult your platform vendor as required.

Oracle Database overhead

Size of System Global Area (SGA)

Number of concurrent users

various Oracle E-Business Suite Database components, refer to My

Minimum Memory for an Oracle E-Business Suite Installation

2-2 Oracle E-Business Suite Technical Planning Guide, First Edition

Important: For detailed guidance and recommendations on this subject,

refer to the section, "Database and Application Tier Sizing."

Single-User Single-Machine Non-Production System

Disk Space Requirements

Database node file system (Fresh install)

90 GB (includes database files and 12cR1

Database node file system (Vision Demo

200 GB (includes database files and 12cR1

Applications node file system (OracleAS 10.1.2

64 GB (for dual file system). Also, see Note

Note: The minimum recommended space required for each active

language is 16 GB in the file system (for both APPL_TOPs), and 3 GB in

Hardware Resources 2-3

database size, care should be taken to size it according to the enterprise

Oracle E-Business Suite log and output files

Temporary directories and files

Updates and patches

2-4 Oracle E-Business Suite Technical Planning Guide, First Edition

Operating system software

Custom applications development files

Files for any other software that you use

Additional Guidelines for Database and Application Tier Sizing

These guidelines were derived using Oracle's hardware and networking

Oracle Application Framework Transactions

Hardware Resources 2-5

memory, and your specific requirements may need more.

Oracle Forms Transactions

Required Machine Memory

2-6 Oracle E-Business Suite Technical Planning Guide, First Edition

Number of Oracle Forms Sessions

Required Machine Memory

Application Tier Memory

Technology Stack Memory

Concurrent Manager Memory