ADOP and Customizations

How to Create Custom

Cross Edition Triggers
by Mike Swing

[email protected]
blog.trutek.com
Latest Book
Sponsored by
ePrentise

by Mike Swing

2
 Online Patching
• All EBS patches for Release
12.2 and beyond are Online
Patches
• Online Patching of code is
enabled by the Dual File
System and 11gR2 Database
Editioning features
Run Edition
• Online Patching of
transactional tables is
enabled by Editioning Views
and Cross-Edition Triggers
• The Patch Edition becomes Patch Edition
the Run Edition at Cutover

3
R12.2 Online Patching

https://blogs.oracle.com/stevenChan/entry/
glimpses_of_e_business_suite
4
 Best Practices with ADOP
• During the prepare phase, use the option sync_mode=delta
(rsync)
• Before a cutover manually stop the concurrent managers
• Use shared disk for the apps tier
• Don’t use the hotpatch option unless the patch is really a
hotpatch
• Use ad_zd.grant_privs to avoid invalid object swarms
• If after running finalize, while waiting to run cutover you
want to apply more patches, you can. After, run finalize,
cutover and cleanup.
• Don’t apply customizations during an ADOP session
• Don’t run AutoConfig during an ADOP session
 Editioned Database Objects
Editioned Database Objects may have a different
definition in each database edition.
Editioned database object types are:
View (Ordinary)
PL/SQL Package
PL/SQL Trigger
User-Defined Type (Editioned)
Synonym
Virtual Private Database Policy
 Non-Editioned Objects can’t refer to
an Editioned Object
Non-Editioned Objects include tables,
materialized views, database links, partitions,
etc.
Editioned objects should go in the APPS schema
and
Non-editioned objects should go in the APPS_NE
schema.
Custom non-editioned objects should go in the
XXCUST_NE schema
 Effectively-Editioned Database
Objects
Tables and Materialized Views

Tables - Since the application is still running during

an online patch (and the application data is
continuously changing), it is not possible to
upgrade application data using a one-time update
script.
Instead we will need to use a new technique
involving Editioning Views and Cross Edition
Triggers.
 Editions and Tables
• Tables cannot be versioned: there is only one definition
of a table across all Editions
• Data is not versioned: a record exists once and only
once
• The solution for managing changes to Tables:
Editioning Views and Cross Edition Triggers.
• Editioning Views are defined on base table (no joins)
Editioning Views can have DML triggers defined (just
like base table).
• Using an editioning view in a query or DML statement
does not impact the performance of the query or DML
9
 “Suggested (Best) Practices”
• Every application (release) sets the Edition it
requires when it connects to a session
• At the same time it calls dbms_application_info
• And sets other Context details
• Applications should never access tables – all
access should be through views
• Only through views can the data structure itself
be Editioned
• Even triggers should be on the Editioning View

10
 Deploying Custom Code
• Apply customizations as an online patch: The custom
code is patched into the patch edition when an online
patching cycle is open. This is the most recommended
approach but requires compliance to the full set
development standards.
• Apply customizations as a downtime patch: The
custom code is patched into the run edition, either
during an extended online patching cutover downtime,
or as a separate downtime patch.
• Hot Patching of Custom Code is Explicitly Discouraged.
 Materialized Views
• The 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.

12
 DB Links & Materialized Views
• DB Links & Materialized Views are currently
not editionable
• Objects of an editionable type are not
editionable when used by a non-editionable
object

13
 Data Dictionary Views
DBA_ALL_EDITIONS – editions in the database
DBA_ALL_OBJECTS – objects (inherited) in
current edition
DBA_ALL_OBJECTS_AE – actual objects across all
editions
 Invalid Objects by Edition
select count(*) from dba_objects where
status='INVALID'
and edition_name = SYS_CONTEXT('USERENV',
'CURRENT_EDITION_NAME');
To view objects in all editions, add _ae to the
data dictionary views:
select * from dba_objects_ae;

15
 DBA_OBJECTS, DBA_OBJECTS_AE,
AD_OBJECTS
DBA_OBJECTS shows object information for the current
edition, but the STATUS column in this view may show the
object as VALID even if the object actually needs to be
compiled before use.

This is a side effect of how the database handles objects in old

editions that have been inherited into the current edition. The
issue is tracked in database Bug 17777718.

DBA_OBJECTS_AE is similar to DBA_OBJECTS, but shows

object information across all editions. This has the drawback
of showing objects in old editions that are no longer accessible
to the application.
 DBA_OBJECTS, DBA_OBJECTS_AE,
AD_OBJECTS
AD_OBJECTS is the Oracle E-Business Suite workaround to the unreliable
STATUS column in DBA_OBJECTS.

AD_OBJECTS shows the correct status for each object visible in the
current edition.

It also shows whether the object is “actual” (a real object) in the current
edition, or a "stub" object (the object definition was inherited from a
previous edition).

You can query AD_OBJECTS to locate objects that need to be recompiled

before use:

SQL>select owner, object_name, object_type

from ad_objects
where status = 'INVALID'
order by 1,2,3
 Editioning
• As EBR is enabled per database user, the
potentially editionable objects in a particular
schema are all either editioned or not (internal
database users such as SYS, SYSTEM, and PUBLIC
cannot be editioned).
• As not all database objects are editioned, and
because the definition of one object may depend
on another object, for editioning to be enabled
successfully there must be no dependencies of
non-editioned objects on editioned objects
 Object Invalidation
• If your application changes will cause significant object
invalidation in the development database, you may wish to
call the "ad_zd.compile" procedure to recompile invalid
objects in the run edition.
• Developers often use the user_objects or all_objects data
dictionary view to confirm that there are no unexpected
invalid objects.
• Due to a database limitation these dictionary views only
return correct object status after running a full compilation
procedure (utl_recomp.recomp_parallel or ad_zd.compile).
• As a workaround, you can check object status using the
ad_objects view included with online patching.
select * from ad_objects where status='INVALID';
 Potential Violations
• PUBLIC synonyms to editioned objects
• Tables and queues that depend on editioned
user defined types (UDTs)
• Materialized views that depend on editioned
objects
• Custom and third-party schemas that depend
on editioned objects
• Non-APPS synonyms on EBS tables
 Violation Priority and Impact
P1 violations must be fixed before using the
system
P2 violations do not pose an immediate
problem, but may cause problems if the
indicated object is patched in a future online
patch.
P3 violations are minor issues that can be
deferred or ignored
 "Table must be owned by an EBS
