Re: Cost of open_cursors parameter

>From my paper, hope this helps

7.F.vii OPEN_CURSORS parameter
OPEN_CURSORS helps to keep open cursors in a session. If you set PARALLEL_AUTOMATIC_TUNING to false, then Oracle also allocates parallel execution message buffers from the shared pool. Larger values improve performance in multi-user systems. Smaller values use less memory.
Specifies the maximum number of open cursors (handles to private SQL areas) each session can have at once. You can use this parameter to prevent a session from opening an excessive number of cursors. This parameter also constrains the size of the PL/SQL cursor cache which PL/SQL uses to avoid having to reparse as statements are reexecuted by a user.
If the limit is exceeded an ORA-01000 error is fired, and you should have to increase this parameter's value. This parameter can too be used in trigger cascading, when a statement in a trigger body causes another trigger to be fired, the triggers are said to be cascading. Oracle allows up to 32 triggers to cascade at any one time. However, you can effectively limit the number of trigger cascades using the initialization parameter OPEN_CURSORS, because a cursor must be opened for every execution of a trigger. Assuming that a session does not open the number of cursors specified by OPEN_CURSORS, there is no added overhead to setting this value higher than actually needed.
Cursors are allocated 64 at a time up to OPEN_CURSORS so having it set high is OK. The recommended value is between 0 and 10,000 open cursor will allocate an array in the session space (smallish). 200 would be fine for most. Reports, Forms, etc they all use a large number of cached cursors. 500-1000 (recommended 1000). OPEN_CURSORS simply allocates a fixed number of slots but does not allocate memory for these slots for a client (eg: it sets an array up to have 1,000 cursors for example but does not allocate 1,000 cursors).
The management of private SQL areas is the responsibility of the user process. The allocation and deallocation of private SQL areas depends largely on which application tool you are using, although the number of private SQL areas that a user process can allocate is always limited by the initialization parameter It is important to set the value of OPEN_CURSORS high enough to prevent your application from running out of open cursors. The number will vary from one application to another.
Applications should close unneeded cursors to conserve system memory. If a cursor cannot be opened due to a limit on the number of cursors

To take advantage of the additional memory available for shared SQL areas, you may also need to increase the number of cursors permitted per session. You can increase this limit by increasing the value of the initialization parameter OPEN_CURSORS. Be careful where you place a recursive call. If you place it inside a cursor FOR loop or between OPEN and CLOSE statements, another cursor is opened at each call. As a result, your program might exceed the limit set by the Oracle initialization parameter OPEN_CURSORS.

--
http://www.freelists.org/webpage/oracle-l