Hot Tables in RAC Tuning

Hot Tables in RAC Tuning

When tuning storage, it is often beneficial to be able to identify hot spots in the databases, i.e. tables with more I/O activity than others. The v$segment_statistics view can be used to generate a list of objects order by read and write operations similar to the following:

 

<  hot_segments.sql

 select

     owner,

     object_name,

     sum(value) as total_ios

  from

     gv$segment_statistics

 where

    (statistic_name like 'physical%read%'

     or statistic_name like 'physical%write%')

     and

     owner not in ('SYS','XDB','SYSTEM','APEX_030200','MDSYS',

          'WMSYS','DBSNMP','EXFSYS','AUDSYS','GSMADMIN_INTERNAL')

  group by

     owner,

     object_name

  order by

     sum(value) desc;

 

OWNER      OBJECT_NAME     TOTAL_IOS

---------- --------------- ----------

SCOTT      DEPTS                 6574

SCOTT      DEPTS_PK               354

HR         EMPLOYEES              184

HR         EMP_EMP_ID_PK           18

HR         DEPARTMENTS              8

 

 

Even in single-instance databases, the above query is beneficial to be able to identify hot spots. Tables and indexes at the top of the list are candidates to be on separate disks so as to reduce disk contention. For Oracle RAC databases, one may also want to consider using application partitioning to access the segments from different instances, if possible. In the example above, there are two schemas shown and those applications may use different services. While separating the segments to different instances will not cut down on the I/O operations, it will reduce global cache transfers between instances.