RE: row cache lock contention parallel insert
- From: "Mark W. Farnham" <mwf@xxxxxxxx>
- To: <exriscer@xxxxxxxxx>, "'Greg Rahn'" <greg@xxxxxxxxxxxxxxxxxx>
- Date: Wed, 23 Dec 2009 07:10:45 -0500
So how much dynamic extension is going on? Is this the bug where when one
thread needs to allocate an extent all the parallel inserters to the same
object pile up and also add an extent?
So, if you count the number of extents on all the objects getting inserted
into at 00:04:59 of your 5 minute cycle (presuming the previous cycle
finished without exhausting the time slice), and you do it again when the
work for the 5 minute period is over, are we routinely talking about a lot
of extents being added or not?
When you say 10 application processes but with 64 slaves, is that 64 total
or 640 total? What is your runqueue or the equivalent for whatever OS you're
on?
End of diagnostic data questions.
Random suggestion leading question: What is driving the five minute window?
Is this controlled such that a set of processes does not start on the five
minute boundary if the previous set has not finished? What sort of input is
being consumed by the insert jobs? Are the three tables the input or the
destination. If input, are they new sets of input or rows added to
previously processed data? Is there a way to stagger the starts
productively?
mwf
_____
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of LS Cheng
Sent: Wednesday, December 23, 2009 3:46 AM
To: Greg Rahn
Cc: info@xxxxxxxxxxxxxxxxxxxxx; oracle-l@xxxxxxxxxxxxx
Subject: Re: row cache lock contention parallel insert
Hi
Thanks for the info
The workload is more or less every 5 minutes 10 data load processes kicks
in, 3 of them needs to load around 12 million of rows each (going through
ETL which are 3 tables per process), the rest from 300000 to 3 million.
All insert append with parallel dml and PQ for the SELECT (insert...select).
Basically there is only 10 application processes but with 64 slaves running
almost all the time. All ETL Tables has more or less 4000 to 5000
subpartitions
I noticed also compatible is set to 10.2.0.1 instead of 10.2.0.4, might be
some old bug? Probably because when I was doing test with a test database,
also 10.2.0.4 with compatible set to 10.2.0.3 I managed to reproduce massive
row cache contention, when I changed compatible to 10.2.0.4 row cache
requests reduced by a factor of 10. I will change compatible to 10.2.0.4
after holidays because they dont allow anymore system changes until then
Thanks!
--
LSC
On Tue, Dec 22, 2009 at 4:30 PM, Greg Rahn <greg@xxxxxxxxxxxxxxxxxx> wrote:
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
Other related posts:
