If you are new to Online Patching and the Oracle Applications release 12.2 Development Standards, you may be confused by the new terminology used to categorize objects in the database.
Today our experts have set out to shed some light on that topic by explaining how Editions work on the database and what each category of objects really mean.
Oracle 12.2 Editions
Database Editions
Database Editions are a new feature that allows you to have two versions of certain types of database objects with the same name, type and owner.
This is similar to a database schema, since you can have a same object (that is, an object with the same name and type) on two different schemas. Well now, the Edition level adds the schema to the equation, so now you can have two versions of a same object on the same schema.
Think about two versions of a database plsql function, version 1 and version 2, having both the same name, type and being created on a same schema.
A database session context variable will define which session you’re working on, so depending on the session you’re connected to, you will access version 1 or version 2 of the plsql function.
The Online Patching architecture that Oracle defined works with two editions: one used for running purposes (that’s the code users are working with), and one for patching purposes (that’s the code that’s patched when you apply a patch). What this means basically is:
- If you’re a final user, your environment is set with the running edition, so you access the running version of the code (let’s say that’s the plsql function version 1)
- If you’re a DBA applying a patch, your session is set to the patching edition, so you work with version 2 of the database function.
Editioned Objects
Unfortunately, object editioning doesn’t work with all object types. The reason behind this is that even though you can manage 2 versions of a piece of code with relative ease, it’d be almost impossible to manage different versions of objects that keep data, like tables, since that would require managing different sets of data, one for each edition, which would need enormous amounts of storage and processing capacity.
So this is a hard constraint: object types that store data cannot be editioned. And there are many object types that store data, like indexes (they keep the values of the indexed attributes), or materialized views (the actually keep the data in the view), sequences (they keep the last value assigned), database links (they keep the target database information), etc.
Editionable objects are mostly those containing code, like database packages, functions, procedures, views, synonyms, types, etc.
Also, please consider that the “Potentially-Editioned” term is used to describe an object that belongs to one of the editionable types (like a database package) but is not editioned. So a “Potentially-Editioned” object “could” be editioned, but for any reason it’s not, like being installed on a non-editioned schema.
Non-Editioned Objects
Non-Editioned objects are those that cannot be editioned. This includes all objects that store data, like tables, materialized views, temporary tables, indexes, sequences, etc.
Effectively-Editioned Objects
A non-editionable object can never be editioned, though there are some workarounds available to apply “edition-like” features on those object types. Those are the effectively-editioned objects.
Effectively-editioned features are provided by the Application foundation and not by the database. They include functionality to simulate edition features on data (used on seed data tables so you can manage different sets of data for each edition on the database) and for materialized views, so you can bypass a restriction that otherwise would make it impossible to work with materialized views on a R12.2 environment.
For more on R12.2 topics, check our other blogs.