Re: how 8.1.7.4 calculates the # of 'library cache' latch children ?

"Alberto Dell'Era" <alberto.dellera_at_bigfoot.com> wrote in message news:f4ed41c5.0311260454.429e0e6c_at_posting.google.com <snipe>

> Already tried, unfortunately that "fine" application has invented a
> new type of cursor-sharing-resistant sql statement, i.e.
>
> select ... from t t123 where ...;
> select ... from t t124 where ...;
> select ... from t t125 where ...;
> select ... from t t126 where ...;
>
> Where the alias t<number> changes at every parse (!!)
> The purpose if that alias is unknown, anyway it sabotages the instance
> nicely (100% of active sessions waiting on 'latch free', where the
> latches waited for are the parsing-related 'shared pool','library
> cache','row cache objects' and 'latch wait list'). Upping the library
> cache latches from 11 to 17 has brought some relief - until the next
> traffic spike, obviously.
>
> Thank you for your time!
> Alberto

<snipe>

Hi,
Is the third party application is using Rougewave libraries? It is the default behaviour for Rougewave !! We faced this problem. The only option is to change the source. Details can be found at

http://www.roguewave.com/support/private/ts/viewsrchdoc.cfm?issn=980812-001

Thanks,
Saikat Chakraborty
http://saikatchak.tripod.com

-- 
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG