When DBAs think of enqueues, they typically think of data dictionary issues, but enqueue waits are related to both application lock issues and data dictionary lock issues. In releases before Oracle Database 10g, the wait event was simply enqueue wait, and we needed to look in the v$session_wait view to determine the actual enqueue. But starting with Oracle Database 10g, the actual enqueue is part of the wait event name. For example, the wait event name could be enq TX - row lock contention. You can tell the enqueue is related to an Oracle data dictionary object or an application object by the enqueue type. For example, the high water enqueue (HW) or the space transaction enqueue (ST) are specifically related to an object's high water mark being updated and dictionary-based free space management, respectively. As DBAs or application developers, we can't directly control or manage high water mark settings or dictionary free space-that's Oracle's responsibility. But other enqueues like application table and row locks are well within application developer control.

Enqueues are relatively expensive, because order must be maintained at all times. Just as the name implies, requests for access must be enqueued and dequeued. To make matters worse, there are various locking degrees, such as exclusive, shared, share for update, and so on. While the time required to manage enqueues is deemed acceptable for managing relational objects, for managing memory structures, it simply takes too long. So another strategy is needed, and that's where latches and mutexes get involved!

Latches and mutexes are deeply involved with memory structure control. In fact, they are both small memory structures themselves! Memory structure access must be exceptionally quick. For example, perhaps a server process wants to know if a single block is in the buffer cache. If a SQL statement must touch 5,000 blocks, and each time the question, "Is the block in the buffer cache?" is asked, which takes 1 ms, it will take 5,000 ms (5 seconds) just to determine if the blocks are in Oracle's cache! This time does not include actually accessing the buffers, asking the operating system for the blocks if they are not in the cache, and other cache management requirements (discussed in Chapters 6, 7, and 8). So, every millisecond counts with memory access. Oracle goes to great lengths to reduce the number of times a latch or mutex is requested, and also in optimizing the code so that once a latch or mutex is acquired, it's not held long.