One of those things that needs to be worried in RAC environment...
Noticed this event "row cache lock" the other day in our database on a simple insert. SQL is mostly showing waits on this even with so much of wait time.
Digging more, found that there was a sequence which "cache" size was not optimized for RAC environment. It has 20 as cache size. Increased to 20000 and this event disappears...
Finding the issue:
Run the following sql to find the CacheID:
select p1text,p1,p2text,p2,p3text,p3
from gv$session
where event = 'row cache lock';
Use the above returned CacheID in the below sql to find the Enqueue type:
select parameter ,count ,gets ,getmisses ,modifications
from gv$rowcache
where cache#=13;
This shows me it is dc_sequences.
Now, find the SEQuence which is being used in the SQL and check the cache size and change it.
alter sequence your_sequence
increment by 1
minvalue 1
maxvalue 999999999999999999999999999
cache 20000
nocycle
noorder;
Noticed this event "row cache lock" the other day in our database on a simple insert. SQL is mostly showing waits on this even with so much of wait time.
Digging more, found that there was a sequence which "cache" size was not optimized for RAC environment. It has 20 as cache size. Increased to 20000 and this event disappears...
Finding the issue:
Run the following sql to find the CacheID:
select p1text,p1,p2text,p2,p3text,p3
from gv$session
where event = 'row cache lock';
Use the above returned CacheID in the below sql to find the Enqueue type:
select parameter ,count ,gets ,getmisses ,modifications
from gv$rowcache
where cache#=13;
This shows me it is dc_sequences.
Now, find the SEQuence which is being used in the SQL and check the cache size and change it.
alter sequence your_sequence
increment by 1
minvalue 1
maxvalue 999999999999999999999999999
cache 20000
nocycle
noorder;
No comments:
Post a Comment