I've presented many technical details in this chapter. The goal was to help you understand serialization, Oracle's general latching and mutex algorithms, latching and mutex specifics, and how to identify when there is significant latching and mutex contention to warrant your attention. You will be able to combine your latching and mutex understanding with Oracle internal algorithms (for example, CBC operations) and proven methodologies to come up with creative, practical, and powerful solutions. So this chapter will become practical only when combined with a proven methodology and a solid understanding of Oracle internals. None of these three components used alone will produce an exceptional performance analysis.

And finally, don't let anyone tell you that once you've hit latching contention, you can't do anything more. As this book is beginning to reveal, there is a very diverse and practical set of solutions to each latch and mutex contention scenario.

1 Each Oracle table has an associated high water mark. Going from bottom (row one) to top, the high water mark points to the topmost block that has ever contained a row. When performing a full table scan, Oracle processes know never to scan above the high water mark-it just doesn't make sense to do so. The high water mark is stored in both Oracle's data dictionary and in the table's header block. If you do a block dump on a table's header block, the high water mark is very plainly shown.