Cursors are created out of chunks of shared pool memory called heaps. Traditionally, different SQL statements required different size memory chunks. Common SQL statements have traditionally required 4KB memory chunks. Just as with free extent management, having nonuniform memory chunk requirements creates allocation, performance, and efficiency issues. Starting in Oracle Database 10g Release 2, Oracle states all memory chunks are 4KB. When the appropriate memory chunk cannot be quickly found, Oracle eventually gives up, posts a 4031 "out of shared pool memory" error, and stops the SQL statement processing. Ouch!

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.