Most people don't think about this, but Oracle has an extremely response time-critical application. This application is managing the data dictionary! Just like an end-user application, Oracle's data dictionary is composed of tables, indexes, and sequences. This means locks must be used to ensure an inappropriate change does not occur. Just as application developers must make sure application locks are employed correctly, Oracle kernel code developers must ensure they appropriately lock their relational structures. If they mess this up, massive enqueue waits will be posted! Oracle gave the locks it uses special names that give us a clue about what operation is being performed. For example, a high water enqueue is related to Oracle adjusting the high water mark.1

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!