Oracle 11g全表扫描以Direct Path Read方式执行
在Oracle Database 11g中有一个新特性,全表扫描可以通过直接路径读的方式来执行(Direct Path Read),这是一个合理的变化,如果全表扫描的大量数据读取是偶发性的,则直接路径读可以避免大量数据对于Buffer Cache的冲击。 Event 10949 可以在线设置,但对现有session可能不会生效,新登录的会话会执行新的设置:
? 隐含参数"_serial_direct_read" 可以达到类似的限制,其默认值为AUTO,设置为NEVER时禁用 11g 的自动direct path read的特性。该参数可以动态在实例或会话级别修改,而无需重启实例。
以下的AWR信息是典型的DPR症状: 引用以下链接的一点英文描述供参考: http://sai-oracle.blogspot.com/2010/06/full-table-scan-behavior-in-11g.html Before 11gr2,full table scan access path read all the blocks of a table (or index fast full scan) under high water mark into the buffer cache unless either "_serial_direct_read" hidden parameter is set to true or the table/index have default parallelism set. In 11gR2,Oracle will automatically decide whether to use direct path reads bypassing buffer cache for serial full table scans. For using direct path reads,Oracle first has to write any dirty blocks of the table to disk by issuing object level checkpoint and then read all the blocks from disk into the PGA of server process. If it has to undo any uncommitted transactions to provide read consistency or to do delayed block clean out,Oracle will use server process PGA to construct read consistent block buffers. If block clean out has to be performed by the server process using direct path reads for full table scans,it won‘t write those modified blocks back to disk,so every time you perform full table scan using direct path reads it‘d have to keep doing the same work of cleaning out the blocks for every execution. For this reason,it is recommended to manually clean out those blocks by performing full table scan without using direct path reads. Following behavior was observed with my testing on 11.2.0.1: Hidden parameter "_small_table_threshold" defines the number of blocks to consider a table as small. Any table having more blocks (about 5 times the value of "_small_table_threshold" if you leave it at default value) will automatically use direct path reads for serial full table scans (FTS). Hidden parameter "_very_large_object_threshold" defines the upper limit of object size in MB for using direct path reads. There is no effect on FTS behavior just by setting this parameter alone. Event 10949 set to any level will disable direct path reads for serial scans only if the size of an object is less then 5 times the size of buffer cache. Combination of event 10949 and "_very_large_object_threshold" parameter will disable direct path reads for serial scans if the size of an object is less than 5 times the size of buffer cache or the value of "_very_large_object_threshold" is less than about 0.8 times the size of an object. So,if you want to disable direct path reads for serial scans for any object,then set event 10949 at any level and set "_very_large_object_threshold" to greater than the size of largest object in MB. Hidden parameter "_serial_direct_read" (or event 10355 set at any level) set to TRUE will enable direct path reads for all serial scans,unless the table is considered as small table and it‘s caching attribute is set (by issuing alter table xxxx cache). Remember that any sql statement already parsed and not using direct path reads will continue to do so unless hard parse is forced after setting these parameters. For this reason,it is better not to set these parameters. It is not recommended to set any of the above mentioned hidden parameters if you want direct path reads to be used for serial scans,let Oracle decide dynamically based on the size of an object. (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |