We have noticed that the Gen Build Tool uses different Oracle pre-compiler options for UNIX vs Windows. Here are the default options:
Windows:
SQLCHECK=SYNTAX MODE=ANSI IRECLEN=255 ORECLEN=255 LTYPE=NONE
UNIX:
IRECLEN=511 ORECLEN=511 CODE=ANSI_C LTYPE=NONE MODE=ANSI DBMS=V7
SQLCHECK=SYNTAX PARSE=NONE RELEASE_CURSOR=NO HOLD_CURSOR=YES
We are not sure why RELEASE_CURSOR=NO and HOLD_CURSOR=YES are not set for Windows. We have experimented with setting these for Windows and have noticed a significant performance improvement.
2 comments:
Hi,
Maybe the info on this link
http://mail-archives.apache.org/mod_mbox/activemq-users/200805.mbox/%3C17053893.post@talk.nabble.com%3E
helps:
2. Tuning at the APPLICATION LEVEL
>
> 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 Version 1.6 p.6-16.
>
> 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 Version 1.6
> p.6-26.
>
> These two parameters must be used in conjunction for them to be effective.
> Here is a table that shows how settings of the two parameters interact.
>
> ----------------------------------------------------
> |HOLD_CURSOR | RELEASE_CURSOR | LINKS ARE... |
> ----------------------------------------------------
> | NO | not applicable | marked as reusable |
> | YES | NO | maintained |
> | NO | YES | removed immediately|
> | n/a | YES | removed immediately|
> ----------------------------------------------------
>
> 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.
>
but, does it make any sense on a window build level?
We use Windows Oracle servers, so this does make sense for us.
Post a Comment