Re: row cache lock contention parallel insert

  • From: Greg Rahn <greg@xxxxxxxxxxxxxxxxxx>
  • To: LS Cheng <exriscer@xxxxxxxxx>
  • Date: Tue, 22 Dec 2009 07:30:49 -0800

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@xxxxxxxxx> 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
--
//www.freelists.org/webpage/oracle-l


Other related posts: