Monitoring Exadata Storage Cells - Oracle Exadata Recipes: A Problem-Solution Approach - page 380

IORM Category (objectType = IORM_CATEGORY)
Oracle automatically collects IORM category performance metrics on each storage server for each database and
consumer group deployed on your Exadata Database Machine when an IORM plan is enabled.

CT_IO_LOAD metric, which reports the disk I/O load per resource category. This is
a good way to measure which classifications of resource consumers are generating the highest
I/O workload.

• Measure the

CT_IO_UTIL * metric, which reports the disk I/O utilization for small and large
I/Os per database per category. This is a good way to measure which classifications of
resource consumers are generating the highest disk utilization.

• Measure the

CT_IO_WT * metrics. These metrics will
show you which resource categories are suffering wait time based on IORM plan I/O queuing
and can be used to validate or adjust your IORM plan.

• If you have implemented an IORM plan, monitor the

Flash Cache (objectType = FLASHCACHE)
Exadata's Flash Cache metrics are classified into two main metric buckets: bandwidth and I/O requests. The FC*BY*
metrics report on the number of MB processed, skipped, or pushed out of Flash Cache for a variety of reasons, and the
FC*RQ* metrics contain I/O request metrics for a variety of conditions. In addition to the bandwidth and I/O requests
classification, there is generally a metric for each Flash Cache “hit” reason and a Flash Cache “miss” reason.

FC_BYKEEP * metrics; these indicate that data was pushed out of
Flash Cache in order to load objects tagged with a Flash Cache “keep” attribute.

• Look for high numbers for the

FC_IO_BYKEEP * and
FC_IO_RQKEEP * metrics to measure the effectiveness of your caching strategy.

• If you have elected to pin objects in Flash Cache, examine the

FC * SKIP * metrics to measure the amount of data and number of requests that
needed to be satisfied from hard disks because the nature of the requests bypassed Smart
Flash Cache.

• Measure the

FC * MISS * metrics to report the number of MB and I/O requests that required I/O
to be satisfied from hard disks because not all of the data was loaded into the Flash Cache.

• Measure the

Like all data-caching solutions, the goal of Flash Cache is to reduce the need to perform disk I/O on physical hard
disks. As such, you would ideally like to see a relatively high percentage of your database's I/O requests be satisfied
from Flash Cache (if not from the database instance buffer cache). However, as large I/O requests generally bypass
Flash Cache, your benefit from Flash Cache is truly dependent on your database, application, and workload.

Flash Logging (objectType = FLASHLOG)
Many of Exadata's FLASHLOG metrics are cumulative, which makes measuring Smart Flash Logging behavior relatively
simple to measure and monitor.

• Look for a high ratio of

FL_FLASH_FIRST to FL_DISK_FIRST ; the higher the metric values are
for FL_FLASH_FIRST , the more often Exadata is writing to flash before disk. While this is the
purpose of Smart Flash Logging, it could indicate that your application is performing a very
high number of commits.

• To measure the overall effectiveness and impact of Smart Flash Logging, monitor the value of

FL_PREVENTED_OUTLIERS and FL_ACTUAL_OUTLIERS . These represent the number of redo write
requests that were cushioned, or “saved”, Flash Logging and the number that could not be
serviced either flash or disk, respectively.