Row Cache Objects

This latch comes into play when user processes are attempting to access or update the cached data dictionary values.SolutionsProblem: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) updatesFROM V$ROWCACHEWHERE gets > 0GROUP 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) updatesFROM V$ROWCACHEWHERE gets > 0GROUP BY parameter;  2    3    4    5    6  PARAMETER  SUM(GETS) SUM(GETMISSES) PCT_SUCC_GETS    UPDATES-------------------------------- ---------- -------------- ------------- ----------dc_constraints 7530      6075sch_lj_oids 22350    77.5784753  0dc_tablespaces     64543467    99.9896194  0dc_awr_control       250713    99.4814519 74dc_object_grants      12861     1269    90.1329601  0dc_histogram_data     187398    20174     89.234677       1972dc_rollback_segments      3071821    99.9316362 31dc_sequences 224      166    25.8928571 224sch_lj_objs 187    61.1111111  0dc_segments      80661    11209    86.1035693       1397dc_objects     316511    14349    95.4665083 731PARAMETER  SUM(GETS) SUM(GETMISSES) PCT_SUCC_GETS    UPDATES-------------------------------- ---------- -------------- ------------- ----------dc_histogram_defs     310809    87836    71.7395571       2418dc_table_scns 1313       0 0dc_users     982961     1282    99.8695777 23outstanding_alerts       108992    91.5518825  2dc_files 41 21    48.7804878  6dc_global_oids       4977      474    90.4761905  0dc_profiles       55248    99.8551774  0global 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_SEQUENCESCheck for appropriate caching of sequences for the application requirements.DC_USERSDeadlock 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_SEGMENTSThis is likely to be down to segment allocation. Identify what the session holding the enqueue is doing and use errorstacks to diagnose.DB_ROLLBACK_SEGMENTSThis 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_CONTROLThis 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.