This metric represents the number of disk reads per transaction during the sample period. When a user performs a SQL query, Oracle tries to retrieve the data from the database buffer cache (memory) first, then goes to disk if it is not in memory already. Reading data blocks from disk is much more expensive than reading the data blocks from memory. The goal with Oracle should always be to maximize memory utilization.
The value of this statistic will be zero if there have not been any write or update transactions committed or rolled back during the last sample period. If the bulk of the activity to the database is read only, the corresponding "per second" metric of the same name will be a better indicator of current performance.
This test checks the data blocks read from disk per transaction. 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%/transaction. |
|
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 |
DeltaReads / Transactions where:
DeltaReads: difference in 'select value from v$sysstat where name='physical reads'' between end and start of sample period
Transactions: number of transactions 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 orders of magnitude changes in performance. Tweaking at system level usually only achieves percentage gains.
To identify the SQL that is responsible for the largest portion of physical reads, visit the Top SQL page sorted by Physical Reads. This view will allow you to quickly determine which SQL statements are causing the I/O activity. From this display you can view the full text of the SQL statement.
To view I/O on a per session basis to determine which sessions are responsible for your physical reads, you can 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 to perform tuning.
If the SQL statements are properly tuned and optimized the following suggestions may help. A larger buffer cache may help - test this by actually increasing DB_BLOCK_BUFFERS and not by using DB_BLOCK_LRU_EXTENDED_STATISTICS. Never increase the SGA size if it will 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 help to tackle this 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.