Saturday, November 8, 2008

Digging

One of the abilities a sysadmin must have is the ability to dig. What do I mean when I say "dig"? Well, I mean that many times you face a problem that seems to be rooted deeply inside the system, and a sysadmin has to know how to solve these problems. The first thing I personally do most of the times is to say "OK, that's as far as I'm going, time for official support", but as I wrote before, this usually ends up with me de-compiling Oracle's code.

Time for an example.
I've recently been trying to utilize Oracle's ESM (Enterprise Security Manager), since the system it's intended for requires batch actions I used the command line tool. Guess what, when I use one of the commands the GUI stops showing associated roles for the related Enterprise Role, since it was obviously a coding bug, I've logged an SR thinking to myself that this bug, if reproducible (and it is) means no one have ever tested this functionality. About a month later I was notified that a fix was created and they're testing it. Two days later - bad news, the fix did not pass testing. And this is actually the current status (a few months have passed by now).
Last week I got tired of this whole thing  so I've started digging for the source of the problem. Apparently, when you use the command line, the record generated in the OID has a case mistake. So my next move was to de-compile Oracle's code and fix it, and voila, it works!
When I told the support analyst about my fix, he said he knows the solution is easy but the problem is that they have some incompatibility issue with different database versions. I really don't care if it's reasonable for such a small fix to be taking such a long time to implement, I'm just happy I know how to dig.