
|
[oracle-l]
||
[Date Prev]
[06-2006 Date Index]
[Date Next]
||
[Thread Prev]
[06-2006 Thread Index]
[Thread Next]
RE: Row cache lock wait issue in RAC
- From: "Luca Canali" <Luca.Canali@xxxxxxx>
- To: "Radoulov, Dimitre" <cichomitiko@xxxxxxxxx>
- Date: Thu, 1 Jun 2006 09:56:26 +0200
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@xxxxxxxxx]
Sent: Thursday, June 01, 2006 9:10 AM
To: Luca Canali
Cc: oracle-l@xxxxxxxxxxxxx
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
|

|