A few years ago, a separate chapter section on latching would not have made sense. But in Oracle 10g Release 2, mutexes were introduced to complement latches. Although latches and mutexes serve the same purpose, they are different enough to warrant their own section. But don't forget that latches are not an Oracle invention. Oracle has numerous patents and also acquires know-how by acquiring other companies. But like other database vendors, Oracle uses the term latch to describe a memory control structure.

It's pretty straightforward how a single latch can be used to control serial access to a memory structure. But, as we all know will eventually occur, when multiple processes need to access the same memory structure, contention results. As the term serial execution implies, one, and only one, process can hold the latch at any given time. This means that significant contention for the latch is very possible. Once again, our need to increase performance draws us toward parallelism. In simplistic terms, this requires multiple latches (sometimes called child latches). And once two latches exist, we also must have a facility to ensure that the two latch holders are not corrupting Oracle's memory structures.

One solution is have a master latch coordinating and controlling many slave latches, but that would mean additional kernel code for coordination. Time spent on latch acquisition is not for actually accessing the underlying memory structure, but rather for gaining the authorization to do so. It is a sad situation indeed when the performance issue resides in the acquisition process itself, not the memory structure access. Using a master/slave latching architecture could easily result in too much time spent acquiring a latch.