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

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 下面我們對直接路徑讀取對于延遲塊清除造成的影響進行測試： SQL> create table tv as select rownum rn,rpad('A',600,'Z') rp from dual 2?????? connect by level <=300000;表已創建。新建一個會話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;????????????? -- 刷新高速緩存，造成延遲塊清除的情景，并提交系統已更改。SQL> commit;提交完成。新建一個會話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時產生了延遲塊清除操作，但不產生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 再次查詢仍采用直接路徑讀取,產生了相同數目的延遲塊清除操作，并沒有產生redo;可見direct path read的清除操作僅是針對從磁盤上讀取到PGA內存中的鏡像，而不對實際的塊做任何修改，因而也沒有任何redo; 下面我們使用普通串行全表掃描方式，設置event 10949可以避免采用直接路徑讀取方式.關于該事件可以參見這里. SQL> ALTER SESSION SET EVENTS '10949 TRACE NAME CONTEXT FOREVER';會話已更改。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 第一次采用普通全表掃描方式時產生了與direct path read時相同量的延遲塊清除操作，并因此產生了大量的redo,這種模式回歸到了最經典的延遲塊清除情景中；之后的一次讀取則不再需要清除塊和產生重做了，我們在讀取一個“干凈”的表段。 從以上測試我們可以了解到，11g中使用更為廣泛的direct path read方式對有需要延遲塊清除操作的段所可能產生的影響，因為實際沒有一個“修改塊”的操作，所以雖然延遲塊清除操作在該種模式下每次都必須產生，卻實際沒有產生臟塊，因而也就不會有“寫塊”的必要，故而也沒有redo的產生。所產生的負載可能更多的體現在cpu time的使用上。

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。