product schema, not APPS“
SECTION-19
"Table must be owned by an EBS product schema, not
APPS“
P2: Tables owned by APPS cannot be patched using
Online Patching.
Fix violations by moving the table to a product schema
and then calling the table upgrade procedure:
SQL> ad_zd_table.upgrade(new_owner, table_name)
Note: 'REFS' indicates if table is referenced by other
objects. An unused table can be ignored or dropped.
Tables that are managed dynamically by application
runtime can be ignored.
 "Query/DML statements must access Tables via
the Table Synonym or Editioning View"
P2: These objects may operate incorrectly after the referenced
table has been patched.
Fix violations by changing the object to reference tables via the
APPS synonym.
Note: View objects that end with '#' are Materialized View Queries.
To fix MV violations before Online Patching Enablement, you must
fix the actual MV definition.
To fix MV violations after Online Patching Enablement, you must fix
the MV Query view and then run the MV upgrade.
SQL> exec ad_zd_mview.upgrade(mview_owner, mview_name)
Note: this check does not work prior to Online Patching Enablement
 PUBLIC synonyms to editioned
objects
• The PUBLIC schema is one of several internal
database schemas that cannot be editioned,
and so no PUBLIC objects are editioned.
• PUBLIC Synonyms that point to editioned
objects must be dropped, and any reference
to them must be replaced with equivalent
private synonyms in the referencing schemas.
 Public Synonyms
• Query PUBLIC synonyms that point at “to-be-
editioned” objects.
• For each PUBLIC synonym in Step 1, query the
oracle users that have code dependencies on that
PUBLIC synonym.
• For each affected oracle user in Step 2, create the
equivalent private synonym.
• After all private replacement synonyms have
been created, drop all PUBLIC synonyms from
step 1.
 Tables and queues that depend on
editioned user-defined types
• EBS includes approximately 20 table/queue
columns that are defined using UDTs owned
by APPS.
• You may have additional custom tables with
this situation.
• Editioning constraints prevent a table column
from depending on an editioned data type, so
these columns must be modified to depend
on an equivalent non-editioned type
 User Defined Types
• Copy the UDT type from the APPS user to the
non-editioned user APPS_NE.
• Stop any affected queues.
• Update the column type to use the non-editioned
type.
• Drop the old type from APPS and create an APPS
synonym to the non-editioned type.
• Recreate AQ internal derived objects.
• Restart any affected queues.
 Materialized views that depend on
editioned objects
• Materialized views depend on editioned
objects such as views and synonyms.
• As materialized views are non-editioned, they
must be converted to an alternative
implementation that is edition-legal.
Non-APPS synonyms to EBS tables
• While not strictly an editioning constraint
violation, it is no longer safe to reference EBS
tables directly.
• All EBS table references must go through the
APPS synonyms (which may in turn point to the
Editioning View for a table), instead of directly at
the EBS table.
• All non-APPS synonyms that point directly to EBS
tables must be updated to point to the equivalent
APPS table synonym instead.
 Enabling Editioning for Oracle E-Business
Suite Database Users except APPS_NE
• All database users in Oracle E-Business Suite are
recorded in the FND_ORACLE_USERID table. This
includes all users shipped with Oracle E-Business
Suite, as well as any registered custom database
users.
• All Oracle E-Business Suite users except APPS_NE
have the editioning feature enabled as follows:
SQL>alter user USERNAME enable editions force;
Enabling Editioning for Oracle E-Business
Suite Database Users except APPS_NE
• The APPS_NE user is deliberately not
editioned, so that it can contain the non-
editioned objects for Oracle E-Business Suite.
 The Custom Synchronization Driver
File (adop_sync.drv)
You need to ensure that any customizations you
may have are preserved when the run and
patch file systems are being synchronized.
Examples include:
• Compiling user-defined JSPs
• Copying some third-party libraries
• Executing user-defined SQL files
• Compiling user-defined forms
 Upgrade Table Definition
Create Edition
Set target Edition for session
Make desired changes to the table
Add columns, modify Columns, … (online redefinition)
Modify the Editioning View in the Edition
To reflect the table as its latest version should look
Perhaps hiding columns you eventually want to drop
(optional) Create Forward Cross-edition Trigger on base
table to have DML on previous Editions made valid
(optional) Create Reverse Cross-edition Trigger on base
table to have DML on current Edition synch back

33
 AD_ZD_TABLE.PATCH
• Whenever you directly alter the structure of a table,
you must call the AD_ZD_TABLE.PATCH procedure.
• The PATCH procedure looks at the physical table
columns and then generates the editioning view
which presents the logical columns for that table.
• The PATCH procedure is called automatically when
applying table structure changes using XDF or ODF.
exec ad_zd_table.patch('APPLSYS',
'XYZ_USER_SERVICE')
 Editionable Objects
The following object types are editionable:
• FUNCTION
• LIBRARY
• PACKAGE and PACKAGE BODY
• PROCEDURE
• TRIGGER
• TYPE and TYPE BODY
• SYNONYM
• VIEW
 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.
The following object types are covered:
Table (Ordinary)
Seed Data Table
Seed Data Loader
Index
Integrity Constraint
Materialized View
 Migrate to Editioning Views
1. Rename Table (for example to old table name_BASE)
2. Constraints continue to refer to the table
3. Create the Editioning View with the old table name
4. Using ‘CREATE OR REPLACE EDITIONING VIEW
5. Reroute privileges – grant on view rather than table
6. Recompile the triggers on the table
7. These now become triggers on the Editioning View
8. Recompile all invalid PL/SQL program units and Views
9. They now refer to the Editioning View instead of the table
10. VPD policies are reassigned to the View
11. Regular auditing and FGA is on the table

37
 AD_ZD_TABLE.UPGRADE
Upgrade the table for Online Patching using the
AD_ZD_TABLE.UPGRADE procedure.
This will generate an Editioning View (EV) for the
table and then create an APPS synonym that points
to the Editioning View.
exec ad_zd_table.upgrade('APPLSYS', 'XXX_CUST')
The table is now ready for use from the APPS
schema. The generated EV is named XXX_CUST#
and looks exactly like the table at this point.
 Forward Cross Edition Triggers
You might need to update an existing logical column
either to:
• Change the column definition (data type, data
length, not null constraint)
• Change the column data (how data is stored in
the column)
To update existing data without disturbing the
running application we must create a new
physical column (called a revised column) to hold
the updated data.
 Cross Edition Triggers
• If you remove a (mandatory) column from the
current Editioning View…
– a Reverse Cross-edition Trigger ensures that new
records get some value in that (invisible) column
• If you add a (mandatory) column to the table
(and the current Editioning View)…
– a Forward Cross-edition Trigger ensures that
records DMLed through previous Editioning View
versions are made valid

40
 ADZDDBCC.sql and gscc.pl
• 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 EBS 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.

41
 Online Patching standards
Be aware that any custom code may need updating in
preparation for an upgrade to R 12.2.n, so that it is
compliant with Online Patching standards.
Prior to upgrading to R12.2.n the following must be run early
in the planning cycle:
• Online Patching Readiness Report to identify issues in
custom database objects that will be fixed automatically Vs
needing manual intervention.
• Manual Fix Readiness Report.
• Global Standards Compliance Checker script. Address errors
that are reported by this script
• Online Patching Database Compliance Checker. Fix any
violations of development standards listed in this report.

42
 Check the Edition
• echo $FILE_EDITION

• select ad_zd.get_edition_type from dual;

• From SQL*Plus it is possible to change your

current edition.
SQL> exec ad_zd.set_edition('PATCH')

43
 Check the Edition
• echo $RUN_BASE
• echo $PATCH_BASE
• echo $NE_BASE
 Online Patching

See EBS Directions: Slashing Downtimes with

Online Patching – Kevin Hudson

45
 Example of ADOP Patching Cycle
$ . <EBS_ROOT>/EBSapps.env run
$ adop phase=prepare
$ adop phase=apply patches=123456
$ adop phase=finalize
$ adop phase=cutover
$ . <EBS_ROOT>/EBSapps.env run
$ adop phase=cleanup

46
 Customize the Patch Edition
Before running finalize_mode

# Apply any customizations to patch edition

(optional):
$ . <EBS_ROOT>/EBSapps.env patch
$ sqlplus apps/apps @my_custom_script_01
$ sqlplus apps/apps @my_custom_script_02

47
 Hot Patching Customizations
“An approach that explicitly discouraged is hot
patching of customizations. Applying custom
changes to the run edition of the system while the
system is online carries the risk of causing large
chain reaction invalidation of objects in the
dependency tree of whatever is getting patched.
This can cause runtime failure in user sessions, and
the code may temporarily be in an inconsistent
state which can lead to data corruption, runtime
exceptions, or other unexpected behavior while
the patch is being applied.”
 Forward Cross Edition Triggers
You might need to update an existing logical column
either to:
• Change the column definition (data type, data
length, not null constraint)
• Change the column data (how data is stored in
the column)
To update existing data without disturbing the
running application we must create a new
physical column (called a revised column) to hold
the updated data.
 Data is updated in the Patch Edition
during Patching

Planning and Preparing for Your

Upgrade to EBS 12.2 – Anne Carlson
OOW12

During patching, data updates are propagated from the Run

Edition to the Patch Edition using Cross-Edition Triggers
50
Cross-Edition Triggers Update Data in
the Patch Edition

Planning and Preparing for

Your Upgrade to EBS 12.2 –
Anne Carlson OOW12

51
 Reverse Cross Edition Triggers
• The reverse cross-edition trigger only fires
when the table contents is changed from the
patch edition (such as during seed data
loading).
 Example of installing a new PL/SQL
package via a Manual Patch
$ source /u01/R122_EBS/EBSapps.env patch

