Featured Article
What does “Online Patching” really mean for you?
by Matthew Zito, Chief Scientist

With Oracle 11g starting to poke its head over the horizon, albeit in an unformed state, it’s becoming clear that manageability and security are a critical focus for Oracle’s 11g release. Of course, the vision is still a little hazy. I saw an “Oracle 11g new features” presentation by Oracle at an OUG event a few weeks ago that was preceded by more legalese than a corporate earnings report, basically saying: “Just because Oracle is saying these are the new features in 11g, it does not actually mean that they will make it into 11g. If you buy Oracle based on these features, don’t come crying to us when they don’t show up”. But, one of the most interesting features in my opinion, and one that a number of reporters have spoken to me about, is "online patching", which Oracle has been touting widely during these
presentations and interviews.

“Online patching” is one of those phrases that demands a lot of explanation, and Oracle isn’t forthcoming with the details. All that has been said publicly is that some one-off patches will allow you to patch the database online, and they hope to eventually allow you to install the Oracle CPU online. That’s all of the information available. No details about what kind of patches they’re talking about, what the requirements will be, whether DataGuard or some other form of replication will be required, etc. – pretty slim on the details. Anyone outside of Oracle who knows more is bound by NDA as part of the 11g beta agreement (GridApp included).

Unfortunately, we have to look at the track record of patch promises from Oracle – notably the promises of “rolling patches” going all the way back to Oracle 9i. With Oracle 9.2.0.2, it was said that some patches could be deployed in a “rolling” fashion on RAC clusters – In other words: taking one node down at a time, patching it, and bringing it back up before taking the next one down. The stated plan was to eventually increase the number of patches that could be deployed in a rolling fashion, but a couple of things happened. One, the success rate of rolling patches, even the simple ones, was not very high, and people grew leery of the process. Second, the rolling patches wouldn’t work if you had shared ORACLE_HOMEs; although it would seem to reduce the complexity (only patch once per cluster instead of once per node), it instead locked users out of rolling patches entirely. Finally, there just weren’t that many patches available that supported rolling deployments. When only 5-10% of the one-off patches, and none of the CPUs, supported rolling deployment, weren’t you better off just doing them all in the tried-and-true non-rolling fashion?

The answer is, of course, yes.

So now, with Oracle 11g touting “online patching”, I have to say, I’m skeptical. I’m skeptical on two fronts: whether it will be another scenario where the feature is initially so limited that its adoption remains slow to flat; and whether “online patching” really solves the fundamental patch problems – validation, testing, and deployment. When you dig into it, patching a database online really only saves you from having to schedule downtime -- which is certainly annoying, and definitely a useful thing to avoid -- but it doesn’t remove all of the upfront work. DBAs still have to get the patch, read the READMEs, test the patch, document the issues, train the other DBAs how to deploy it, inventory and track the process, and then validate post-deployment that everything is functioning as expected.

At GridApp, we love the idea of online patching. It makes sense from a usability perspective, and it solves the one problem we’d never been able to address for our customers through automation: our software could never work with the developers to schedule downtime. With online patching, GridApp Clarity™ for automation, and GridApp Patchworks™ for certified, tested patch bundles, all of the pain of patching goes away. However, I’m skeptical that the online patching part of that story will be available anytime soon.

<< back