This blog post was originally released on Pythian blog

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 1st 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 EBR

Before 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

Basically, the most important message here is that there are new restrictions introduced on dependencies between different objects.

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?

  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.

Similar problems could also be introduced with other customized non-editioned objects.

Problem 2: Online patching might not be as effective as advertised. I’m basing this statement on the information that there would be another schema – APPS_NE – introduced for non-editioned (or potentially editioned) objects. Online patching would not be able to patch these objects – some downtime would be required here as I understand, but probably Oracle has some tricks in mind for this. Also, RDBMS patches would still need downtime.

Problem 3: Based on the information available, there would be quite a lot of reorganization going on in seeded schemas, and I still haven’t seen a good document explaining what is going to be changed, and how we should prepare for the changes. This will definitely affect customizations, but there’s still no guideline released on how to make customizations ready for R12.2. Additionally, I think the upgrade to R12.2 might require much downtime to reorganize all the schemas.

Despite all the concerns and unknown variables, I’m very excited to see Oracle trying to do something that has never been done before! Did you know the main reason they started creating the Edition Based Redefinition feature was the requirement from the ERP team to implement the online patching feature? As the EBR was specifically designed to allow online patching for Oracle e-Business Suite, I hope they will have gotten all the gears right to implement it efficiently enough. R12.2 should be out in 11 months, and I really can’t wait to get my hands dirty with it.