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.
本文转自maclean_007 51CTO博客，原文链接:http://blog.51cto.com/maclean/1277935
