在Oracle 11g版本中串行的全表掃描可能使用直接路徑讀取(direct path read)的方式取代之前版本中一直使用的DB FILE SCATTERED READ, 顯然direct path read具備更多的優(yōu)勢(shì)： 1. 減少了對(duì)栓的使用，避免可能的栓爭(zhēng)用 2.物理IO的大小不再取決于buffer_cache中所存在的塊；試想某個(gè)8個(gè)塊的extent中1,3,5,7號(hào)塊在高速緩存中，而2,4,6,8塊沒有被緩存，傳統(tǒng)的方式在讀取該extent時(shí)將會(huì)是對(duì)2,4,6,8塊進(jìn)行4次db file sequential read,這是一種十分可怕的狀況，其效率往往要比單次讀取這個(gè)區(qū)間的所有8個(gè)塊還要低得多，雖然Oracle為了避免這種情況總是盡可能的不緩存大表的塊(讀入后總是放在隊(duì)列最冷的一端);而direct path read則可以完全避免這類問題，盡可能地單次讀入更多的物理塊。 當(dāng)然直接路徑讀取也會(huì)引入一些缺點(diǎn)： 1.在直接路徑讀取某段前需要對(duì)該對(duì)象進(jìn)行一次段級(jí)的檢查點(diǎn)(A segment checkpoint). 2.可能導(dǎo)致重復(fù)的延遲塊清除操作(我們假設(shè)你了解delayed block cleanout是什么). metalink 文檔[ID 793845.1] 對(duì)該新版本中的變化進(jìn)行了描述:

Applies to:

Oracle Server - Enterprise Edition - Version: 11.1.0.6 to 11.1.0.7 This problem can occur on any platform.

Symptoms

After?migrating?an?11g?database?from?a?standalone?to?a?4-node?RAC,??a?noticeable increase?of?'direct?path?read'?waits?were?observed?at?times. Here are the?Cache?sizes?and?Top?5?events. waitsCache?Sizes???????????????????????Begin????????End ~~~~~~~~~~~??????????????????----------?----------Buffer?Cache:?????3,232M?????3,616M??Std?Block?Size:?????????8KShared?Pool?Size:?????6,736M?????6,400M??????Log?Buffer:?????8,824K Top?5?Timed?Foreground?Events ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Avgwait???%?DB Event?????????????????????????????????Waits?????Time(s)???(ms)???time?Wait?Class ------------------------------?------------?-----------?------?------?---------- DB?CPU???????????????????????????????????????????13,916??????????42.1 direct?path?read??????????????????1,637,344??????13,359??????8???40.4?User?I/O db?file?sequential?read??????????????47,132???????1,111?????24????3.4?User?I/O DFS?lock?handle?????????????????????301,278???????1,028??????3????3.1?Other db?file?parallel?read????????????????14,724?????????554?????38????1.7?User?I/O

Changes

Migrated from a standalone database to a 4-node RAC. Moved from Unix file system storage to ASM. Using Automatic Shared Memory Management (ASMM). The setting of db_cache_size in spfile/pfile is low compared to normal workload requirements.

Cause

There have been changes in 11g in the heuristics to choose between direct path reads or reads through buffer cache for serial table scans. In 10g, serial table scans for "large" tables used to go through cache (by default) which is not the case anymore.??In 11g, this decision to read via direct path or through cache is based on the size of the table, buffer cache size and various other stats. Direct path reads?are faster than scattered reads and have less impact on other processes because they avoid latches.

Solution

