RE: Row cache lock wait issue in RAC

Hi Dimitre,

I haven't tried yet to use separate tablespaces, it looks like a good solution although a bit unpractical for my system (without reengineering), because I would end up with a very large number of tablespaces in a
short time.

As for you previous suggestion of assigning a fixed quota to the user, I didn't mention it in my mail but we had tried it without success.

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'.

Thanks,
L.

-----Original Message-----
From: Radoulov, Dimitre [mailto:cichomitiko_at_gmail.com] Sent: Thursday, June 01, 2006 9:10 AM
To: Luca Canali
Cc: oracle-l_at_freelists.org
Subject: Re: Row cache lock wait issue in RAC

>I am stress testing an application that performs massive inserts (logs

>tons of data) into Oracle tables using direct path insert. Multiple
>tables are used to provide scalability (each log source inserts into a

>dedicated table). This application uses direct path inserts and
>bypasses the cache so I can see that it also scales in RAC (10g RAC, 6
nodes).
>
> BUT increasing the number of log sources I have now started to see the

> following bottleneck: row cache wait (on dc_tablespace_quotas), for
> example from a 10046 trace:
> ---------------------------
> WAIT #19: nam='row cache lock' ela= 2888862 cache id=5 mode=0
> request=5
> obj#=76647 tim=1122164147766228
> WAIT #19: nam='row cache lock' ela= 2824967 cache id=5 mode=0
> request=5
> obj#=76647 tim=1122164150591291
>
> It looks to me as row cache lock contention between direct path
> inserts, probably made worse by rac/GES. (Note also that I don't
> enforce tablespace quotas (the application owner has unlimited
tablespace).
>
> Any ideas on how to tune this?

You can also try to put the tables in different tablespaces.

Regards
Dimitre

--
http://www.freelists.org/webpage/oracle-l