Wall of Shame Rant: Oracle Support and Maintenance

In my last Wall of Shame rant, I blasted some shady spammer and had no qualms about it.  But this time is different:  I’m writing this post in a sincere effort to get Oracle to look at some of its policies and procedures, specifically around support.  Oracle has some stellar products and decent support, and in defense of Oracle’s support organization, support people have a tireless, thankless job, dealing with irate customers who think that software should never have problems.  So, while occasionally customers have it tough, customer support often has it much tougher (NSFW for a LOT of language; kudos to that Dell support guy for keeping his cool and staying on the line).

Oracle support, I salute you for the tireless, thankless job you have, but please stop telling clients their problems will be fixed with an upgrade when you’re not sure it will, or worse, know that it won’t.  Also, please honor Oracle’s support policy and don’t withold patches until a client gets to the latest version of the software, knowing that by the time they do, another patch release will probably come out, starting the whole cycle all over.  Of course, it’d be different if the upgraded version actually fixed the problem, but in the below rant, my client couldn’t even submit a patch request that affected the 10gR3 version of Analytics because they weren’t on the “latest version”, which was ridiculous because the latest version didn’t fix the problem either.

Aqualogic Analytics 2.5 has a bug in it (login required) where the “Excel spreadsheet export of the Analytics Collaboration Document Views report has Project Name data in the Documents column instead of the document name”.  That is, you can’t get document data when you export a Collaboration report.  Sure, a relative small issue, but pretty critical for ALUI/WCI portal managers who would like to see which documents are being viewed in a WebCenter Collaboration Server project.

Aqualogic Analytics 2.5 had a patch released for this “bug”, and all was right again.  But then 10gR3 came along, and the functionality was broken again.  No problem – just get the 10gR3 patch right?  Wrong.  There is no patch for 10gR3.  OK, but the bug report says to update to 10.3.0.1, so that should fix it, right? Wrong (according to the release notes). 

We contacted support, and – get this! – were told that Oracle won’t even submit a request to engineering for another patch until we first upgrade to Analytics 10.3.0.1.  But the .1 patch release seems to only provide asian character support, and requires even MORE software installed before putting on this “patch” that does nothing for us:

  • Oracle WebCenter Analytics leverages Hibernate 3.0.5 for persistence. You must install Hibernate 3.0.5 before you install Oracle WebCenter Analytics. Hibernate 3.0.5 can be downloaded from http://sourceforge.net/project/showfiles.php?group_id=40712&package_id=127784.
  • Oracle WebCenter Analytics leverages Cewolf 0.10.3 for its charting engine. You must install Cewolf 0.10.3 before you install Oracle WebCenter Analytics. Cewolf can be downloaded from http://sourceforge.net/projects/cewolf/files/cewolf/cewolf-0.10.3/cewolf-0.10.3.zip/download.
  • So we’re expected to install a patch we don’t need, including other additional software that needs to be tested, only so that Oracle will start building a patch for the version we’re on?  This isn’t an isolated incident; I’ve had an issue with NT File Crawlers as well that Oracle promised “will be fixed if you just upgrade” (it wasn’t, we discovered, after a huge amount of effort on our part to confirm that).

    It seems to me that Oracle support’s #1 directive is to close tickets.  But, you say, “Every support organizations #1 directive is to close tickets, right?” Bear with me on this: there’s a difference between closing tickets and resolving customer problems.  All too often, it seems, I find clients not getting the support they’re paying for, simply because they haven’t installed last week’s patch – regardless of whether last week’s patch fixes the problem or not.  It seems “just upgrade to the latest version” is used way too commonly for support people to avoid resolving problems, because they know it could take weeks or months for the clients to actually be able to install and test said upgrades.

    So, Oracle clients, I suggest this:  The next time you get a promise that an upgrade “fixes the problem”, get it in writing.  You invest a huge amount of time in upgrades (it’s not like Windows Update, after all), and you should have some sort of assurance that this time will be worthwhile.  And to Oracle support: confirm the issue actually is going to resolve the problem.  If you don’t know for certain, then the default answer should be “it DOESN’T”, and you should spend more time investigating the actual problem.

    Am I wrong?  I will update this post with any official Oracle response to this post, and will approve any reasonable comment for discussion.

    Oh, and stay tuned to a future post for the fix to that Analytics problem, bug #8198674.

    Tags: , , , ,

    3 Responses to “Wall of Shame Rant: Oracle Support and Maintenance”

    1. hross says:

      In my opinion this is more of a development/QA issue. Front line, or even further down the line, support people don’t really control the code tree for the product. So… even if they *wanted* to change things, they would have to push back on the developers to actually create a patch. The real problem is the developers don’t roll up their bug fixes into the next major version release. There is no excuse for not including patch sets in the next major version of a software release. Even 2 bit software shops with a couple of developers manage to merge and maintain version control on their code. If you fix it in 2.5, it should stay fixed in 10.3.

    2. Andrea says:

      I had to say that with moving to oracle support (despite the fact that the folks at the support substantially here in EMEA are the same from BEA) i saw that for the first time they seem more reactive in aknowledging problems and proposing patch (maybe now they have the directive or the opportunity to communicate with development).
      I completely agree with your rant about the fact that the priority #1 seems to close the ticket always no matter if the problem is solved or not or end in endless cycles of remote session to understand the problem (and often to discover that there were a lot of misunderstanding).
      That makes me always thinking (but is only an impression) that the people at the support had a knowledge of the product that is just like the mine and they have very little room for improving. I’ve always think to this as a lack of communication with the development team: in my experience if i had an applicative problem the chance to communicate with the developer often lead to the solution.

    3. Ed Tennant says:

      My opinion of Oracle support in regards to WCI has recently improved by a lot. I had a ticket open that I had honestly gotten tired of dealing with. The first person assigned really was not helpful, tried to pass the blame off to other systems, and asked for so much logging that it was not worth my time to provide it. Recently someone else got the ticket and actually tried to replicate what I was experiencing after verifying the trouble in our environment. He had a theory about what was causing the problem and researched it to understand what was happening. I received email from his manager that encouraged me to give them another try and I am glad I did.

      I have had two very positive experiences with Oracle support recently.

    Leave a Reply