Pinning a cursor is similar to pinning a buffer. It is used to ensure the cursor is not deallocated (sometimes called destroyed) when being referenced. While cursors are clearly not relational structures, SQL is related to relational structures (for example, the employee table), and relational structures are used to build cursors (for example, sys.col$) and therefore locks-that is, enqueues are used! The cursor enqueue is called the CU enqueue and can be detected just like any other enqueue through Oracle's wait interface.

Pinning occurs whenever a cursor is created and executed. It makes sense when you think about it. When your build a cursor, which is a memory structure, you don't want another process is deallocate the associated memory! Normally, cursors are unpinned after being built and after execution. This means that after your session executes a cursor and then 2 minutes later wants to execute that same cursor again, it may have been deallocated. If this occurs, the cursor will not be found in the library cache, resulting in a hard parse, which is a complete cursor rebuild.

Locking also occurs when a cursor is built and executed. But the perspective is different than pinning. Pins are concerned with memory being deallocated. A lock ensures an Oracle table related to a cursor is not altered during cursor creation and execution. Obviously, that could create some rather strange situations, and Oracle will not allow this to occur.