* Detect significant latch and mutex contention. Every production Oracle system contains latch and mutex contention. If this were not the case, Oracle would be out of business, and nonconcurrency control products would be used instead. The issue is not whether contention exists; it's whether contention is a performance problem. As you'll see, Oracle's wait interface tells us if there is enough serialization to prompt us to act.

* Determine the problematic latch or mutex. With rare exception, the best solutions are latch- and mutex-specific, which means they are not general, but target a specific latch or mutex. Knowing the contention exists is not enough for a pinpoint diagnosis. You need to determine specifically which latch is the problem. Again, Oracle's wait interface provides us with this information.

* Understand why the latch or mutex is being requested so often. Ask yourself, "Why is the latch so popular? Why are processes so interested in acquiring this specific latch?" Answer the question, and try to discover how you can influence the situation so the latch is not being requested so often. To do this, you must understand Oracle's general serialization algorithm, the specific latch with contention issues, and the underlying memory structure and associated Oracle kernel code. The underlying memory structure and associated Oracle kernel code for the most common latching issues are presented in Chapters 6, 7, and 8, which cover Oracle internals.