Edition based redefinition – an apology

In April 2008 (wow, does time fly!) I used the following picture in my "11g features for Developers" presentation at the Australian Oracle User Group conference.


I think the picture is from the movie "Indiana Jones and the Last Crusade"… where they sought the Holy Grail.

I used the picture because I said that Edition Based Redefinition (EBR) was the Holy Grail of 24/7 Oracle based applications.  (Like most Oracle presentations at the time, and since then, on EBR) I then presented several examples of evolving an application without service interruption.  It’s not a trivial task – there is editions to manage, special edition views to be created, forward and reverse cross-edition triggers potentially required…but if the quest is no service interruption – then editions is the way to go.

So….has the Oracle community embraced editions ?  Well…to my knowledge, it has not been a runaway success.  Perhaps its the complexity?  Or perhaps for many customers, there simply isn’t the need to be strictly 24/7 in terms of application availability.  Easier to just take a small outage, deploy the code, and resume.  I’m sure people have their reasons – but maybe some of those reasons are due to Oracle practitioners like myself always talking about EBR from an application continuity perspective.

Which is why I come offering an apology :-)  Like everyone else, I’ve always approached EBR from a view of application continuity.  But as I was creating a standard database trigger at work recently, I realised that stance was doing EBR a disservice, because it’s not necessarily about continuity and version control at all.  Here’s why:

Since 11g, you have been able to create triggers in an initial status of DISABLED.  That is very very cool.  Why ?  Because if you are creating a trigger, and for some reason that trigger will not compile successfully (eg, something as simple as a syntactical error or something less obvious, such as a privilege missing on an object that the trigger references) – then that error is a very very public one.  If the trigger is created ENABLED, but does not compile, then the table that the trigger is on is effectively broken, because all DML on that table will return an error.  11g fixed this problem by allowing the initial state for the trigger to be DISABLED.  So if the trigger does not compile, there is no damage done.  The problem can be resolved without impacting DML on the table.

Which brings me back to EBR.  Even if you don’t care about application continuity, and even if you are deploying your application changes during a scheduled outage, it dawned on me that EBR takes the disabled trigger metaphor and extends to other database objects.  Consider now how safe your deployments could be if you did this:

  • create a new edition,
  • (If needed) create edition-ing views representing the target state of your new tables,
  • compile all of your code changes into the new edition,
  • drop the edition

Whoa there!!!….drop the edition ?  What’s all that about?  Well…I’m presuming that you are currently not using EBR because there is something about it that makes you uncomfortable. And that’s fine – this post is not trying to dissuade you from your current stance.  My point is that even in this instance, you can be using EBR to test your deployments on the target database that your true deployment will be on.  How incredibly cool is that !?  Imagine the confidence you will have if you can roll out all of your changes in advance in deployment "test mode".  You’ll catch any errors that may have had you in a panic and/or considering a backout if they had occurred during the true deployment.

And once you start doing "trial deployments" in this way…well, who knows, you might end up deciding to simply stay on the new edition, and voila – you’ve begun the journey toward application continuity in an easy and safe manner.

So here’s my new succinct summary on EBR:

If you have not enabled EBR on your database, you are not being the sharpest knife in the drawer🙂

Happy Easter.

4 thoughts on “Edition based redefinition – an apology

  1. The invention of EBR was commissioned by the team that builds Oracle E-Business Suite — for obvious reasons. The general availability of E-Biz Release 12.2 was announced at OpenWorld 2013. From this release onwards, every E-Biz patch and upgrade will be done as an EBR exercise. By now many tens of customers are using this release in production; and this number will inevitably grow to equal the total number of E-Biz customers world-wide. Famous-name customers are using EBR too. A Salesforce engineer gave a talk on their use of it at OpenWorld 2014. Connor’s “it has not been a runaway success” is out of date.

    The biggest challenge for would-be EBR adopters aiming for zero downtime application patching is the thinking, and then the work, that they have to do in order to change, and then to administer, the outside of the database components to support hot rollover. Human beings have to change the way they do things; and it takes real will to succeed in this space.

    Obviously, it’s easier for the staff who run an application simply to force their users to suffer so that they can patch in the peace and quiet of down time. When this suffering brings a noticeable financial penalty, then upper management can do the cost/benefit calculation. When the cost of adopting and using EBR is less than the opportunity cost of the downtime, the choice is a no-brainer. The choice is also easy when the cost/benefit outcome is the opposite.

    Bryn Llewellyn
    Product Manager for PL/SQL and EBR
    Oracle Corporation HQ, Redwood Shores CA 94065 USA

    April 2015

    • Thanks for stopping by and taking the time to comment Bryn.

      We might need to agree to disagree on our definition of “runaway success”🙂 When EBR is the *norm* for database application changes, namely, we reach the saturation point that when a customer is going to deploy an application change, that EBR is either an automatic choice or at least always a candidate on the table – then this would meet my definition. Whilst the “show of hands” survey method at user group meetings may not be the most rigorous of statistical sciences🙂, it does suggest EBR is still considered niche.

      But then again, thats the point of this blog post. Even if people are still taking the “easy” option of an outage to evolve their application, I’m espousing the premise that EBR should be a use case here as well – its a fantastic risk mitigation option.

      EBR remains a hidden gem that not enough people take advantage of😦

  2. We use peoplesoft. I can’t see edition based redefinition working without substantial changes from Oracle, but I’d be grateful if you would point me at some instructions. I have probably not looked into it enough, but as I understand it, you can not edition a table definition, so you have to use a view. A view can’t (obviously) have the same name as a table, so we would have to rename all the tables. This would completely break the applications ability to maintain the table definitions. To take advantage of it with a vendor supplied application is almost impossible, and will certainly entail significant extra work than using the vendors suggested procedures.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s