Thursday, August 7, 2008

Flexibility

Patching mechanisms such as Oracle's opatch and it's more successful brother adpatch (this issue deserves a post of it's own) are great stuff - you can introduce specific bug fixes into the system, install a whole new functionality or make your application compatible with a new database version and all without having to upgrade a whole application version. The other side of this coin is the fact that you can ignore bugs you don't care about and you don't have to maintain and debug functionallity you don't use. Well, sounds great, everyone gets a suit sewn to perfectly (or at least nearly perfectly) match his needs.

But those mechanisms frequently require strict dependency and versioning management, and sometimes, I think, Oracle just exaggerates.

Let me show you what I'm talking about. During installation of SCM_PF.J on 11.5.9 I got many failed workers, two of them relate to my point:

1. A worker failed and searching Metalink I've discovered that this bug can be fixed by applying a database patch. The README file for the patch says that I should apply the patch and run drkorean.sql, it also specifies very strictly that I should make sure my database is down during the process. Off I go and try to install the patch, but opatch complains about bad inventory which might actually be true since this is a replecated development environment and it might have a problematic inventory. But I'm not the one to give up easily, so I take a look at the actions.xml file of the patch, and... big surprise (not really)! All the patch does is to copy drkorean.sql to a designated folder. A more naive sysadmin could've started panicing, trying to fix his inventory or even open an SR to cure the poor thing.
Wouldn't a simple "copy-run" instruction be a better option? It's not like there're problematic versioning issues here - it's a single sql script that fixes a specific bug - if you insist on having some supervision here, let me take care of this single script's version, believe me I'm up to it. And what's that about taking my database down? Guys, I was in the middle of applying a patch!

2. Another worker failed and Metalink pointed me to a "PROBLEM" document that said that I should apply a patch - unluckily the patch is for 11.5.10, no good for me. Like in the previous case a brief glance inside the .drv file proved my suspicions that all the script really does is to replace the sql script that the worker failed on with a newer version. I'm 100% sure that there's no problem running it on 11.5.9 - and that's actually what I did.
OK, I get it, the bug was originally discovered on 11.5.10 and that's probably the only setup it was ever tested on. But, wouldn't arriving at the conclusion that it matches 11.5.9 as well save us all some time and blog lines? Woudln't it be ashame if I had to open an SR and wait for a reply to handle this trivial case?

No comments: