cell single block physical read等待事件
This is an Exadata wait event similar to db file sequential read and normally occurs during index lookups when the block is not in memory and must be read from the Exadata storage cell disks. These are generally considered a ‘good’ read unless the index being used is not very efficient. In this case the query will read more blocks than necessary and possibly age out other good blocks from the Exadata smart cache.
cell single block physical read 等待事件是Exadata中的等待事件，类似于 db file sequential read。 常常在需要的索引数据块不在内存中，必须到Exadata的磁盘中获取的情况。 这种通常是可以认为是“好的”读取， 除非使用的很差的索引。 在使用差索引的情况时，查询操作会读取比正常情况多的数据块，并将好的数据块从Exadata 的缓存中挤出。
Solutions
Review the ‘Cell Single Block Physical Read Latency’ metric (in Ignite Resources view on the Exadata tab) to determine latencies. If the time to read data is above 2ms, that could indicate configuration issues with the Exadata storage cell.
If there are excessive waits on this event for a specific SQL statement, tune the statement so that it reads fewer blocks. If the top objects listed in the Ignite Object tab are indexes, determine if there is a more efficient index that could be used. If the top objects are tables, Oracle is going back to the table to get more data after the index lookup completes. That may indicate criteria in the WHERE clause that is not using a column in this index. Adding that column to the index could help performance.
DML statements like INSERT, UPDATE, DELETE, etc can also wait on this event because they are being forced to update inefficient indexes. Review the Ignite Object tab to determine which indexes are being waited for. If they are inefficient, Oracle is most likely not utilizing them in other SQL statements, so consider dropping them.
参考文献：exadata-awr.pdf (oracle.com)
| 欢迎光临 重庆思庄Oracle、Redhat认证学习论坛 (http://bbs.cqsztech.com/) | Powered by Discuz! X3.2 |