So, You Don’t Need Online Upgrades

EBR is a set of features that enables patching and upgrading live Oracle-based applications in an online fashion, with zero downtime.

If you are responsible for an Oracle-based application, and you have a maintenance window, during which users do not use the application, you don’t need EBR.
You can upgrade in an offline fashion, by taking the system down during the maintenance window.

But, although you don’t have to use EBR, using EBR may improve your quality of life and your users’ satisfaction.

Improve Your Users’ Satisfaction

The website of the bank that manages my account is “temporarily unavailable” every night between midnight and 4am. I guess this is their maintenance window, during which they do (among other tasks) offline application upgrades.

My user experience is usually ok.
Rarely do I want to check my balance or to do some transactions in the middle of the night, and even if I do want, it’s not a matter of life and death – I’ll wait for the morning.
But if the bank’s website was available during nights as well, then my experience as a user would be excellent, rather than just ok.

Online upgrades mean less downtime, and less downtime means better user experience.
Even if downtime is acceptable, users are happier with no (or less) downtime.

Improve Your Quality Of Life

Upgrades can be done at any time

With EBR you are not limited to do upgrades only during the “maintenance window”.

Upgrades can be done at any time. We don’t need to look for off-peak hours, that are usually at nights and weekends – when we are tired and frustrated. We can do it when it’s most convenient to us – during work hours.

But it’s not just about our convenience.
If something goes wrong with an upgrade that is executed during work hours, rather than at nights/weekends, then solving the problem is much easier and usually faster. Our colleagues that can help with the problems are there. We don’t need to wake someone in the middle of the night, or to try tracking someone on a weekend family trip.

And most importantly, in my opinion, is that we can deploy features as soon as they are ready.
With offline upgrades, waiting for the maintenance window – which may be once a week, once a month, once a quarter, or any other frequency – means that your users do not get the best service.
EBR allows for agile development – you deploy features (and bug fixes) as soon as they are ready.

Upgrades can take as long as needed

The maintenance window is usually limited to several hours. What if the upgrade takes more than that? With EBR, the upgrade takes as long as needed. It is not limited to some arbitrary period of time.

When the upgrade is limited in time, we tend to be stressed, because we’re in a race against the clock. This is obviously not a good thing. And this stress may cause us to make some errors, which means the upgrade will take even longer, with a higher risk of not finishing it on time, which makes the whole situation even more stressful.

With EBR the upgrades can be done properly, with no pressure.

We can start an upgrade with a new edition in the morning, and then something more urgent comes up and we handle it, and get back to the upgrade later on – maybe even in the evening – and complete it.

Or, if we start an upgrade before lunch time, there is no problem having lunch before finishing the upgrade.

If during the upgrade there are some “half-baked” objects, or even invalid objects, in the production schema, it doesn’t matter.
Not even if it’s true for many hours.
As long as these objects are in the new (unexposed) edition, nobody knows it, and the end users (that are exposed only to the pre-upgrade edition) keep using the application uninterruptedly.

Database-side upgrades can be done independently of server-side upgrade readiness

With EBR, we can prepare a new edition, expose it to a new service, and the app server upgrade can be done at any time afterwards.
If I’m brave enough, I can even go on vacation once I expose the new edition, and the server may start using it even days later 🙂

Flexible exposure of new versions

With EBR, we don’t have to expose the new edition to all the servers at once. We can take advantage of that, and first use it only by a dedicated testing server. All the “real” users continue using the old edition during this time, without being affected.

Another flexibility we gain with EBR is that different types of app servers may use different versions (i.e., editions). Sometimes a database change affects several types of app servers, and only some of them are ready to upgrade. No problem – they can continue using an older edition, while the app servers that are ready can upgrade and start using the new edition.

Summary

EBR is not just about reducing downtime.
It gives several benefits that can improve the quality of life for both the developers and the end users.
And, at least based on my experience, the additional efforts that are required to develop and deploy with EBR are not high.