Re: row cache lock contention parallel insert
From: Greg Rahn <greg_at_structureddata.org>
Date: Tue, 22 Dec 2009 07:30:49 -0800
Message-ID: <a9c093440912220730s68904117l394044b400555b9_at_mail.gmail.com>
That query is used for the row cache read call back for SEG$ when the segment entry is not available in the row cache. Once the row cache entry is available, all the reads should go through row cache rather than from disk. It seems that something may be wrong with the row cache layer.
Date: Tue, 22 Dec 2009 07:30:49 -0800
Message-ID: <a9c093440912220730s68904117l394044b400555b9_at_mail.gmail.com>
That query is used for the row cache read call back for SEG$ when the segment entry is not available in the row cache. Once the row cache entry is available, all the reads should go through row cache rather than from disk. It seems that something may be wrong with the row cache layer.
Can you describe the workload?
What are the other top SQLs?
On Mon, Dec 21, 2009 at 3:47 PM, LS Cheng <exriscer_at_gmail.com> wrote:
> Yes there are many executions on this two query:
>
> 2ym6hhaq30r73 - around 11 millions executions per hour
> SELECT type#, blocks, extents, minexts, maxexts, extsize, extpct, user#,
> iniexts, NVL (lists, 65535), NVL (GROUPS, 65535), cachehint, hwmincr,
> NVL (spare1, 0), NVL (scanhint, 0)
> FROM seg$
> WHERE ts# = :1 AND file# = :2 AND block# = :3
-- Regards, Greg Rahn http://structureddata.org -- http://www.freelists.org/webpage/oracle-lReceived on Tue Dec 22 2009 - 09:30:49 CST