R12.2 online patching – What are the hidden costs?
One of the hot topics at the UKOUG 2011 Technology and E-Business Suite Conference last December was the upcoming release of Oracle e-Business Suite R12.2. The new release will bring us lots of new features, usability improvements and new versions of technology stack components (Oracle Database 11g R2 and Oracle Fusion Middleware 11g R1 as the application server), but the most important and impressive new feature of course will be online patching. Online patching is supposed to change the game completely. All owners of E-Business Suite environments know that patching requires downtime. Although it can be reduced with various techniques (e.g. staged APPL_TOP), some downtime is still required to apply a number of changes. Online patching will not eliminate downtime completely, but will reduce it significantly by using “Edition Based Redefinition” (EBR) at the database level and using a secondary applications file system for online patching. In fact, all patching activity will be an online operation; downtime will be required only to switch from one version to another. I attended a great presentation at UKOUG 2011, “Oracle E-business Suite’s use of edition-based redefinition for online patching,” delivered by Bryn Llewellyn from Oracle. The presentation provided thorough insight on how EBR works and how E-Business Suite will be able to use it for online patching. It answered many questions, but raised a few more questions and concerns. I’ll try to summarize in this post the main concerns I’ve been thinking about after attending this presentation. At this point I have to stop and add a disclaimer. Actually, it’s a double disclaimer, because there was a disclaimer on the 1 st slide of the presentation saying something like “don’t take it for granted” as we were discussing features of a product that is not yet released. Since I’m giving you my thoughts on a product which I haven’t seen, here it is: “don’t take it for granted”^2!
Limitations of EBRBefore we move on, I have to give a short background on a few important specifics of EBR, which are taken from the EBR documentation and were also discussed during the presentation (You can read full documentation in Oracle® Database Advanced Application Developer's Guide Chapter 19):
- 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.)
- 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)
- All non-editionable objects are always non-editioned (no matter what schema they reside in)
- !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.As described before, “a non-editioned object cannot depend on an editioned object”. Think about it! I’ve seen lots of materialized views depending on functions, packages or views, and tables with user-defined data types. Oracle will need to remove as much of these dependencies as possible (as they need as many editioned objects as possible to have a way to change them online); otherwise the online patching would be too limited (which I really hope it won’t be). The presenter also mentioned that a new schema APPS_NE (APPS Non-Editioned) would be introduced in R12.2 to hold potentially editioned objects for which these dependencies would not be removed. Oracle will take care of these dependencies by separating the editionable objects into 2 schemas instead of one– they will make it work for their objects, don’t worry. Problem 1: What I’m worried about are customizations – I’ve seen quite a few environments where custom materialized views are created depending on views and functions. As the views and functions will likely become editioned in R12.2, these custom materialized views will become invalid. What options do we have?
- 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);
- 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);
- 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.