Like each buffer in the buffer cache, each parent and child cursor must be locatable, and that search must be fast! This requires memory, a searching structure, serialization, kernel code, and plenty of CPU resources.

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.