This latch comes into play when user processes are attempting to access or update the cached data dictionary values.
Solutions
Problem:
To determine if the row cache is being used efficiently, execute the following SQL. If the ratio is not close to 1 then some tuning required.
SELECT parameter, sum(gets), sum(getmisses),
100*sum(gets – getmisses) / sum(gets) pct_succ_gets,
sum(modifications) updates
FROM V$ROWCACHE
WHERE gets > 0
GROUP BY parameter;
Options for tuning row cache are so limited that some resources call it non-tunable. However if the value of the column pct_succ_gets in the above query is
not close to “1″ or if Ignite for Oracle shows significant waits for the “Row Cache Objects” latch, then consider increasing SHARED_POOL_SIZE.
Another way to adjust the dictionary cache is to increase the library cache. Since the dictionary cache is a part of the library cache, the increase will
indirectly increase the dictionary cache. Also, consider the following:
Using Locally Managed tablespaces for application objects, especially indexes, may decrease Row Cache locks.
Review and amend database logical design. For example, try to decrease the number of indexes on tables with frequent inserts
这个latch出现当用户进程试图访问或修改cached数据字典值,要减少对数据字典的访问和修改
解决办法:
SQL> SELECT parameter, sum(gets), sum(getmisses),
100*sum(gets - getmisses) / sum(gets) pct_succ_gets,
sum(modifications) updates
FROM V$ROWCACHE
WHERE gets > 0
GROUP BY parameter; 2 3 4 5 6
PARAMETER SUM(GETS) SUM(GETMISSES) PCT_SUCC_GETS UPDATES
-------------------------------- ---------- -------------- ------------- ----------
dc_constraints 7530 6075
sch_lj_oids 22350 77.5784753 0
dc_tablespaces 64543467 99.9896194 0
dc_awr_control 250713 99.4814519 74
dc_object_grants 12861 1269 90.1329601 0
dc_histogram_data 187398 20174 89.234677 1972
dc_rollback_segments 3071821 99.9316362 31
dc_sequences 224 166 25.8928571 224
sch_lj_objs 187 61.1111111 0
dc_segments 80661 11209 86.1035693 1397
dc_objects 316511 14349 95.4665083 731
PARAMETER SUM(GETS) SUM(GETMISSES) PCT_SUCC_GETS UPDATES
-------------------------------- ---------- -------------- ------------- ----------
dc_histogram_defs 310809 87836 71.7395571 2418
dc_table_scns 1313 0 0
dc_users 982961 1282 99.8695777 23
outstanding_alerts 108992 91.5518825 2
dc_files 41 21 48.7804878 6
dc_global_oids 4977 474 90.4761905 0
dc_profiles 55248 99.8551774 0
global database name 921494 99.9956592 0
已选择19行。
调优row cache方法是有限的,有些资源甚至不可调整,如果上面的查询column pct_succ_gets的值不接近于100%,
否则就会促发“Row Cache Objects” latch。然后试着增加SHARED_POOL_SIZE,间接的也增加了dictionary cache。
行高速缓存调整非常有限,最佳的解决方法是根据v$rowcache中输出减少字典访问。例如,如果序列是问题所在,那么就考虑高速缓存序列。
DC_SEQUENCES
Check for appropriate caching of sequences for the application requirements.
DC_USERS
Deadlock and resulting “WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK!” can occur if a session issues a GRANT to a user, and that user is in the process of
logging on to the database.
DC_SEGMENTS
This is likely to be down to segment allocation. Identify what the session holding the enqueue is doing and use errorstacks to diagnose.
DB_ROLLBACK_SEGMENTS
This is due to rollback segment allocation. Just like dc_segments,identify what is holding the enqueue and also generate errorstacks. Remember that on a
multi-node system (RAC) the holder may be on another node and so multiple systemstates from each node will be required.
DC_AWR_CONTROL
This enqueue is related to control of the Automatic Workload Repository. As such any operation manipulating the repository may hold this so look for
processes blocking these.