Oracle Applications Performance Tuning Handbook (Book/CD-ROM package)

Chapter 1: The Performance Methodology

Oracle Applications systems typically consist of a number of highly integrated and interdependent modules that can be implemented in a number of ways, sometimes making the resulting system appear quite complex. The modules are rarely static, and no two systems are ever alike. No matter how meticulous your proactive capacity planning has been, at some point during the system life cycle you should expect to encounter an emergency reactive performance problem. When faced with a performance challenge or, worse still, when facing many system problems, it is sometimes very difficult to know how and where to start, and perhaps more importantly, how to identify the resources you need to fix the problems. This chapter will help you to address these issues. A number of problem definition methods, decision support systems, continuous improvement techniques, and other methodologies can be usefully employed for troubleshooting Oracle-based systems. However, many of these approaches are necessarily abstract and very generic. They can be so complex that they require specialist problem-solving skills, making their deployment almost as difficult as solving the problem they are endeavoring to identify. This chapter describes a proven methodology specifically designed to identify and analyze complex and multifaceted Oracle Applications issues. Although this approach is primarily intended for use with Oracle Applications, it can also be used to identify problems with other Oracle-based systems.

TIP To see an example of the questions used in this approach, review the questions in Form 1-1 at the end of Chapter 4. (The dark edging on all Form pages makesthem easy to locate throughout this book.)

The methodology described here evaluates all of the interacting components by considering the system in its entirety, or "holistically." Other methodologies such as Kepner Tregoe and several proposed by the University of Maryland also use some of the same techniques but necessarily adopt a more generic approach. This holistic methodology integrates some of the best features from other techniques while maintaining the common approach of using five problem definition stages: What, Where, When, Extent, and Priority. Which approach you decide to use is a matter of personal choice. If you already use an approach or have a strategy with which you are more familiar, you may find it useful to modify or incorporate stages from this chapter. This methodology documents an approach based on real-world experience that has evolved from numerous performance engagements working on fundamentally disparate problems. It has repeatedly proven to reduce the effort and expense of locating and identifying system problems. A great deal of time has been expended

on maintaining the speed and simplicity of the approach, while ensuring it remains accurate and sufficiently comprehensive to identify the most complex Oracle Applications issues. Not only does it formalize the problem definition process, but it also enables you to correlate the subsidiary effects and possible consequences of poor performance from other areas.

Why Use This Methodology?

Throwing resources at a performance problem is rarely helpful. It can lead to contention between the parties, with you in the middle trying to mediate. If one of the on-site experts tells you that there are no problems in their area, applying this methodology can provide a definitive insight.

TIP It is essential to always draw your own conclusions, based on the facts and without bias.

Two strategies are commonly used when faced with a performance problem. One is to engage a database tuning expert, who has specialized skills and an understanding of the Oracle tuning tools. The other is to throw hardware at the problem. Neither of these options provides a long-term solution; they only address the symptoms, not the causes. There is a lot that you can do to locate and identify system problems. The value of the method described in this chapter is that while you may need an expert in a particular technology stack to resolve a problem, you do not need to be an expert to identify where the problem is in the system. Your goal is to narrow the scope of the investigation as quickly and cost-effectively as possible, enabling early identification of the correct resources. This will not only save you days or possibly weeks of sub-optimal performance; it can also avoid the significant costs associated with extending the working day or having to change the business practices in an attempt to address the shortfall.

Do You Need to Be an Expert?

Being an expert in every technology stack would be very beneficial. However, it is highly unlikely; you may need expert assistance to resolve a problem...