Locks prevent an inappropriate change from occurring. When an Oracle process is waiting for a lock, it posts an enqueue wait. I like to say using enqueues is very mature and boring because they are orderly, structured, and just not a lot of fun. (You'll see that latches are just the opposite.)

The two broad locking areas are application locks and data dictionary locks. Locking the employee table is an application lock example. Application locks are under the control of application developers. They write the code to issue the locks. On the other hand, data dictionary locks are under the control of Oracle kernel code developers.

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