Looks like an SR is your only way out for now ...
I am using Oracle 10.2.0.2 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 > > -- > http://www.freelists.org/webpage/oracle-l > > >