db file parallel read等待事件
2011-08-08 19:31
363 查看
The process has issued multiple I/O requests in parallel to read blocks from data files into memory and is waiting for all requests to complete. This occurs during regular activity when a session batches many single block I/O requests together and issues them in parallel. This is also occurs during recovery. This wait event does not apply to parallel query or parallel DML.
Solutions
Block reads are necessary in a database, but it is important to limit unnecessary I/O. The best way to do this is by making the application as efficient as possible in regard to its data access requirements. Also, creating efficient SQL can produce large gains in performance. In contrast, changes to the RDBMS itself may produce smaller performance improvements.
Identify and resolve any SQL using unselective index scans. Use Ignite to find SQL with a large "db file parallel read" wait time -- indicating a long index scan. Look at the explain plan to see if the index scan is high cost with low cardinality.
Try increasing the size of the buffer cache with DB_BLOCK_BUFFERS if enough memory is available on the server. This should reduce the cost of the I/O, since the necessary data is more likely to be in memory, but it won't reduce the amount of I/O.
Consider using the operating system's data cache if available. For tables that are frequently accessed via index scans, placing their corresponding data files on buffered file systems can reduce the I/O to actual drives.
Evaluate Data Clustering.
Evaluate whether table partitioning can reduce the amount of data needed to navigate to satisfy your queries.本文出自 “Ask Maclean Liu Oracle” 博客,请务必保留此出处http://maclean.blog.51cto.com/2923249/1277906
Solutions
Block reads are necessary in a database, but it is important to limit unnecessary I/O. The best way to do this is by making the application as efficient as possible in regard to its data access requirements. Also, creating efficient SQL can produce large gains in performance. In contrast, changes to the RDBMS itself may produce smaller performance improvements.
Identify and resolve any SQL using unselective index scans. Use Ignite to find SQL with a large "db file parallel read" wait time -- indicating a long index scan. Look at the explain plan to see if the index scan is high cost with low cardinality.
Try increasing the size of the buffer cache with DB_BLOCK_BUFFERS if enough memory is available on the server. This should reduce the cost of the I/O, since the necessary data is more likely to be in memory, but it won't reduce the amount of I/O.
Consider using the operating system's data cache if available. For tables that are frequently accessed via index scans, placing their corresponding data files on buffered file systems can reduce the I/O to actual drives.
Evaluate Data Clustering.
Evaluate whether table partitioning can reduce the amount of data needed to navigate to satisfy your queries.本文出自 “Ask Maclean Liu Oracle” 博客,请务必保留此出处http://maclean.blog.51cto.com/2923249/1277906
相关文章推荐
- Oracle等待事件之db file sequential read/ db file parallel read
- db file parallel read等待事件
- 深入了解db file parallel read等待事件
- I/O上的等待事件 —— db file parallel read
- Oracle 等待事件之 db file parallel read
- Oracle等待事件db file parallel read
- 何时会发生db file sequential read等待事件?
- Oracle db file parallel write 和 log file parallel write 等待事件 说明
- db file sequential read等待事件
- 何时会发生db file sequential read等待事件
- 等待事件--db file sequential read
- Oracle等待事件之db file scattered read
- db file scattered read等待事件
- I/O上的等待事件 —— db file sequential read
- db file sequential read等待事件 --转载
- 等待事件--db file sequential read
- db file sequential read等待事件的一点研究
- db file sequential read等待事件总结
- Oracle 等待事件之 db file scattered read
- oracle之 db file sequential read等待事件优化思想