Latches are like semaphores.
Latches are used to guarantee physical consistency of data, while locks are used to assure logical consistency of data.
Latches are simple, low-level system lock (serialization mechanisms) that coordinate multi-user access (concurrency) to shared data structures, objects, and files.
Latches protect shared memory resources from corruption when accessed by multiple processes. Specifically, latches protect data structures from the following situations:
Typically, a single latch protects multiple objects in the SGA.
The implementation of latches is operating system-dependent, especially in respect to whether and how long a process waits for a latch.
As an auxiliary to locks, lighter-weight latches are also provided for mutual exclusion. Latches are more akin to monitors or semaphores than locks; they are used to provide exclusive access to internal data structures.
As an example in a database, the buffer pool page table has a latch associated with each frame, to guarantee that only one DBMS thread is replacing a given frame at any time. Latches are used in the implementation of locks and to briefly stabilize internal data structures potentially being concurrently modified.
Latches differ from locks in a number of ways:
Background processes such as DBWn and LGWR allocate memory from the shared pool to create data structures. To allocate this memory, these processes use a shared pool latch that serializes access to prevent two processes from trying to inspect or modify the shared pool simultaneously. After the memory is allocated, other processes may need to access shared pool areas such as the library cache, which is required for parsing. In this case, processes latch only the library cache, not the entire shared pool.
An increase in latching means a decrease in concurrency. For example, excessive hard parse operations create contention for the library cache latch.
Latches are a type of lightweight lock. Locks are serialization devices. Serialization devices inhibit concurrency.
To build applications that have the potential to scale, ones that can service 1 user as well as 1,000 or 10,000 users, the less latching we incur in our approaches, the better off will be.
You have to choose always an approach that takes longer to run on the wall clock but that uses 10 percent of the latches. We know that the approach that uses fewer latches will scale substantially better than the approach that uses more latches.
Latch contention increases statement execution time and decreases concurrency.
Unlike enqueue latches such as row locks, latches do not permit sessions to queue. When a latch becomes available, the first session to request the latch obtains exclusive access to it.
Typically, an Oracle process acquires a latch for an extremely short time while manipulating or looking at a data structure. For example, while processing a salary update of a single employee, the database may obtain and release thousands of latches.