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.