Re: row cache lock contention parallel insert
From: Greg Rahn <greg_at_structureddata.org>
Date: Mon, 21 Dec 2009 13:17:24 -0800
Message-ID: <a9c093440912211317s3ff93764sdc47677d22d5a9c8_at_mail.gmail.com>
On Mon, Dec 21, 2009 at 11:34 AM, Randolf Geist <info_at_sqltools-plusplus.org> wrote:
> Still it is interesting that using the explicit partition pruning syntax changes the outcome of your test case.
Date: Mon, 21 Dec 2009 13:17:24 -0800
Message-ID: <a9c093440912211317s3ff93764sdc47677d22d5a9c8_at_mail.gmail.com>
On Mon, Dec 21, 2009 at 11:34 AM, Randolf Geist <info_at_sqltools-plusplus.org> wrote:
> Still it is interesting that using the explicit partition pruning syntax changes the outcome of your test case.
Using partition extended syntax reduces the locks and metadata required, so the issue seems to point in that direction, not extent allocation, etc. If it were the latter, it would reproduce in both cases.
There should be some dictionary query on a $ table (like SEG$, TSQ$, etc) that shows up, I would think, in the ASH/AWR report. Finding that SQL might make it more apparent what the issue may be.
-- Regards, Greg Rahn http://structureddata.org -- http://www.freelists.org/webpage/oracle-lReceived on Mon Dec 21 2009 - 15:17:24 CST