$ cd $PATCH_TOP/manual_patch
$ copy_files.sh
cp fnd/patch/115/sql/* $FND_TOP/patch/115/sql

$ manual_db_steps.sh
sqlplus apps/apps
@$FND_TOP/patch/115/sql/XXX_CUST_S.pls
sqlplus apps/apps
@$FND_TOP/patch/115/sql/XXX_CUST_B.pls
 Confirm Manual Patch Changes
$ source /u01/R122_EBS/EBSapps.env patch
$ sqlplus apps/apps
SQL> show errors package XXX_CUST
SQL> show errors package body XXX_CUST
SQL> quit
 Run Manual Patch Phases
• Finalize
$ adop phase=finalize
• Cutover
$ adop phase=cutover
$ source /u01/R122_EBS/EBSapps.env run
• Cleanup
$ adop phase=cleanup

$ adop phase=cleanup cleanup_mode=quick

Use quick cleanup when you need to start another patch cycle

Use full cleanup to remove obsolete table columns. Full cleanup is

required after aborting an online patching cycle.
$ adop phase=cleanup cleanup_mode=full (post 12.2.2)
 Customizations and ADOP
To ensure that your customizations will be
compliant with the Online Patching
technology, you must follow standards
described in My Oracle Support Knowledge
Document 1577661.1, "Developing and
Deploying Customizations in Oracle E-Business
Suite Release 12.2."
 MOS Note: 1577661.1
Section 1.5.1: Setting Up a Production Environment
First, you must set up your custom application on your production
environment.
On the production environment, run the adop prepare phase.
If your customizations include custom Java or BC4J code or extensions, apply
the following patches to the production environment.
17217965:R12.TXK.C (TEMPLATE CHANGE REQUIRED TO UPLOAD THE CLASS FILES
RELATED TO CUSTOMIZATIONS)
17217772:R12.AD.C (NEED UTILITY TO GENERATE CUSTOMALL.JAR)
Connect to the patch edition file system on the production environment. See
Section 1.1.2: Connecting to the Patch Edition.
Invoke adsplice from the patch file system to register your custom application.
For more information about using adsplice, see Section 1.3.1: Setting Up an
Environment for Customizations.
Run the adop cutover phase.
 Register a Custom Schema
• MOS Note 15770771.1
Custom and third party schemas that
depend on editioned objects
• Custom schemas that depend on editioned
EBS objects must be registered with EBS, and
will be themselves editioned. Custom schema
registration is performed as follows:
fnd_oracle_user_pkg.load_row(
'SCHEMA_NAME', 'CUSTOM', 'INVALID', NULL,
'N', 'B');
Custom and third party schemas that
depend on editioned objects
• Registered custom schemas will be included in
database preparation processing to
automatically fix other types of editioning
constraint violations.
• Custom objects will also need to comply with
online patching development standards,
which may require manual correction by the
custom developer.
 MOS Note 1577707.1
Section 1: Create A Custom Application Using adsplice
Download Patch 3636980 "Support Diagnostics (IZU) patch for AD Splice"
from My Oracle Support.

Manually copy the three .txt files from the 3636980\izu\admin directory to
your own temporary directory.

Rename izuprod.txt to <CUSTOM MODULE>prod.txt. In this example, we will

be using "xxmzprod.txt".

Rename izterr.txt to <CUSTOM MODULE>terr.txt. In this example, we will be

using "xxmzterr.txt".

Open newprods.txt in a text editor.

Change all references of "izu" to <custom module> and all references of "IZU" to
<CUSTOM MODULE> (i.e. keep the case sensitivity).
 Register your Custom Application
Use the AD Splicer utility (adsplice) to register your
custom application as a product within EBS
You can use Patch 3636980, "Support Diagnostics
(IZU) patch for AD Splice", to help you create your
custom application.
adsplice performs the following steps:
Makes the new user edition-enabled.
Enables Edition-Based Redefinition (EBR) for the custom
objects.
 Run ADSPLICE
Open xxmzterr.txt in a text editor.
Change all references of "izu" to <custom module> and all references of "IZU" to <CUSTOM
MODULE> (keeping the case sensitivity).
Note: In this example, we will be changing references of "izu" to be "xxmz" and "IZU" to be
"XXMZ".

Change the text "Oracle_Support_Diagnostic_Tools" to be "xxmz_custom_app".

Copy the following text files to the $APPL_TOP/admin directory:

xxmzprod.txt
xxmzterr.txt
newprods.txt

Change directory to the admin directory under $APPL_TOP

Run AD Splice
 Run ADSPLICE

AD Splice must be run from the admin directory under APPL_TOP, and is invoked
by running the command:

$ adsplice

When prompted for the following, you can press Enter to accept the default
location:
Enter the directory where your AD Splicer control file is located.
The default directory is [/oracle/VIS/apps/apps_st/appl/admin] :

When prompted for the following, you can press Enter to accept the default
filename:
Please enter the name of your AD Splicer control file [newprods.txt] :

When prompted for the following, you can press Enter to accept the default value
and regenerate the environment file:
Do you wish to regenerate your environment file [Yes] ?

AutoConfig will be run automatically as part of this procedure.

Review the AD Splice log file to ensure the procedure completed successfully.
Review the AutoConfig log file to ensure the procedure completed successfully.
 Verify Creation of Custom
Product in the Database
1.Log in to SQL*Plus as APPS, and run the following SQL to confirm that the
fnd_application table has one row:
SQL>select * from fnd_application where application_short_name = 'XXMZ';
This statement should return one row only.

2. Run the following SQL to check the product installations table has one
row for your custom product:
SQL>select * from fnd_product_installations where APPLICATION_ID =
50201;
This statement should return one row only.

3.Run the following SQL to check the database user:

SQL>select * from dba_users where username = 'XXMZ';
This statement should return one row only.
 Verify Creation of Custom
Product in the Database
3.Run the following SQL to check the database user:
SQL>select * from dba_users where username = 'XXMZ';
This statement should return one row only.
4.To ensure the new environment file is picked up, log out and back in
again as applmgr, then run the following command to confirm the
$XXMZ_TOP variable is correctly set:
$ env | grep XXMZ
5.Run the following command to check the file system has been created
correctly. You should see a directory listing returned as shown:
$ ls $XXMZ_TOP
admin log mesg out sql
Note: If you have registered any schemas using the
fnd_oracle_user_pkg.load_row API, their passwords will not be
encrypted. As a result, adpatch and adsplice will fail. To correct this, you
need to run the FNDCPASS utility to set the password for the schemas.
 Deploy Customizations
Run the adop prepare phase on the PATCH edition and
filesystem.
Connect to the patch edition file system on the production
environment.
Copy the custom files to the appropriate directory on the
patch edition file system.
If you copied any custom files under the $JAVA_TOP directory,
run the adcgnjar utility to generate and sign a JAR file
containing these files.
If necessary, use the appropriate utility for your product or
component to import or upload the custom files to the
database.
Run the adop cutover phase.
 Drop Object in Edition
• Drop Object in an Edition stops the inheritance
from previous Edition.
• An Object no longer is carried forward
An Edition can have only one child – no branches
(yet)
DBMS_SQL.PARSE can be executed in a specific
Edition
• If no explicit edition is set for a session, the
default edition is used
ALTER DATABASE DEFAULT EDITION =
edition_name;

68
 Deploying Custom Files
• Connect to the run edition file system on your development
environment.
• Copy the custom files to the appropriate directory on the run
edition file system.
• If you copied any custom files under the $JAVA_TOP directory, run
the adcgnjar utility to generate and sign a JAR file containing these
files. When prompted, enter the user name and password of the
APPS user.
• If necessary, use the appropriate utility for your product or
component to upload the custom files to the database.
• Add entries for the custom files to the custom synchronization
driver file to ensure that the adop utility synchronizes these files
between the run file system and the patch file system the next time
you run the prepare phase.
 Deploying Custom Files
• Connect to the run edition file system on your development
environment.
• Copy the custom files to the appropriate directory on the run
edition file system.
• If you copied any custom files under the $JAVA_TOP directory, run
the adcgnjar utility to generate and sign a JAR file containing these
files. When prompted, enter the user name and password of the
APPS user.
• If necessary, use the appropriate utility for your product or
component to upload the custom files to the database.
• Add entries for the custom files to the custom synchronization
driver file to ensure that the adop utility synchronizes these files
between the run file system and the patch file system the next time
you run the prepare phase.
 Deploying Custom Files
• Connect to the run edition file system on your development
environment.
• Copy the custom files to the appropriate directory on the run
edition file system.
• If you copied any custom files under the $JAVA_TOP directory, run
the adcgnjar utility to generate and sign a JAR file containing these
files. When prompted, enter the user name and password of the
APPS user.
• If necessary, use the appropriate utility for your product or
component to upload the custom files to the database.
• Add entries for the custom files to the custom synchronization
driver file to ensure that the adop utility synchronizes these files
between the run file system and the patch file system the next time
you run the prepare phase.
 Step 1: Create or Replace Editioned
Database Objects
• Step 1: Create or Replace Editioned Database Objects in
your development database
• If your application changes will cause significant object
invalidation in the development database, you may wish to
call the "ad_zd.compile" procedure to recompile invalid
objects in the run edition.
• Due to a database limitation the user_objects or all_objects
dictionary views only return correct object status after
running a full compilation procedure
(utl_recomp.recomp_parallel or ad_zd.compile).
• As a workaround, you can check object status using the
ad_objects view included with online patching.
select * from ad_objects where status='INVALID';
 Step 2: Create the patch
$ cd $PATCH_TOP/manual_patch
$ vi copy_files.sh
Insert the following:
cp fnd/patch/115/sql/* $FND_TOP/patch/115/sql

$ vi manual_db_steps.sh
Insert the following:
sqlplus apps/apps
@$FND_TOP/patch/115/sql/XXX_CUST_S.pls
sqlplus apps/apps
@$FND_TOP/patch/115/sql/XXX_CUST_B.pls
 Hot Patching of Customizations
• An approach that explicitly discouraged is hot patching
of customizations. Applying custom changes to the run
edition of the system while the system is online carries
the risk of causing large chain-reaction invalidation of
objects in the dependency tree of whatever is getting
patched.
• This can cause runtime failure in user sessions, and the
code may temporarily be in an inconsistent state which
can lead to data corruption, runtime exceptions, or
other unexpected behavior while the patch is being
applied.
 Full vs Runtime Compliance
• Full compliance with all standards in this section
enable a product to support both correct runtime
operation and online patching in an Oracle E-
Business Suite Release 12.2 environment.
• Runtime compliance is a subset of the full
standards that allows a product operate correctly
in the Oracle E-Business Suite Release 12.2
runtime, but without supporting online patching
of the product itself.
 Full vs Runtime Compliance
• A product that only implements runtime
compliance must be patched using downtime
patching. Oracle E-Business Suite products are
required to implement full compliance, but
custom or third-party products have the
option to only implement the runtime
compliance subset. Runtime compliance
standards are marked with a [minimal] tag.
 Full vs Runtime Compliance
• Note: These standards only apply to objects
and data that are directly managed by
application developers.
• The database may generate internal/hidden
tables, indexes, types, and other objects to
implement certain higher level features.
• These development standards do not apply to
these generated objects.
DBCC Violations

Minimal Compliance
 Minimal Compliance
These checks represent the minimum
requirement for correct operation of E-
Business Suite Release 12.2.
Do not attempt to operate the system if there
are P1 minimal compliance violations.

Custom code should pass the minimal

compliance checks before being used in a
Release 12.2 system.
 Violation Priority and Impact
P1 violations must be fixed before using the
system
P2 violations do not pose an immediate
problem, but may cause problems if the
indicated object is patched in a future online
patch.
P3 violations are minor issues that can be
deferred or ignored
 SECTION-2 [minimal]
Database data dictionary corruption

- P1: If these checks return any rows, please follow the

instructions in "Fix data dictionary corruption" section
of My Oracle Support Knowledge Document
1531121.1.

Note: Upgrade or Online Patching must not be

attempted until all errors in this section are resolved.

no rows selected
 SECTION-4 [minimal]
"EBS_LOGON Trigger must be enabled."

- P1: The SYSTEM.EBS_LOGON trigger must exist and must be

enabled. If not, Online Patching tools will connect to the
wrong edition in the database, causing system corruption.

- Fix: Install the SYSTEM.EBS_LOGON trigger by running:

sqlplus apps/apps $AD_TOP/patch/115/sql/ADZDLTRG
<system_password>

no rows selected
 SECTION-5 [minimal]
"The database initialization parameter
_system_trig_enabled must be set to TRUE."

- P1: This violation will prevent Online Patching

tools from operating correctly, resulting in system
corruption.
- Fix: Set _system_trig_enabled parameter to
TRUE

no rows selected
 SECTION-6 [minimal]
"'ADMINISTER DATABASE TRIGGER' privilege must
not be granted to APPS."

- P1: This violation will prevent Online Patching

tools from operating correctly, resulting in system
corruption.
- Fix: Revoke the privilege from APPS.

no rows selected
 SECTION-7 [minimal]
"'EXEMPT ACCESS POLICY' privilege must not be
granted to APPS."

- P1: This violation will cause applications to

bypass VPD policies, resulting in system
corruption.
- Fix: Revoke the privilege from APPS.

no rows selected
 SECTION-8 [minimal]
"Object must be VALID."

- P1: Invalid objects are non-functional.

- Invalid Oracle-owned objects that affect application functionality
must be corrected. Contact Oracle Support to obtain a correction.
- Invalid Oracle-owned objects that do not affect application
functionality can be ignored.
- Invalid custom or junk objects should be fixed or dropped.

Note: Although unused invalid objects can be ignored, they should

eventually be fixed or dropped, as large numbers of invalid objects
will increase the time required for system compilation.
 SECTION-9 [minimal]
"Database Recyclebin should be off."

- P3: Objects in the recyclebin can prevent full

cleanup of old database editions.
- Fix: Set the 'recyclebin' database parameter
to 'off‘

no rows selected
 SECTION-13 [minimal]
"Table Trigger must be on the editioning view, not the table, if the editioning
view exists."
- P2: These triggers may operate incorrectly once the table is patched with
revised columns.
- If the trigger is needed, move it to the editioning view by calling the table
upgrade procedure.
SQL> exec ad_zd_table.upgrade(table_owner, table_name)

- If the trigger is not needed, then drop it:

SQL> drop trigger trigger_owner.trigger_name;

Note: If the trigger table is a custom table that will not be patched using
online patching, then this violation can be ignored.

no rows selected
 SECTION-14 [minimal]
"Table Synonym must point to the editioning view, not the table, if
the editioning view exists."

- P2: Code that references these synonyms may operate incorrectly

once the table is patched with revised columns.

- Fix: Execute the table upgrade procedure.

SQL> exec ad_zd_table.upgrade(table_owner, table_name)

- Unused synonyms can be ignored or dropped.

no rows selected
 SECTION-15 [minimal]
"Synonym must point to an object."

- P3: broken synonyms cause clutter and

confusion.
- Fix: Correct or drop these synonyms.
 SECTION-16 [minimal]
"VPD Policy must be on the editioning view or table synonym, not the table, if the
editioning view exists."

- P2: These VPD policies may operate incorrectly once the table is patched with
revised columns.

- Fix: Execute the table upgrade procedure on the affected table.

SQL> exec ad_zd_table.upgrade(table_owner, table_name)

- VPD Policies on unused tables can be ignored.

Note: If the VPD table is a custom table that will not be patched using online patching,
then this violation can be ignored.

no rows selected
 SECTION-25 [minimal]
"Column Type should not be ROWID."

- P2: Stored ROWID references may be broken when tables

are patched.

- Fix: Re-design table to reference the target table primary key.

- Unused columns or columns that only store the ROWID
temporarily can be ignored.
Note: this check does not work prior to Online Patching
Enablement.

no rows selected
 SECTION-26 [minimal]
"Query/DML statements must access tables via
the APPS table synonym."
- P2: These objects may operate incorrectly after
the referenced table has been patched.
- Fix: Change the object to reference tables via
the APPS table synonym.
 SECTION-34 [minimal]
"Index Must be usable."

- P1: Unusable indexes block DML access to the

table
- Fix: Rebuild the index.
SQL> alter index owner.index_name rebuild;
- Indexes on unused tables can be ignored
- Note: Unusable indexes where
ITYP_OWNER='CTXSYS' will not block DML and
are not P1 issues.
 SECTION-39 [minimal]
"Foreign Key constraint cannot reference seed data table."

- P2: These constraints become invalid when the seed

data table is upgraded for editioning.
- Fix: Drop the constraint and ensure that runtime application
logic validates data integrity rules as needed.

Note: This check only works after Online Patching

Enablement.

no rows selected
 SECTION-40 [minimal]
"Materialized View name must be unique within
the first 29 bytes."

- P1: Matching materialized views will not upgrade

correctly and will be non-functional.
- Fix: Rename materialized views so that names
are unique within the first 29 bytes.

no rows selected
 SECTION-41 [minimal]
*
"Materialized View (MV) must have a corresponding Logical View (MV#)."

- P1: These MVs did not upgrade correctly and are non-functional. This can happen if
the MV query is not a legal ordinary view query.
- Fix: Recreate the MV using the AD_MV.CREATE_MV procedure.
- Unneeded MVs can be ignored but should be dropped.
Note: This check is only active after Online Patching Enablement.
#

OWNER MVIEW_NAME
---------------- ------------------------------
APPS XXSCP_MTL_PARAMETERS_TEST
APPS XXSCP_TEST_MV
APPS XXSCP_TEST_MV1
 SECTION-42 [minimal]
*
"Logical View (MV#) must have a corresponding Materialized View (MV)."

- P1: These MVs did not upgrade correctly and are non-functional. This is
likely because the MV query references an editioned PL/SQL function.
- Fix: create the MV according to development standards using the
AD_MV.CREATE_MV procedure.
- Unneeded MVs can be ignored but should be dropped.
#

OWNER VIEW_NAME
---------------- -----------------------------------------------

APPS XXSCP_SS_PLNR_BUYER_MV#
 SECTION-43 [minimal]
"Object name must not match any E-Business
Suite schema name."

- P1: These object names conflict with schema

names and may cause errors during upgrade
or online patching.
- Fix: Drop or rename the object.
 SECTION-44 [minimal]
*
"Object name must not conflict with data
dictionary view names."

- P1: These objects may return wrong data,

causing incorrect operation.
- Fix: Drop or rename the object.
#
 SSECTION-45 [minimal]
"E-Business Suite DB Technology Codelevel Checker must be
run on all database nodes."

- P1: Online Patching will not allow execution until the until
the this manual step is completed. See My Oracle Support
Knowledge Document 1594274.1 for further information.

NODE_NAME PATCH_CHECKER_MESSAGE
------------------------------ ---------------------------------
ascp-uat-vm-db01 All required database bug fixes
have been applied to this node
 SECTION-46 [minimal]
"If Online Patching has been enabled, the
EBS_PATCH service must be running."

- P1: If the patch service is not running then

connections to patch edition might fail.
- Fix: Create and start the service by running
SQL> exec ad_zd_prep.create_patch_service;
#
no rows selected
 SECTION-47 [minimal]
"Latest version of the package APPS_DDL must be installed in each
EBS schema."

- P2: If the latest package version is not installed then dynamic SQL
executed in the schema might fail.
- Fix: Create the APPS_DDL spec and body in the listed schemas by
running the installation scripts.

sqlplus <username>/<password> @
$AD_TOP/patch/115/sql/adaddls.pls

sqlplus <username>/<password> @
$AD_TOP/patch/115/sql/adaddlb.pls
no rows selected
DBCC Full Compliance
 Full Compliance [full]
These checks indicate whether an object can be
patched using Online Patching.
Objects which do not meet full compliance may
have limitations in how they can be patched, or
may need to be patched using downtime
patching.
Full compliance also requires that all minimal
compliance checks are passed.
Custom code that will only be patched using
downtime patching does not need to meet the
full compliance level.
 SECTION-10 [full]
"APPS object names must end with alphanumeric character."

- P2: May cause object name conflicts during online patching.

Use of special characters as the last character of an
object name is reserved for the Online Patching tool.
- Fix: Change the object name to use an ordinary identifier character
as the last character: A-Z a-z 0-9 _ # $
- Unused objects can be ignored or dropped.
#

no rows selected
 SECTION-12 [full]
"Editioning view must have table."

- P3: Extraneous object.

- Fix: Drop the view.
SQL> drop view owner.view_name;

Note: When dropping a table with an editioning view,

you must also explicitly drop the editioning view to
avoid this issue.

no rows selected
 SECTION-17 [full]
"Table name must not end with '#' character."

- P2: The '#' character in table and view names is reserved for
use by the Online Patching tools. Online patching may not
operate correctly on tables that violate this standard.

- Fix: Rename the table and correct any code references to the
new table name.
#

no rows selected
 SECTION-18 [full]
"Table name must be unique within the first 29 bytes."

- P3: Duplicate table names may cause confusion as to

which is the "real" table. Tables that only differ in the
30th characters may have a conflict in their editioning
view names.

- Fix: Rename table or drop unwanted table.

no rows selected
 SECTION-19 [full]
"Table must be owned by an EBS product schema, not APPS.“

- P2: Tables owned by APPS cannot be patched using online patching.

- Fix: Move table to a product schema and then call the table upgrade
procedure.
SQL> ad_zd_table.upgrade(new_owner, table_name)

- Note: An unused table can be ignored or dropped. Tables that are managed
dynamically by application runtime can be ignored.

TABLE_NAME
------------------------------
ABC1
ABC_DEF
ABC_TEST
 SECTION-20 [full]
“Table must have an editioning view."

- P2: These tables may not be patched using online patching.

- Fix: Execute the table upgrade procedure.

SQL> exec ad_zd_table.upgrade(table_owner, new_table_name)

Note: Tables that are dynamically created by application runtime can be ignored.
Note: Tables that end with "_A" are typically audit tables by the Audit Trail feature, and can be ignored.
Note: This check is only active after Online Patching Enablement.

OWNER TABLE_NAME
---------------- ------------------------------
XXSCP ITEM_PC_BACKUP_2906
XXSCP MSC_SOURCING_RULES_BKUP
 SECTION-21 [full]
"Base column name can only use '#' as the last character."

- P2: These columns will not show correctly in the editioning view.
- Fix: Rename the column

SQL> alter table table_owner.table_name

rename column column_name to new_column_name;

- Unused tables and columns can be ignored.

Note: This check only works prior to Online Patching Enablement.

no rows selected
 SECTION-22 [full]
SECTION-22 [full]
"Base column name must be unique within 28 bytes."

- P3: these columns cannot be revised using the same logical name during online patching.
- Fix violations by renaming the column to a shorter base name.

SQL> alter table table_owner.table_name

rename column column_name to new_column_name;

SQL> ad_zd_table.patch(table_owner, table_name)

- Fixes can be deferred until there is a reason to patch the column. Unused columns can be ignored.
Note: This check only works after Online Patching Enablement.

OWNER TABLE_NAME COLUMN_NAME_TO_28_CHARS MATCHES

---------------- ------------------------------ ---------------------------- ----------
AP AP_INVOICE_LINES_ALL AIL_DISTRIBUTION_LINE_NUMBER 2
BEN BEN_ELIGY_CRITERIA TIME_ENTRY_ACCESS_TABLE_NAME 2
 SECTION-24 [full]
"Column Type must not be LONG or LONG RAW."

- P2: These columns cannot be patched using Online Patching.

- Fix: Alter the column datatype to CLOB or BLOB.

SQL> alter table owner.table_name modify column_name CLOB;

- Note: The LONG-to-CLOB datatype change should be implemented before Online Patching
Enablement.
- Note: If you alter the column type via 'ALTER TABLE' DDL (instead of using using XDF/ODF) you will
need to rebuild indexes on the affected table manually.

SQL> alter index owner.index_name rebuild;

- Note: Changing a LONG to CLOB will cause any trigger that references the CLOB column in the "UPDATE
OF" clause of a trigger to go invalid. Fix this by referencing the table in the "ON" clause of the
trigger
- Unused LONG columns can be ignored, but should be dropped.
#
Internal Checks
 Internal Checks
This report also implements a number of internal
checks which verify that the upgrade and Online
Patching Enablement process executed correctly.
Violations of internal checks indicate upgrade
failure and should be reviewed with support if the
cause is not understood.
For further information about development
standards, review the Online Patching Development
Standards chapter of the Oracle E-Business Suite
R12.2 Developer Guide R12.2, and My Oracle
Support document 1577661.1.
 Internal Checks
SECTION-11 [internal]
*
"APPS_NE Object must not also exist in APPS."

- Check for related errors in the Online

Patching Error Log.

# no rows selected
 Internal Checks

SECTION-23 [internal]
*
"Column Type must be a built-in type or non-editioned User Defined Type."

- Check for related errors in the Online Patching Enablement error log.
#

OWNER TABLE_NAME COLUMN_NAME DATA_TYPE_OWNER DATA_TYPE

---------------- ------------------------------ ------------------------------ ---------------- ------------------------------
APPS IMP_SQL_BASELINE BIND_VALUE PUBLIC ANYDATA

1 row selected.
 Internal Checks
SECTION-27 [internal]
*
"AQ table must NOT have an editioning view."
#

no rows selected
 Internal Checks
SECTION-28 [internal]
*
"Seed data table must have standard ZD_EDITION_NAME column."

- P2: failed upgrade of seed data table, do not use until corrected.
- ZD_EDITION_NAME column must be VARCHAR2(30) NOT NULL
- Check ad_zd_logs for related messages
#

no rows selected
 Internal Checks
SECTION-29 [internal]
*
"Seed data table must have a maintenance trigger."

- P1: failed upgrade of seed data table, do not use until

corrected.
- Check ad_zd_logs for related messages.
#

no rows selected
 Internal Checks
SECTION-30 [internal]
*
"Seed data table must have a VPD policy on the EV."

- P1: failed upgrade of seed data table, do not use until

corrected.
- Check ad_zd_logs for related messages
#

no rows selected
 Internal Checks
SECTION-31 [internal]
*
"Seed data table must have a VPD policy function."

- P1: failed upgrade of seed data table, do not use

until corrected.
- Check ad_zd_logs for related messages.
#

no rows selected
 MOS Note 1577661.1
Developing and Deploying Customizations in Oracle
E-Business Suite Release 12.2

• Upgrade the table for Online Patching using the

AD_ZD_TABLE.UPGRADE procedure.
• This will generate an Editioning View (EV) for the
table and then create an APPS synonym that
points to the Editioning View.
• exec ad_zd_table.upgrade('APPLSYS',
'XYZ_USER_SERVICE')
 ADZD Scripts are in $AD_TOP/sql
All ADZD* scripts are found under $AD_TOP/sql.
For convenience, you can add this directory to
the SQLPATH environment variable so that you
can refer to the scripts by simple name.

$ SQLPATH=$AD_TOP/sql; export SQLPATH

 AD_ZD
1) After creating the table in custom schema execute the following
script to generate the editoning view and synonym in APPS schema.
exec AD_ZD_TABLE.UPGRADE('XXCUST','XX_CUST_TBL1');
2)To regenerate the editioning view to sync any table changes:
exec AD_ZD_TABLE.PATCH('XXCUST','XX_CUST_TBL1')
3) Use AD_ZD.GRANT_PRIVS to avoid invalid objects.
exec AD_ZD.GRANT_PRIVS('SELECT','XX_CUST_TBL1','XX_ROLE0')
 AD_ZD
4) To update seed data tables in Patch edition,
execute prepare command.

example:
exec ad_zd_seed.prepare('WF_MESSAGES');

The prepare will create a edition based storage for

the run edition data for which the updates will be
made. During cutover, the run time data will be
synced using forward/reverse cross edition triggers.
 Create a New Table
• create table APPLSYS.XXX_CUST
(
ID NUMBER(15) not null,
TYPE VARCHAR2(8) not null,
DESC VARCHAR2(1000)
)
tablespace APPS_TS_TX_DATA
/
create unique index APPLSYS.XXX_CUST_U1
on APPLSYS.XXX_CUST ( ID )
tablespace APPS_TS_TX_IDX
/
 AD_ZD_TABLE.UPGRADE
Upgrade the table for Online Patching using the
AD_ZD_TABLE.UPGRADE procedure.
This will generate an Editioning View (EV) for the
table and then create an APPS synonym that points
to the Editioning View.
exec ad_zd_table.upgrade('APPLSYS', 'XXX_CUST')
The table is now ready for use from the APPS
schema. The generated EV is named XXX_CUST#
and looks exactly like the table at this point.
 AD_ZD_TABLE.UPGRADE
• The table is now ready for use from the APPS
schema. The generated EV is named
XYZ_USER_SERVICE# and looks exactly like the
table at this point. When the table structure is
patched in the future, the EV will serve to map
logical column names (used by the application
code) to the table columns that store the data
in each edition.
 ADZDSHOWEV.sql
You can see a display of the EV column mapping
with the ADZDSHOWEV.sql script:

$AD_TOP/sql/ADZDSHOWEV.sql XXX_CUST
-- EV Column Mapping
VIEW_COLUMN -> TABLE_COLUMN
--------------------------- ---- -------------------
ID = ID
TYPE = SERVICE_TYPE
DESC = DESC
 AD_ZD.GRANT_PRIVS
This procedure allows a developer to grant
privileges on Oracle E-Business Suite objects
without causing object invalidation.
There are occasions where you might want to grant
privileges to objects in the APPS schema; for
example, you might want to create a database user
with read-only privileges.
However, due to the way that editioned objects are
treated, granting a privilege on an editioned object
directly may cause temporary invalidation of any
dependent objects.
 AD_ZD.GRANT_PRIVS
To avoid such invalidation, use the procedure
AD_ZD.GRANT_PRIVS:
procedure GRANT_PRIVS( X_PERMISSIONS in
VARCHAR2,
X_OBJECT_NAME in VARCHAR2,
X_GRANTEE in VARCHAR2,
X_OPTIONS in VARCHAR2 default
NULL);
end;
 Synonyms
• Most APPS synonyms are automatically created
by the adop patching tool. Do not create, modify,
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.
(dbcc: SECTION-14) [minimal]
• A synonym must point to an object. (dbcc:
SECTION-15)[minimal]
• Do not create public synonyms.
 Materialized View
An effectively-editioned Materialized View includes both a
Logical View (managed by the developer) and a Materialized
View (generated by Online Patching).
The Logical View is an ordinary database view, and is therefore
an editioned object that can be changed in the Patch Edition
without affecting the Run Edition.
But the generated Materialized View is a non-editioned
object, meaning the definition and content of the materialized
view is shared across all editions.
In order to avoid breaking the running application during an
online patch, the system must defer materialized view
regeneration until the cutover phase, when the application is
down.
 Materialized View
During online patching, materialized view
regeneration happens automatically during the
cutover phase whenever the materialized view
implementation is out-of-date with respect to the
Logical View.
A materialized view implementation becomes out-
of-date if the Logical View is patched anything
which the Logical View depends on is patched or
recompiled any seed data table the materialized
view depends on is prepared for loading new
content in the patch edition
 Materialized View
Materialized view cutover processing will take care
to avoid regenerating materialized views unless
there is an actual change required in the MV
implementation.
When regenerating the MV implementation, the
system will try to preserve the existing MV
container table (with its data), but if the shape of
the container table must change, then the
container table is dropped and recreated
automatically.
 AD_ZD_MVIEW.UPGRADE
• To change the definition of a materialized view, you
first replace the definition of the corresponding logical
view in your development database.
• This is done using SQL DDL as usual.
• In this example, we create a new view that our MV
definition will reference, and then update the
XYZ_SCHEMAS_MV# Logical View to use the new view.
• When you are satisfied with the results of the updated
Logical View, remember to call the
AD_ZD_MVIEW.UPGRADE procedure to regenerate
materialized view implementation.
 Generate the Materialized View
On an editioned database, materialized views are
generated from their corresponding logical views using
the AD_ZD_MVIEW.UPGRADE procedure.
exec ad_zd_mview.upgrade('APPS', 'XYZ_SCHEMAS_MV')
In this example, the UPGRADE procedure detects that
materialized view is missing and generates it from the
Logical View.
The Materialized View definition is generated by
transforming the Logical View query into an equivalent
implementation query that directly references the
underlying tables and columns.
 Generate the Materialized View
You can see the resulting MV implementation objects using the
"ADZDSHOWMV" utility script:

sqlplus <apps_user> @ADZDSHOWMV XYZ_SCHEMAS_MV

-- MV Objects
OBJECT_NAME OBJECT_TYPE STATUS DESCRIPTION
------------------------------ ------------------- ---------- -------------------
XYZ_SCHEMAS_MV MATERIALIZED VIEW VALID Materialized
View
XYZ_SCHEMAS_MV TABLE VALID Container
Table
XYZ_SCHEMAS_MV# VIEW VALID Logical View
 Materialized Views
The MV implementation query should never be
changed directly.
It must always be generated from the logical view
using the UPGRADE procedure.
The MV implementation query can be difficult to
read and normally the developer will not need to
look at it.
But it is worth examining the implementation query
of our example to understand what the
transformation is doing.
 Materialized View Creation
The formatted MV implementation query for our example logical view is as
follows:
CREATE MATERIALIZED VIEW "APPS"."XYZ_SCHEMAS_MV"
("USERNAME", "USERTYPE") AS
SELECT
UPPER("A1"."ORACLE_USERNAME") "USERNAME",
DECODE("A1"."READ_ONLY_FLAG",
'C','pub','E','applsys','U','apps') "USERTYPE"
FROM "APPLSYS"."FND_ORACLE_USERID" "A1"
WHERE "A1"."READ_ONLY_FLAG"='C'
OR "A1"."READ_ONLY_FLAG"='E'
OR "A1"."READ_ONLY_FLAG"='U'
Notice that while the logical view references the APPS FND_ORACLE_USERID
table synonym, the materialized view references the base table directly.
The generated MV is automatically maintained by online patching whenever
the logical view or anything it depends on is changed in a patch.
Once generated, you can query or refresh the MV as usual.
 EVALUATE USING CURRENT EDITION
CREATE MATERIALIZED VIEW
"APPS"."XXASCP_PLNR_BUYER_MV"
("ITEM_CATEGORY_KEY", "PRIMARY_COMCODE",
"SECONDARY_COMCODE", "ITEM_NAME",
"PLANNER_CODE", "BUYER_NAME")
TABLESPACE "APPS_TS_TX_DATA"
REFRESH FAST ON DEMAND
WITH ROWID USING DEFAULT LOCAL ROLLBACK
SEGMENT
USING ENFORCED CONSTRAINTS EVALUATE USING
CURRENT EDITION DISABLE QUERY REWRITE
 Unable to Update Materialized View After
R12.2 Upgrade (Doc ID 2079988.1)
Can we create materialized views in updateable mode?

Updatable Materialized Views (MV) are not currently supported within

Oracle E-Business Suite Online Patching, but you can create an
updatable materialized view in a non-editioned schema as long as it
does not reference editioned Oracle E-Business objects.

Updatable materialized views are often used to replicate data from

remote databases with the ability to “write back” changes.

So if the Materialized View definition is accessing something from a

database link, that is non-editioned it should work fine as long as the
MV is in a non-editioned schema.

Guidance for Integrating Custom and Third-Party Products With Oracle

E-Business Suite Release 12.2 (Doc ID 1916149.1)
 MVs – General Rules
• MV with FAST refresh cannot contain any
subquery
• Underlying Query cannot contain non-
repeatable expressions (ROWNUM, SYSDATE,
non-repeatable PL/SQL functions, and so on).
• The query cannot contain any references to
RAW or LONG RAW datatypes or object REFs
 MV - Query Rewrite
• Query rewrite is the process of modifying a query
to use the view rather than the base table.
• User do not explicitly need privileges on
materialized views, permission on underlying
base tables are required.
• Optimizer rewrites the queries in order to utilize
materialized views.
• GLOBAL_QUERY_REWRITE & QUERY_REWRITE
system privileges allows user to enable
materialized views.
Questions?

??????????????