This metric represents the number of data blocks read from disk per second during this sample period. When a user performs a SQL query, Oracle tries to retrieve the data from the database buffer cache (memory) first, then searches the disk if it is not already in memory. Reading data blocks from disk is much more inefficient than reading the data blocks from memory. The goal with Oracle should always be to maximize memory utilization.
This test checks the data blocks read from disk per second. If the value is greater than or equal to the threshold values specified by the threshold arguments, and the number of occurrences exceeds the value specified in the "Number of Occurrences" parameter, then a warning or critical alert is generated.
The rest of the information in this section is only valid for this metric when it appears in either the Enterprise Manager Grid Control or the Enterprise Manager Database Control (if applicable).
The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.
|
Target Version |
Evaluation and Collection Frequency |
Upload Frequency |
Operator |
Default Warning Threshold |
Default Critical Threshold |
Consecutive Number of Occurrences Preceding Notification |
Alert Text |
|
pre-10g |
Every 5 Minutes |
After Every Sample |
> |
Not Defined |
Not Defined |
2 |
Physical reads are %value%/sec. |
|
Target Version |
Server Evaluation Frequency |
Collection Frequency |
Upload Frequency |
Operator |
Default Warning Threshold |
Default Critical Threshold |
Consecutive Number of Occurrences Preceding Notification |
Alert Text |
|
10.1.0.x; 10.2.0.x; 11.1.0.x; 11.2.0.x |
Every Minute |
Not Defined |
After Every Sample |
> |
Not Defined |
Not Defined |
2 |
Generated By Database Server |
DeltaPhysicalReads / Seconds where:
DeltaPhysicalReads: difference in 'select s.value from v$sysstat s, v$statname n where n.name='physical reads' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period
Block reads are inevitable so the aim should be to minimize unnecessary IO. This is best achieved by good application design and efficient execution plans. Changes to execution plans can yield profound changes in performance. Tweaking at system level usually only achieves percentage gains.
To view I/O on a per session basis to determine which sessions are responsible for your physical reads, you should visit the Top Sessions page sorted by Physical Reads. This approach allows you to identify problematic sessions and then drill down to their current SQL statement and perform tuning from there.
To identify the SQL that is responsible for the largest portion of physical reads, visit the Top SQL page sorted by Physical Reads. This page allows you to quickly determine which SQL statements are the causing your I/O activity. From this display you can view the full text of the SQL statement.
The difference between the two methods for identifying problematic SQL is that the Top Sessions view displays sessions that are performing the most physical reads at the moment. The Top SQL view displays the SQL statements that are still in the SQL cache that have performed the most I/O over their lifetime. A SQL statement could show up in the Top SQL view that is not currently being executed.
If the SQL statements are properly tuned and optimized, consider the following suggestions. A larger buffer cache may help - test this by actually increasing DB_BLOCK_BUFFERS. Do not use DB_BLOCK_LRU_EXTENDED_STATISTICS, as this may introduce other performance issues. Never increase the SGA size if it may induce additional paging or swapping on the system.
A less obvious issue which can affect the I/Orates is how well data is clustered physically. For example, assume that you frequently fetch rows from a table where a column is between two values via an index scan. If there are 100 rows in each index block then the two extremes are: 1.Each of the table rows is in a different physical block (100 blocks need to be read for each index block). 2.The table rows are all located in the few adjacent blocks (a handful of blocks need to be read for each index block).
Pre-sorting or reorganizing data can improve this situation in severe situations as well.
Related Topics
About Alerts
About the Metric Detail Page
Editing Thresholds
Understanding Line Charts
Copyright © 1996, 2009, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its affiliates.
Other names may be trademarks of their respective owners.