Re: Do you ask the question: How do I work with Oracle Support....?

From: Tim Hall <>
Date: Thu, 7 Apr 2011 12:56:54 +0100
Message-ID: <>


The level of service you get depends on many factors including:

  • Platform : I worked on Tru64 for a few years and the support was terrible. I got the, "we've got no kit to reproduce your issue on", answer multiple times.
  • Version : The older your version, the less likely someone will bother to investigate, fix or backport a fix for your problem.
  • Feature : Some features get special attention. When ASM came out it was a bag of bugs, but the patches came thick and fast. Less publicity worth features get left out in the dark for years. Literally.
  • Skill of the support analyst : You can get clogged down in supplying irrelevant rubbish to support because a bad analyst wants to tick every box, when it is clearly unnecessary.
  • Your level of skill : Knowing how to play the game goes a long way. The more information you give in an SR, the less likely you are going to spend 3 days uploading things "you've missed", before they can start looking at the issue. It's also worth listing all the Notes and Bugs you've already found on MOS that do not fix your issue. You sometimes get them pushed back at you, but for the most part you can reduce the amount of BS you get asked to do and it signals that you have some idea about what you are doing.

It's worth remembering that many of the developers, PMs and good MOS staff frequent the OTN forums, as well as assorted feature gurus. You can often get your answers quicker from there. More importantly, you can develop relationships with those people so that you can approach them directly with new issues. Once they know you are not a gumby, they will know your problem is probably something they should be concerned about. After all, they would rather fix the issues before the rest of the world notices them. :)



On Thu, Apr 7, 2011 at 12:09 PM, John Scoles <> wrote:
> On 06/04/2011 10:45 PM, Robert Freeman wrote:
> So, I wonder if it's fair to judge Oracle support vs. some of the brighter
> minds here. Wolfgang, you and several others here on Oracle-L know Oracle to
> such a degree that your calls to Oracle support are probably more likely to
> be reporting bugs that you have already identified, or dealing with truly
> mystifying issues. Somehow I think that if you are opening an SR and sending
> a 10046 trace file to Oracle Wolfgang, I suspect the problem was anything
> other than simple.
> We all know that remote support can be a difficult proposition. I would
> propose that the complexity of remote support increases in a non-linear
> fashion based on the complexity of the problem. I've also found that you can
> have two very smart people, work the same problem, with two totally
> different answers.
> So, I can understand that there might be a curve of support with respect to
> satisfaction with support based on the experience level of the person using
> support.
> Not to say that Wolfgang should not have gotten sterling support... but I'm
> just sayin'..... :)
> I've always thought that Metalink SR's should include a click box that
> indicates the expertise of the person opening the SR and a resulting
> decision tree comes into play with respect to how the SR is routed. That way
> when Wolfgang files and SR, he can click the super expert box and be routed
> to a super expert right off the bat....
> Been there, done that, gave up on it.
> Not a good idea at least from the service provider point of view.  Seems the
> customer is always a 'Super Expert', and the issue no matter how trivial can
> only be solved by another  'Super Expert'
> Just my thinking.
> Robert G. Freeman
> Master Principal Consultant, Oracle Corporation, Oracle ACE
> Author of various books on RMAN, New Features and this shorter signature
> line.
> Blog:
> the opinion of one Oracle employee. I can be wrong, have been wrong in the
> past and will be wrong in the future. If your problem is a critical
> production problem, you should always contact Oracle support for assistance.
> Statements in this email in no way represent Oracle Corporation or any
> subsidiaries and reflect only the opinion of the author of this email.

Received on Thu Apr 07 2011 - 06:56:54 CDT

Original text of this message