The cursor is a fundamental object that is a complete executable representation of a SQL statement or a PL/SQL programmatic construct, which can be used and reused by any authorized session. Cursors must be created, locatable (that is, found by a search), destroyed (deallocated), invalidated, and reloaded. If any part of the cursor is not in the shared pool and is needed for any reason, that aspect must be reloaded, which does slow performance.

Developers typically have a good understanding of cursors because they have needed to specifically create, open, execute, fetch, and close cursors. DBAs commonly look at cursors as simply memory chunks related to SQL. However, this simplistic view inhibits our ability to create solutions to cursor-related performance problems. So, if you take the time to better understand cursors, you'll notice your performance solution options will significant increase.

The term cursor is in itself an abstraction and is used to refer to shared information (located in a shared SQL area), private information (located in a session's PGA), and the library cache chain node (called a handle when referring to the library cache) used to locate the various cursor components. Unfortunately, this multipurpose definition also adds to the confusion.