Row Cache Objects

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.