Chapter 2. Targeting the Right User Actions | Optimizing Oracle Performance

One of the first steps in any project is to figure out what the project is supposed to accomplish. The formal written result of figuring out the project's goal is called the project's specification . An Oracle performance improvement project, like all sorts of other projects, needs a specification. Otherwise, you have nothing that you can use to measure the success or failure of your project.

Many Oracle performance improvement projects are crippled from their beginnings with poor specifications. You've probably seen the cartoon in which a programmer's manager says, "You start coding. I'll go find out what they want." A lot of people try to "tune their systems" without ever really knowing what they're out to accomplish. On the other hand, there's no need for a system to languish for months while analysts try to construct the "ultimate" project specification, charging time and materials rates while they inch forward. Constructing a good specification for an Oracle performance improvement project should usually consume no more than a couple of hours.

The aim of this chapter is to help you get your performance improvement project started on the right foot , so that your project will optimize the economic value of a system. I'll explore some bad project specifications and explain why they hurt the projects they were supposed to help. I'll describe some specifications that have worked well, resulting in projects that have quickly created great positive economic impact to their systems. Throughout the chapter, I'll list some attributes that have distinguished good specifications from bad ones.

Top