There are three parameters that affect handling cursors at the application level: RELEASE_CURSOR, HOLD_CURSOR, MAXOPENCURSORS. You should set these parameters at the precompiler level.
HOLD_CURSOR by default is NO. This means that after Oracle executes a SQL statement the links to the cursor cache, memory, and parse locks are released and marked for reuse. For more details refer to Programmer's Guide to Precompilers.
RELEASE_CURSOR by default is NO. This means that after Oracle executes a SQL statement, the links to the cursor cache is maintained and not released. For more information, refer to Programmer's Guide to Precompilers.
The maximum number of open cursors per user session is set by the Oracle initialization parameter OPEN_CURSORS.
MAXOPENCURSORS specifies the initial size of the cursor cache. If a new cursor is needed and there are no free cache entries, Oracle tries to reuse an entry. Its success depends on the values of HOLD_CURSOR and RELEASE_CURSOR and, for explicit cursors, on the status of the cursor itself.
If the value of MAXOPENCURSORS is less than the number of cache entries actually needed, Oracle uses the first cache entry marked as reusable. For example, suppose the cache entry E(1) for an INSERT statement is marked as reusable, and the number of cache entries already equals MAXOPENCURSORS. If the program executes a new statement, cache entry E(1) and its private SQL area might be reassigned to the new statement. To re-execute the INSERT statement, Oracle would have to reparse it and reassign another cache entry.
Oracle allocates an additional cache entry if it cannot find one to reuse. For example, if MAXOPENCURSORS=8 and all eight entries are active, a ninth is created. If necessary, Oracle keeps allocating additional cache entries until it runs out of memory or reaches the limit set by OPEN_CURSORS. This dynamic allocation adds to processing overhead.
Thus, specifying a low value for MAXOPENCURSORS saves memory but causes potentially expensive dynamic allocations and deallocations of new cache entries. Specifying a high value for MAXOPENCURSORS assures speedy execution but uses more memory.
To resolve the ORA-01000 error, you should set HOLD_CURSOR=NO and
RELEASE_CURSOR=YES. This way, after the cursors are used, Oracle will free up the memory for other cursors.
Consequences of setting these parameters HOLD_CURSOR=NO and RELEASE_CURSOR=YES:
This will cause Oracle to release the links and locks for each cursor after the SQL statement is executed. This means that the next time Oracle needs to issue the same SQL statement, Oracle will have to reparse the statement, and rebuild the execution plan. This will cause some performance overhead.
MAXOPENCURSORS by default is 10. This number indicates the concurrent number of open cursors that the precompiler tries to keep cached. It specifies the initial size of the cursor cache. The limit of this parameter is determined by what you set OPEN_CURSORS to. Here is the formula:
MAXOPENCURSORS + 6 <= OPEN_CURSORS
6 is the overhead cursors Oracle needs.