This chapter is from the book
This chapter is from the book
This chapter is from the book
Diagnosing the Problem
Before contacting Oracle Support, you should have a good description of the problem and what caused it. Use of support is most effective when you know precisely what you want from them before you call.
TIP
When a problem surfaces during an implementation project, I usually spend about a half hour defining and understanding the problem before contacting Oracle Support. You can solve more problems on the first contact if you understand what the system is doing.
Concurrent Manager Logs and Messages
Problems with batch jobs and interfaces that are run by the concurrent manager can be investigated by looking at the runtime log produced by these jobs.
For example, you run a concurrent process and the Requests form shows the job completed with an error. Before calling for support or investigating the executable or the data, which can be very involved, gather facts by reading the concurrent manager log. Usually, an important series of diagnostic error messages is near the end of the log. There are often several messages, and the trick is to pick out the ones with the highest odds of revealing the problem.
Understanding the Sequence of Events
Understanding what happened and in what order is important to understanding and diagnosing the error. Document what happened and be prepared to lead the support analyst through exactly the same series of keystrokes to re-create the problem. Know the navigation path, the data that was entered, parameters and lists of values that were used, and so forth. Because an error might create several error messages, try to determine which event is the root cause because secondary messages might go away when you fix the basis of the problem.
Repeating the Error
If you can't re-create the problem consistently within a test database, contacting Support and logging a Technical Assistance Request (TAR) might be a waste of time unless the problem is caused by a rare, one-time event.
Examine the parameters and user procedures that caused the problem. Collect error messages, logs, screen shots, and other output before contacting Support. If you have them at hand, the conversation with the support analyst will be more efficient, and you can add these items to the TAR record.
Also, try to understand enough about the problem to re-create the error on the support analyst's system. When you can create the problem on an Oracle system, you almost certainly prove that the problem is not caused by a customization you made and the problem is not caused by a data anomaly. If you can't re-create the problem on an Oracle system, the odds become good that the current version of the program will solve your problem.
Using Deductive Reasoning
Investigate the problem and use deductive reasoning to eliminate what the problem can't be and define what it is. On an established release of the software that has been in production for more than six months, proper definition of the problem might be 90% of the solution. Definition of the problem should be your responsibility. If you leave problem definition to the support analyst, you might spend a lot of time on the resolution.
Determine whether the program has ever worked. If it has, determine what is different this time. Suspect your procedures, the user, the data, or a system change. Involve the implementation team member in the problem statement. Gather facts about the problem.
Break the problem into parts. Determine which parts are working, and eliminate them from further analysis. This process directs your analysis to parts of the system that might be causing the error. Often, the project team spends a lot of time analyzing what they know about or just worked on simply because they think they understand it. The problem might be located elsewhere. Concentrate on what is not working and don't waste time analyzing what is working. If the problem is still not defined, subdivide the system further until you are working with a piece that is small enough to understand and diagnose.