Well, there are a few types of patches, generally speaking:

a) database patches
b) OS or infrastructure patches
c) application patches

Let's peek at each one in turn.

Database patches -

Many times these days, they could be installed with little to no downtime. With RAC or RAC One Node http://www.oracle.com/database/rac-one-node.html - you can apply many patches (not all, many) online - with a single database. With dataguard and a logical standby or a transient logical standby - you could apply any patch with minimal service interruption (I'll call it an interruption - not downtime - since it is more of a pause during the switchover and switchback events).

So, why doesn't everyone do it? Well, not everyone has RAC or RAC one node. The more available you want, the more resources (money being a resource, hardware being a resource, training for the hardware/software being a resource, testing the increased capabilities being a resource and so on) it takes. Not everyone has the resources necessary for this solution. Nor do they deem the incremental cost of the additional resource to be worth the decreased downtime. It is a trade off.

OS/Infrastructure patches

Much the same as a database patch. In most cases - RAC/RAC one node would provide you with everything you need to patch most of your infrastructure without taking a database down - if the infrastructure you are patching however is your cluster itself, then step in dataguard and the ability to gracefully switchover to your failover site and run there while you do anything to production you want. With RAC/dataguard - you could have no scheduled downtime due to OS/Infrastructure patching.

So, why doesn't everyone do it? Same as above - it is all a tradeoff. The more available you wish to be - the more resources it will take, the more planning, the more design, the more testing, the more money and so on. It might not be deemed "worthwhile enough" to expend those resources for a given system.


Lastly - the really hard one - application upgrades.

before I dive into that, I'd encourage you to read these if you haven't already:

https://www.oracle.com/technetwork/issue-archive/2010/10-jan/o10asktom-172777.html
https://asktom.oracle.com/Misc/oramag/edition-based-redefinition-part-2.html
https://asktom.oracle.com/Misc/oramag/looking-at-edition-based-redefinition-part-3.html

That overviews the new Editioned Based Redefinition (EBR) capabilities in 11g Release 2.

As you progress from issue to issue reading that - you'll see it go from "easy to implement with" to "more complex" to "requires a lot of design to upgrade". Another way to say that is "as you get more complex with the upgrade/patch - the amount of effort needed to make it 'entirely online' increases". It will come back to a pure "is it worth the resource investment to make this an online patch or not". It all comes back to resources.

I can see a day in the future when E-Business Suite (EBS) makes some of it's patches "entirely oneline" - if they fall into the simple category (just replace some code, views, editionable objects...). I can see them REDUCE the amount of downtime (from the end user perspective) of an upgrade or patch that touches non-editionable objects (by making the update of the editionable things 'online' and taking downtime just for the non-editionable things). But given the sheer complexity of EBS - I'm not sure (this is purely my opinion remember) they would ever get to the point where they program the entire upgrade like I did in the third installment above.

So, we have the tools necessary to do online application upgrades now - but we might not use them 100% of the way. We might use them to REDUCE downtime where it is easy (little resource investment in the way of development), or we might use them to ELIMINATE it (more and more resources as the complexity of the patch/upgrade increases).



In short - it all comes back to "it takes extra effort which translates into resources - be they human, machine or money - to be 100% online"

And not every application is worthy of the resources. This site, asktom.oracle.com, takes downtime to upgrade the database. We are "oracle" so we know we have access to the software resources, and the training resources, and the qualified human resources - so why not make it 100% online?

Because it just still isn't worth it, it is not a mission critical system. If it is down for a few hours every so many months, it is not the end of the world. It is not worth the extra planning that would be involved, not worth the extra hardware that would be involved.

But we do have many other systems where these capabilities are exploited - as they are mission critical.

So - that is the bottom line - "how much is that downtime worth to you", what does it cost to be down? Little cost? then little impetus to be 100% online. Huge cost - higher impetus to reduce (maybe not eliminate but reduce) downtime...