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.