R12.2 online patching – What are the hidden costs?

Limitations of EBR

1. All schema objects can be divided in 2 groups, editionable and non-editionable:
   • Editionable objects are synonyms (except public synonyms), views, and all PL/SQL object types (functions, libraries, packages and package bodies, procedures, triggers, types and type bodies).
   • All other objects are non-editionable (e.g. tables, indexes, materialized views, database links, etc.)
2. Editionable objects can be editioned or potentially editioned
   • Editioned editionable objects reside in an editions-enabled schemas;
   • Editionable objects residing in schemas that are not editions-enabled are potentially editioned (I really don’t like this term, as these objects are in fact non-editioned)
3. All non-editionable objects are always non-editioned (no matter what schema they reside in)
4. !IMPORTANT RULE! A non-editioned (and based on my experiments also potentially editioned) object cannot depend on an editioned object. For example:
   • A function-based index cannot depend on an editioned function.
   • A materialized view cannot depend on an editioned view.
   • A table cannot have a column of a user-defined data type (collection or ADT) whose owner is editions-enabled.
   • A materialized view cannot depend on editioned function

EBR, R12.2, online patching and our customizations.

1. We can get lucky and it might turn out that the dependent objects will become non-editioned in schema APPS_NE. In this case, we’d only need to change the schema for the referenced object (remember, APPS synonyms will be editioned);
2. We might need to create duplicate functions in an editions-disabled schema to reference in our custom materialized views If the function we are duplicating is seeded, we will likely miss the moment it changes, so there is an increased risk to get wrong data from the MV. (By the way, creating a non-editioned wrapped function for editioned function is not allowed);
3. We might need to rewrite our materialized views to depend on tables directly (not synonyms or views), but EBS also brings editioning views that allow access to “different versions of data” from the same table. MVs cannot depend on editioning views – so our MVs might require changes whenever the table is modified and a new version of an editioning view is created.