Working with Support

Having helped customers to work with Oracle support the boot was on the other foot this week when one of my Amazon purchases went wrong.  I got to experience the frustration of trying to work with a support process that I didn't really understand and I got the feeling that the people at the other end of the web screens didn't really care.  My problem was never resolved to my satisfaction, because I was never able to engage in a dialogue with Amazon support, they just assumed what the problem was without ever reading the note I sent and kept giving me unhelpful information.

I think that Oracle customers sometimes feel like this.  However Oracle, like most large software organisations, does make a lot of effort to provide decent support and often the frustrations come from not realising the limitations of what support can and can't do. So in the interests of making life easier I offer some of my suggestions for working with support.

Describe Your Problem

You would be surprised how many service requests consist of a single line of problem statement along the lines;

"my application server doesn't work"

This is obviously less than helpful to the support engineer, although at least it usually identifies the product with which the user is unhappy.  Try and write a short concise description of what you believe the problem to be.  An example might be;

"When configuring two app servers to be in a cluster on different machines, state information appears not to be replicated between the two machines."

This informs the support engineer that we have a problem with session replication, drilling down into the product area.  Obviously we need to provide more information than this.  The better the description the more likely that support can assist you quickly.

Simplify the Problem

One customer I work with is notorious for claiming they have a problem, but the problem is wrapped up in a hugely complicated environment that only they have.  In such cases it can be very difficult for support to isolate the problem.  Try to reduce the number of moving parts in your solution to just those that are needed to provoke the problem.  For example if you have a BPEL process calling a J2EE web service which in turn invokes another web service, and you think there is a problem with the J2EE web service then try calling it from a simple test page and if possible stub out the back-end web service.  This will reduce the complexity of the solution and the possibility of unexpected interactions.

Provide Environmental Settings

Upload relevant environment files before being asked for them.  For example if you are having a problem with HTTP Session state replication then upload the web.xml, orion-web.xml, application.xml, orion-application.xml files from the app servers involved.  If necessary describe relevant network configurations, for example in the session replication case identify network connectivity between the boxes, indicating any firewalls, routes, switches between the machines.

Create a Test Case

If at all possible create a test case that can be uploaded to Oracle support.  Such a test case should be self contained.  If you create such a test case then you can reduce your management of the request to hitting support with a stick until they provide a solution for you.  Note that a test case that relies on access to a 3TB database is not really self contained!

Monitor the Service Request

If the problem is important enough to raise a service request then make sure that you manage it.  Respond rapidly to support requests for more information.  If you don't feel that you are getting any attention then  first of all add an update to the request politely asking for a status update.  Don't ask for updates every few hours unless it is a priority one request and you don't mind providing someone on hand 24 hours a day to help resolve the problem.

Restate the Problem

Service requests have a nasty habit of exhibiting exponential growth, and this can make it very easy for support analysts to miss important pieces of information.  I find it useful to restate the problem every now and then in the request, summarising what has been tried to date, what the results were and basically providing all the information needed in a few paragraphs rather than spread across several screens.  This makes it a lot easier for a new support analyst to pick up your request and start working on it effectively in a short time.

Escalte Requests Only When Necessary

If you really feel that you are not getting anywhere with a request and that support is not giving it the priority you feel it deserves then you can ask for the priority to be raised or the request to be escalated.

Raising the priority engages a greater commitment from support but also requires a greater commitment from your own organisation, support will expect you to be as responsive as you expect them to be.  For some priority levels a business case is required indicating why this problem is impacting your business.  Raising the priority should be done when there is a definite business impact that makes this a high priority to fix within your own organisation.  It should not be dpne just to get resources working on a problem because support will expect you to give up evenings and weekends to get your business back on its feet.

An alternative to raising the priority and more suitable when you feel you are being ignored to to request an escalation.  This will engage the duty manager and will raise the visibility of your request.  This approach should only be taken when support appear to be unreasonably tardy or obtuse in their pursuit of a problem.

Be Polite

Like you support are human beings, well most of them anyway, and they deserve the same respect and politeness that you would expect from your own customers.

Summary

The list above is not exhaustive, it just covers some of things I have found help customers to get the best out of Oracle Support.  Support wants to do a good job and they sometimes feel that customers deliberately withhold information, of course you would never do that but to summarise again here is Antony's list of tips for working with support;

• Describe Your Problem


• Simplify the Problem


• Provide Environmental Settings


• Create a Test Case


• Monitor the Service Request


• Restate the Problem


• Escalate Requests Only When Necessary


• Be Polite