Cursors are built from data in the shared pool. And if the data is not currently in the shared pool, Oracle creates its own SQL to retrieve the data from the data dictionary tables. Recursive SQL is the name given to the SQL Oracle dynamically creates and runs itself. Some of the data Oracle needs to create a cursor is optimizer statistics, session information, security information, object information, and object relationship information. Books could be written simply about cursor creation.

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.