Since cursors and programmatic structures reside in the library cache, there is a structure to locate the objects. Oracle chose to use a hashing algorithm and the related hash-like structure. Part of parsing is determining if a cursor currently resides in the library cache. If the cursor is indeed found in the library cache, some parsing did occur, so it's deemed a soft parse. However, if the cursor was not found, the entire cursor must be built, so this is deemed a hard parse. As I mentioned earlier, cursor creation, and therefore hard parsing, results in a relatively expensive operation.

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.