Re: Row cache lock wait issue in RAC

  • From: "Anand Rao" <panandrao@xxxxxxxxx>
  • To: "Luca Canali" <Luca.Canali@xxxxxxx>
  • Date: Thu, 1 Jun 2006 15:11:06 +0530

Looks like an SR is your only way out for now ...


On 01/06/06, Luca Canali <Luca.Canali@xxxxxxx> wrote:

Hi Anand,

I am using Oracle with RAC (6 nodes ) + ASM on RHEL 3. I use LMT
bigfile tablespaces and ASSM. I am aware of the exchange partition bug, but
my case looks different: I don't seem to have any deadlocks and using the
workaround you mention (fixed quotas) did not help.


------------------------------ *From:* Anand Rao [mailto:panandrao@xxxxxxxxx] *Sent:* Thursday, June 01, 2006 11:15 AM

*To:* Luca Canali
*Cc:* oracle-l@xxxxxxxxxxxxx
*Subject:* Re: Row cache lock wait issue in RAC


In LMT, Oracle acquired a row cache enqueue on dc_tablespace_quotas after
a segment is built. this could even be a partition exchange or add. In DMT,
it used to be worse, where Oracle acquired this enqueue to check quotas and
add extents.

The quota checks are still performed but only at the end, even though you
may have provided unlimited quota. i think Dimitre's suggestion to provide
fixed quota came from this aspect. so, we both assume you are using LMT :)

also, are you using partitions and dynamically exchanging data to
partitions? if so, run the EXCHANGE PARTITION statements serially and ensure
it involves a single tablespace.

one bug hit suggested providing the quotas in M or K instead of bytes,
especially if the quota is more than 4GB.

unfortunately, you are hitting a couple of bugs related to this enqueue
especially while Oracle updates TSQ$ table...problem occuring mainly in high
insert RAC environments.

you didn't mention the version. depending on yours, you can get a backport
fix. some fixes are available in 10.1...but there are a couple of bugs in
10.1 too :(

hope that helps


On 01/06/06, Radoulov, Dimitre <cichomitiko@xxxxxxxxx> wrote:
> > By the way, I would be quite interested to know why oracle needs to
> > acquire row cache lock on dc_tablespace_quotas in this case and if
> there
> > is any way to skip this operation with 'a clever hack'.
> If you search on MetaLink with keyword "dc_tablespace_quotas" (with bug
> database search enabled), there are a few bugs related to data
> dictionary
> cache deadlocks.
> Regards
> Dimitre
> --

Other related posts: