Rules for Closing Cursors
Oracle versions 7-8
Oracle cursors are constructed during hard parsing. They are memory structures in the cursor cache of the shared pool in the SGA. They include references to the SQL statements associated with them and the data most recently fetched, which is stored in the PGA, and a context area that provides other information. To close a cursor is to release the memory, which among other things loses the connection between the cursor and its SQL statement. A cursor re-opened after closing will have to have its SQL statement hard-parsed again, just as if the statement had never been submitted.
It is also true that a cursor allocated for a user process will not necessarily be cleaned up automatically, because the rules for cursor garbage collection are subtle and change with different Oracle versions. Cursor garbage collection may not happen if the routine that allocated the cursor was not top-level, because Oracle waits for the top-level routine to exit before rescuing cursor cache space allocated at lower levels in the call stack. Garbage collection probably won't happen if the user process has terminated unexpectedly without disconnecting from the Oracle instance, because in that case the instance does not know that it can clean up the cursor. Garbage collection is supposed to happen for a normal disconnection, but not all database-connection drivers have been cleanly coded. So a program that opens cursors and exits without closing them may cause a "cursor leak," in which unused cursors remain open indefinitely. A cursor leak raises the risk of incurring ORA-01000, "maximum open cursors exceeded."
It is important to keep cursors open for as long as they are used, without opening and closing them repeatedly in a loop. It's also important to close them as soon as the program logic is done with them.