When using Automatic Shared Memory Management (ASMM) and with buffer cache low limit set at a low end compared to the normal workload requirements and usually after startup, 11g might choose to do serial direct path read scans for large tables that do not fit in the SGA. When ASMM increases the buffer cache due to increased demand, 11g might not again do serial direct path read scans for these same large tables.? If you like to avoid this from happening, you should note the buffer cache and share pool requirements for a normal workload and set the low limits of buffer cache and shared pool in spfile/pfile close to these normal workload values. db_cache_size shared_pool_size 下面我們對(duì)直接路徑讀取對(duì)于延遲塊清除造成的影響進(jìn)行測(cè)試： SQL> create table tv as select rownum rn,rpad('A',600,'Z') rp from dual 2?????? connect by level <=300000;表已創(chuàng)建。新建一個(gè)會(huì)話a:SQL> set linesize 200 pagesize 1400; SQL> select count(*) from tv;COUNT(*) ---------- 300000SQL> select vm.sid, vs.name, vm.value 2??? from v$mystat vm, v$sysstat vs 3?? where vm.statistic# = vs.statistic# 4???? and vs.name in ('cleanouts only - consistent read gets', 5???????????????????? 'session logical reads', 6???????????????????? 'physical reads', 7???????????????????? 'physical reads direct');SID NAME????????????????????????????????????????????????????????????????? VALUE ---------- ---------------------------------------------------------------- ---------- 25 session logical reads???????????????????????????????????????? 27281 25 physical reads?????????????????????????????????????????????? 27273 25 physical reads direct 27273????????? 25 cleanouts only - consistent read gets???????????????? ??????? 0-- 顯然查詢采用了直接路徑讀取方式SQL> update tv set rn=rn+1;??????????????????????? -- 嘗試批量更新SQL> alter system flush buffer_cache;????????????? -- 刷新高速緩存，造成延遲塊清除的情景，并提交系統(tǒng)已更改。SQL> commit;提交完成。新建一個(gè)會(huì)話b:SQL> set linesize 200 pagesize 1400; SQL> select count(*) from tv;COUNT(*) ---------- 300000SQL> select vm.sid, vs.name, vm.value 2??? from v$mystat vm, v$sysstat vs 3?? where vm.statistic# = vs.statistic# 4???? and vs.name in ('cleanouts only - consistent read gets', 5???????????????????? 'session logical reads', 6???????????????????? 'physical reads', 7???????????????????? 'physical reads direct','redo size');SID NAME????????????????????????????????????????????????????????????????? VALUE ---------- ---------------------------------------------------------------- ---------- 25 session logical reads???????????????????????????????????????????????? 54554 25 physical reads?????????????????????????????????????????????????????? ?27273 25 physical reads direct???????????????????????????????????????????????? 27273 25 redo size???????????????????????????????????????????????????????????????? 0 25 cleanouts only - consistent read gets????????????????? 27273?????? --查詢采用direct path read時(shí)產(chǎn)生了延遲塊清除操作，但不產(chǎn)生redoSQL> select count(*) from tv;COUNT(*) ---------- 300000SQL> select vm.sid, vs.name, vm.value 2??? from v$mystat vm, v$sysstat vs 3?? where vm.statistic# = vs.statistic# 4???? and vs.name in ('cleanouts only - consistent read gets', 5???????????????????? 'session logical reads', 6???????????????????? 'physical reads', 7???????????????????? 'physical reads direct','redo size');SID NAME????????????????????????????????????????????????????????????????? VALUE ---------- ---------------------------------------------------------------- ---------- 25 session logical reads??????????????????????????????????????????????? 109104 25 physical reads??????????????????????????????????????????????????????? 54546 25 physical reads direct???????????????????????????????????????????????? 54546 25 redo size???????????????????????????????????????????????????????????????? 0 25 cleanouts only - consistent read gets??????????????????? 54546 再次查詢?nèi)圆捎弥苯勇窂阶x取,產(chǎn)生了相同數(shù)目的延遲塊清除操作，并沒有產(chǎn)生redo;可見direct path read的清除操作僅是針對(duì)從磁盤上讀取到PGA內(nèi)存中的鏡像，而不對(duì)實(shí)際的塊做任何修改，因而也沒有任何redo; 下面我們使用普通串行全表掃描方式，設(shè)置event 10949可以避免采用直接路徑讀取方式.關(guān)于該事件可以參見這里. SQL> ALTER SESSION SET EVENTS '10949 TRACE NAME CONTEXT FOREVER';會(huì)話已更改。SQL> select count(*) from tv;COUNT(*) ---------- 300000SQL> select vm.sid, vs.name, vm.value 2??? from v$mystat vm, v$sysstat vs 3?? where vm.statistic# = vs.statistic# 4???? and vs.name in ('cleanouts only - consistent read gets', 5???????????????????? 'session logical reads', 6???????????????????? 'physical reads', 7???????????????????? 'physical reads direct','redo size');SID NAME????????????????????????????????????????????????????????????????? VALUE ---------- ---------------------------------------------------------------- ---------- 25 session logical reads??????????????????????????????????????????????? 163662 25 physical reads??????????????????????????????????????????????????????? 81819 25 physical reads direct???????????????????????????????????????????????? 54546 25 redo size?????????????????????????????????????????????????????????? 1966560 25 cleanouts only - consistent read gets???????????????????????????????? 81819SQL> select count(*) from tv;COUNT(*) ---------- 300000SQL> select vm.sid, vs.name, vm.value 2??? from v$mystat vm, v$sysstat vs 3?? where vm.statistic# = vs.statistic# 4???? and vs.name in ('cleanouts only - consistent read gets', 5???????????????????? 'session logical reads', 6???????????????????? 'physical reads', 7???????????????????? 'physical reads direct','redo size');SID NAME????????????????????????????????????????????????????????????????? VALUE ---------- ---------------------------------------------------------------- ---------- 25 session logical reads??????????????????????????????????????????????? 190947 25 physical reads??????????????????????????????????????????????????????? 95673 25 physical reads direct???????????????????????????????????????????????? 54546 25 redo size?????????????????????????????????????????????????????????? 1966560 25 cleanouts only - consistent read gets???????????????????????????????? 81819 第一次采用普通全表掃描方式時(shí)產(chǎn)生了與direct path read時(shí)相同量的延遲塊清除操作，并因此產(chǎn)生了大量的redo,這種模式回歸到了最經(jīng)典的延遲塊清除情景中；之后的一次讀取則不再需要清除塊和產(chǎn)生重做了，我們?cè)谧x取一個(gè)“干凈”的表段。 從以上測(cè)試我們可以了解到，11g中使用更為廣泛的direct path read方式對(duì)有需要延遲塊清除操作的段所可能產(chǎn)生的影響，因?yàn)閷?shí)際沒有一個(gè)“修改塊”的操作，所以雖然延遲塊清除操作在該種模式下每次都必須產(chǎn)生，卻實(shí)際沒有產(chǎn)生臟塊，因而也就不會(huì)有“寫塊”的必要，故而也沒有redo的產(chǎn)生。所產(chǎn)生的負(fù)載可能更多的體現(xiàn)在cpu time的使用上。

總結(jié)

以上是生活随笔為你收集整理的直接路径读取对于延迟块清除的影响的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。