Re: Row cache lock wait issue in RAC
- From: "Radoulov, Dimitre" <cichomitiko@xxxxxxxxx>
- To: "Oracle Discussion List" <oracle-l@xxxxxxxxxxxxx>
- Date: Wed, 31 May 2006 22:54:40 +0200
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?
Just an idea: why don't you try to remove user's unlimited quota privilege
and assign a specific quota?
Regards
Dimitre
--
http://www.freelists.org/webpage/oracle-l
Other related posts:
- » Row cache lock wait issue in RAC
- » Re: Row cache lock wait issue in RAC
- » Re: Row cache lock wait issue in RAC
- » RE: Row cache lock wait issue in RAC
- » Re: Row cache lock wait issue in RAC
- » Re: Row cache lock wait issue in RAC
- » RE: Row cache lock wait issue in RAC
- » Re: Row cache lock wait issue in RAC
- » Re: Row cache lock wait issue in RAC
- » Re: Row cache lock wait issue in RAC
- » RE: Row cache lock wait issue in RAC
- » 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?