Professional Documents
Culture Documents
Planning PDF
Planning PDF
Planning PDF
April 2016
Oracle E-Business Suite Technical Planning Guide, First Edition, Release 12.2
Copyright 2012, 2016, Oracle and/or its affiliates. All rights reserved.
Contributing Author: Samer Barakat, Santiago Bastidas, Deepak Bhatnagar, George Buzsaki, Steven Chan,
Kevin Hudson, Lisa Parekh, Scot Robson
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
Preface
1 Introduction
Purpose of this Book................................................................................................................. 1-1
2 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
iii
Running the Global Standards Compliance Checker (GSCC)................................................ 5-6
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.
v
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.
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.
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
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.
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.
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
Introduction 1-1
2
Hardware Resources
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 manager processes and the types of jobs that they are
running
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
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
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.
Database node file system (Fresh install) 90 GB (includes database files and 12cR1
database Oracle Home).
Database node file system (Vision Demo 200 GB (includes database files and 12cR1
database) database Oracle Home).
Applications node file system (OracleAS 10.1.2 64 GB (for dual file system). Also, see Note
Oracle Home, Oracle FMW Oracle Home, below for language (NLS) considerations.
COMMON_TOP, APPL_TOP, and
INST_TOP)
Stage area
For a production database installation, running Rapid Install from a stage area requires
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.
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.
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:
Online backups
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).
Note: The figures in the table do not take into account any Online
Patching requirements.
0-10 4 GB 2 6 GB 2
100-200 8 GB 2 8 GB 2
200-400 12 GB 4 10 GB 4
400-800 20 GB 8 14 GB 8
You should plan your resources using the above figures as guidelines.
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:
100 3 GB
200 6 GB
400 12 GB
800 24 GB
JVM Memory
Forms Memory
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.
Number of CPUs: 24
Note: The database tier and application tier are on the same machine in
this example.
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.
The reduction in database size is a result of multiple obsolete schemas and objects being
removed from the upgraded system.
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).
ORACLE_HOME 9 GB 9.3 GB
APPL_TOP 51 GB N/A
INST_TOP 27 MB N/A
fs_ne N/A 1 GB
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.
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.
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
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.
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.
Apply
Executes patch drivers to update patch edition.
Finalize
Compiles invalid objects.
Cutover
Cleanup
Delete obsolete code and seed data to recover space.
2. The patch edition files become an exact copy of the run edition files.
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.
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 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.
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.
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.
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:
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.
Updates to seed data in the run edition are automatically propagated to the patch
edition by the use of crossedition triggers.
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).
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.
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
Files containing transactions that are needed across all file systems.
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.
Running the Summary Readiness Report and the Manual Fix Readiness Report
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.
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.
Note: The DBCC utility cannot give a complete report until the
system has online patching enabled.
9. Fix any errors and repeat Step 8 until no errors are reported.
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
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.
SYSTEM
CTXSYS
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.
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.
The running application must replicate dynamic changes to editioned objects to the
Patch Edition.
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.
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.
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, -- applsys schema name
l_app, -- application short name for your
product
ad_ddl.create_view, -- statement type
l_stmt, -- statement text
l_name -- view name
);
end;
/
2. 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
PL/SQL Package
Definition Standards
The package name must be a non-quoted identifier.
Usage Standards
No special considerations.
DECLARE
l_applsys_schema varchar2(30);
BEGIN
-- Get applsys schema name
SELECT user
INTO l_applsys_schema
FROM dual;
2. 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
Definition Standards
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.
PL/SQL Trigger
Definition Standards
The trigger name must be a non-quoted identifier.
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.
declare
L_APP varchar2(8);
L_NAME varchar2(30);
L_STMT varchar2(32000);
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(
ad_zd.applsys_schema, -- applsys schema name
l_app, -- application short name for your
product
ad_ddl.create_trigger, -- statement type
l_stmt, -- statement text
l_name -- trigger name
);
end;
/
2. 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
Definition Standards
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.
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 for a table points to the editioning view instead
of the table, if the editioning view exists.
declare
L_APP varchar2(8);
L_NAME varchar2(30);
L_STMT varchar2(32000);
begin
l_app := 'FND';
l_name := 'FND_USERS';
l_stmt :=
'create or replace synonym '||l_name||' for fnd_user';
ad_ddl.do_ddl(
ad_zd.applsys_schema, -- applsys schema name
l_app, -- application short name for your
product
ad_ddl.create_synonym, -- statement type
l_stmt, -- statement text
l_name -- view name
);
end;
/
2. 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 operations.
This approach is meant only as a temporary workaround.
See:
Disabling Functionality while Online Patching, page 6-31
Definition Standards
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
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.
Definition Standards
A table name must not end with the '#' character. (GSCC File.Gen.34)
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 base column name may only use '#' as the last character. (GSCC File.Gen.36)
The column type must not be LONG or LONG RAW. See: LONG to CLOB
Conversion Procedures, page 6-34. (GSCC File.Xdf.4)
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.
Usage Standards
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.
Follow the Logical versus Physical Column Guidelines, page 6-23 for runtime
application code.
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.
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: insert into table (col1, col2, ...) values (val1, val2, ...)
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.
Definition Standards
A seed data table must satisfy all requirements of an ordinary table.
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.
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
+=============================================================
==========*/
exec AD_ZD_SEED.UPGRADE('<seed_data_table_name>')
...
commit;
exit;
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
+=============================================================
==========*/
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;
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.
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.
Definition Standards
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.
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
REM
/*==================================================================
=====+
REM | Copyright (c) 2012 Oracle, Belmont, California, USA
|
REM | All rights reserved.
|
REM
+===================================================================
====+
REM |
REM | NAME
REM | ldrexample.sql
REM |
REM | DESCRIPTION
REM | This script adds a policy to the wf_signature_policies
REM
+===================================================================
====*/
--
-- NEW FOR ONLINE PATCHING
--
exec ad_zd_seed.prepare('WF_SIGNATURE_POLICIES')
commit;
exit;
Seed data upload logic may not reference seed data rows by ROWID.
Usage Standards
No special considerations.
Index
Definition Standards
The index name must contain an underscore ('_'). (GSCC File.Gen.39)
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).
Integrity Constraint
Definition Standards
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.
Definition Standards
Definition Standards:
A materialized view name must be unique within the first 29 bytes.
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#;
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".
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.
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;
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
Queries for table column information, where the table does not have an editioning
view. This category includes:
Temporary tables.
Index-organized tables.
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:
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
/
ALL_EDITIONING_VIEW_COLS_AE, DBA_EDITIONING_VIEW_COLS_AE,
ALL_LOB_SUBPARTITIONS, DBA_LOB_SUBPARTITIONS,
USER_LOB_SUBPARTITIONS
ALL_PART_KEY_COLUMNS, DBA_PART_KEY_COLUMNS,
USER_PART_KEY_COLUMNS
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
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
Sequence
Definition Standards
No special considerations.
Usage Standards
No special considerations.
Definition Standards
The type owner must be the "non-editioned APPS" user: APPS_NE
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.
Temporary Table
Definition Standards
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
Usage Standards
No special considerations.
Definition Standards
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>.
Usage Standards
No special considerations.
Application Context
Definition Standards
No special considerations.
Usage Standards
No special considerations.
Definition Standards
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.
Usage Standards
No special considerations.
Database Link
Definition Standards
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.
Any other data files that are dynamically generated or consumed by the
runtime application
Usage Standards
Reference the non-editioned APPL_TOP using the 'APPL_TOP_NE' environment
variable.
For example, $APPL_TOP_NE/fnd/import
3. Add a new global incompatibility rule for your program with the following
program:
Application Name: Applications DBA
After:
(select profile_option_value from fnd_profile_option_values
where level_id = 10001 and (profile_option_id, application_id) =
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.
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
/
After:
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.
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.
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.
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.
After your modifications, perform suitable tests using the BC4J tester object.
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.
A F
adop fs_ne
online patching tool, 4-12 See non-editioned file system
online patching utility, 4-1
ADZDPAUT.sql, 5-5 G
ADZDPMAN.sql, 5-5
Global Standards Compliance Checker (GSCC),
ADZDPSUM.sql, 5-5
5-6
C L
cover layer
log files
in online patching of data, 4-7
disk space, 2-4
CPU
purging, 2-4
requirements, 2-1
logical view
crossedition trigger
of data model, 4-6
in online patching, 4-6
M
D
Memory requirement for Oracle E-Business
Database
Suite, 2-2
memory requirements, 2-2
dual file system
N
definition, 4-10
non-editioned file system
E used in online patching, 4-10
edition
O
in online patching, 4-6
Edition-Based Redefinition, 4-6 old edition
editioned data storage in online patching, 4-6
in online patching, 4-9 online patching, 4-1
editioning view Online patching, 4-1
definition, 4-6 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
in online patching, 4-6
patches
disk space, 2-4
patch file system, 4-10
phases
of online patching, 4-2
R
run edition
in online patching, 4-6
run file system, 4-10
S
seed data
in online patching, 4-9
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