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 -- //www.freelists.org/webpage/oracle-l