The session is not experiencing any waits during these executions, so
this is not the case. The queries are also SELECTs and not UPDATEs or
SELECT FOR UPDATEs.
Daniel
solbeach@(protected) wrote:
> I had a similar issue a couple of months ago.
> My problem was that a few "popular " tables,
> which are regularly updated/accessed by most of the
> application had INITRANS too low & sessions were going into
> ENQUEUE wait state.
>
> Run this simple SQL the next time a "slowdown " occurs...
>
> SELECT DECODE(request,0, 'Holder: ', 'Waiter: ')||sid sess,
> id1, id2, lmode, request, type
> FROM V$LOCK
> WHERE (id1, id2, type) IN
> (SELECT id1, id2, type FROM V$LOCK WHERE request >0)
> ORDER BY id1, request
> /
>
> We had folks to started an UPDATE (got a lock)
> and then literally went to lunch to 90 minutes!
> Other sessions would hang quietly waiting for the resource.
>
> HTH & YMMV!
>
> -- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ------
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> -- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ------
> To unsubscribe send email to: oracle-l-request@(protected)
> put 'unsubscribe ' in the subject line.
> --
> Archives are at http://www.freelists.org/archives/oracle-l/
> FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
> -- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- --
-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ------
To unsubscribe send email to: oracle-l-request@(protected)
put 'unsubscribe ' in the subject line.
--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- --
