Pinning ensures a specific memory structure is not deallocated, removed, or destroyed. For example, if a process is accessing an Oracle block buffer, obviously the process would not want the buffer replaced by some other buffer. To prevent this from occurring, the accessing process pins the buffer. Kernel developers perform the pin, not DBAs. While DBAs can cache tables and keep programmatic structures in the library cache, Oracle kernel developers issue an underlying pin of a buffer or a cursor.

Latches and mutexes can be used to pin a memory structure. Every mutex has a variable called the reference count. It contains the number of processes that are currently referencing the mutex (in shared mode). Oracle uses the reference count to determine if an object is being pinned. If the reference count is greater than zero, Oracle knows the object is pinned and cannot be deallocated. When an object is being pinned, the corresponding mutex's reference count is incremented by one. When the object is unpinned, the reference count is reduced by one. As long as the reference count is greater than zero or the mutex is being exclusively held, every Oracle process knows the memory structure is being referenced by some process, and therefore it cannot be deallocated.

As you might expect, mutexes are expected to perform the pinning operation much more quickly than latches can do pinning. A quick test showed mutex pinning is significantly faster than latch pinning. For this test, a simple Oracle Database 10g Release 2 one-table SQL statement cursor was repeatedly opened and closed 500,000 times in a very tight PL/SQL loop by a single session. The database server contained a single four-core CPU. This test was repeated 30 times and the wall clock time recorded. The hidden instance parameter _kks_use_mutex_pin (a setting of true enables mutexes when supported) determined if mutexes were used instead of library cache latches.