]
> Sent: Friday, January 31, 2003 9:25 AM
> To: Multiple recipients of list ORACLE-L
> Subject: RE: Excessive library cache latch contention
>
>
> Jonathan,
>
> I think you've got a point on all three counts. I am seeing
> an imbalance of
--
Please see the
Just to clarify...
If you upload something to our site, and you haven't purchased a license
to run the Hotsos Profiler, then make sure you send a note to
[EMAIL PROTECTED], letting him know that you're interested in
seeing a demo profile of your data.
We're glad to do demos of our software, espec
Correction on this ... I should have said
www.hotsos.com would have some additional
insights on dealing with 10046 data for you
if you are interested.
-Original Message-
Sent: Friday, January 31, 2003 10:57 AM
To: Multiple recipients of list ORACLE-L
Harvey,
Personally, I would go righ
Harvey,
Personally, I would go right to the user(s) who has complained
about the slowdown and have them run the application at the peak
hour/period where things seem very slow.
Set a 10046 event level 8 trace on that session(s) after they
log on and then take a look at the trace file in
the udump
After I posted this, I thought I should elaborate:
This seems to work sometimes; but we also had some problems with it and
opened a TAR. We were told there is an unspecified bug associated with it.
I guess the conclusion is: Try it. Maybe it will work; maybe not.
> -Original Message-
>
I don't know about 9, but I am pretty sure that in 8, this "feature" is
broken.
> -Original Message-
> cursor_sharing=FORCE may be an option,
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Stephen Lee
INET: [EMAIL PROTECTED]
Fat City Network Services--
Jonathan,
I think you've got a point on all three counts. I am seeing an imbalance of
gets / misses and sleeps on one of the latch children, and it does get worse
when the CPU's are being hammered.
Public synonyms could be an issue in certain areas of the application but
not all, though that shou
The 'objects on hot latches' is likely to help
only if there is a significant imbalance in the
latch activity on the latch children (as you probably
know).
The fact that 'waits holding' is rather high
may be a hint. The most likely latches that
you would be holding whilst waiting for the
library
Neil,
Does this application use a lot of literal SQL?
Do the users tend to use the same Appl processes during the peak times?
And do they really complain about poor performance during the peak times?
The contention could be due to the excessive parsing. Since you are noticing this at
al
I've got access to Metalink and the doco you mentioned, but its too generic.
Its a forms application, but the developers are generating dynamic where
clauses on blocks, as well as the standard block.item notation in
predicates, so there is a degree of literal SQL in the mix, and multiple
versions
We've got about 30 sites all running the same application, and I'm
consistently seeing large numbers of 106 (library cache) latch free waits.
They tend to happen at peak times during the day, and in the worst case I
saw 12 sessions all on a 106 latch free wait event, spread across 3 P1RAW
addresses
11 matches
Mail list logo
