【等待事件】User I/O類 等待事件(2.5)--direct path read(直接路徑讀、DPR)


想關注我嗎?請點擊圖片上方watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=藍字小麥苗關注即可,關注後您將能夠每日得到最實用的數據庫技術。請將小麥苗公衆號置頂,小麥苗不喜歡被壓着,~O(∩_∩)O~html


小麥苗的今日寄語算法

     故天將降大任於斯人也,必先苦其心志,勞其筋骨,餓其體膚,空乏其身,行拂亂其所爲,因此動心忍性,曾益其所不能。數據庫

watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk= watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=       

    各位粉絲朋友,從8月13日開始,小麥苗打算花很長很長的一段時間來給你們分享有關本身整理的等待事件的學習筆記,有的內容來自於網絡,你們有什麼問題能夠留言,歡迎交流。緩存

    今天給你們分享的是等待事件中的User I/O 類等待事件之direct path read(直接路徑讀),仍是很重要的一個等待事件。微信

watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk= 等待事件歷史文章

【等待事件】等待事件概述(1)--等待事件的源起和分類網絡

●【等待事件】User I/O類 等待事件(2.1)--db file sequential read(數據文件順序讀)
session

【等待事件】User I/O類 等待事件(2.2)--db file scattered read(數據文件離散讀)ide

【等待事件】User I/O類 等待事件(2.3)--db file parallel read函數

【等待事件】User I/O類 等待事件(2.4)--db file single write性能



【等待事件】User I/O類 等待事件(2.5)--direct path read(直接路徑讀、DPR)



直接路徑讀等待事件的3個參數分別是:file#(指絕對文件號)、first block#block數量。

SELECT * FROM V$EVENT_NAME A WHERE A.NAME = 'direct path read';


watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk= 

這個等待事件有三個參數:

file number: 等待I/O讀取請求的文件的絕對文件號

first dba: 等待I/O讀取請求的第一個BLOCK

block cnt: first block爲起點,總共有多少個連續的BLOCK被請求讀取

 

直接路徑讀(direct path read)一般發生在Oracle直接讀取數據到PGA,這個讀取不須要通過SGA這類讀取一般在如下狀況被使用:

① 大量的磁盤排序IO操做,包括order by, group by, union, distinct, rollup, 沒法在PGA中完成排序,須要利用temp表空間進行排序。 當從臨時表空間中讀取排序結果時,會產生direct path read10g開始表現爲direct path read temp等待事件。

② 大量的Hash Join操做,利用temp表空間保存hash區。

③ SQL語句的並行處理並行查詢從屬進程

④ 預讀操做

⑤ 串行全表掃描(Serial  Table  Scan)大表的全表掃描,在Oracle11g中,全表掃描的算法有新的變化,根據表的大小、高速緩存的大小等信息,決定是否繞過SGA直接從磁盤讀取數據。而10g則是所有經過高速緩存讀取數據,稱爲table scan(large)11g認爲大表全表時使用直接路徑讀,可能比10g中的數據文件散列讀(db file scattered reads)速度更快,使用的latch也更少。

最多見的是第一種狀況。在DSS系統中,存在大量的Direct path read是很正常的,可是在OLTP系統中,一般顯著的直接路徑讀都意味着系統應用存在問題,從而致使大量的磁盤排序讀取操做。

db file sequential readdb file scattered readdirect path read是常見的集中數據讀方式,圖簡要述了這3種方式的讀取示意。


watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk= 

大量的direct path read等待時間最多是一個應用程序問題。 

direct path read事件由SQL語句驅動,這些SQL語句執行來自臨時的或常規的表空間的直接讀取操做。當輸入的內容大於PGA中的工做區域時,帶有須要排序的函數的SQL語句將排序結果寫入到臨時表空間中 臨時表空間中的排序順序串隨後被合併,用於提供最終的結果。讀取排序結果時, Oracle會話在direct path read等待事件上等待。

對於這一寫入等待,咱們應該找到I/O操做最爲頻繁的數據文件(若是有過多的排序操做,頗有可能就是臨時文件),分散負載,加快其寫入操做。

DB_FILE_DIRECT_IO_COUNT初始化參數可能影響direct path read的性能。

串行全表掃描(Serial Table Scan)--Oracle 11g全表掃描以Direct Path Read方式執行


Oracle 11g以前,全表掃描使用db file scattered read的方式,將表中的數據塊離散的讀到Buffer Cache以後,供用戶訪問和使用,可是若是全表訪問的表很是大,則有可能佔用大量的Buffer Cache內存,這會致使Buffer Cache中其餘數據被老化和擠出內存,並且在這一系列的讀取操做中,Oracle引擎須要去判斷每個數據塊是否已經存在於內存中,而後還要去請求內存空間,不斷使用Cache Buffer ChainCache Buffer Lru Chain兩個Latch進行判斷,在某種程度上會加重Latch競爭,若是全表訪問的數據只是偶爾個別的訪問,則佔據大量Buffer  Cache就顯得過於昂貴,Oracle Database 11g,一種被稱爲串行全表掃描(Serial  Table  Scan)的技術被引入,該特性根據數據塊的設置和統計信息等,自動決定是採用Direct Path Read繞過SGA,仍是採用常規方式讀取,由於這種自動選擇,這一特性又被稱爲自適應直接讀(Adaptive  Direct Read).這種方式的好處是能夠下降Buffer Cache的競爭,可是每次都要發生物理讀,如果有多個會話同時去掃描同一張大表,這樣會增大IO,也有可能致使系統的問題,並且在讀取以前可能須要觸發檢查點,避免讀到舊的映像

Oracle Database 11g中有一個新特性,全表掃描能夠經過直接路徑讀的方式來執行(Direct Path Read),這是一個合理的變化,若是全表掃描的大量數據讀取是偶發性的,則直接路徑讀能夠避免大量數據對於Buffer Cache的衝擊。

固然對於小表來講,Oracle容許經過Buffer Cache來進行全表掃描,由於這可能更快,也對性能影響不大。小表受到隱含參數:_small_table_threshold 影響。若是表大於 5 倍的小表限制,則自動會使用DPR替代FTS。能夠設置初始化參數: _serial_direct_read 來禁用串行直接路徑讀。

固然,Oracle經過一個內部的限制,來決定執行DPR的閾值。

能夠經過設置10949事件屏蔽這個特性,返回到Oracle 11g以前的模式上:

altersession setevents '10949 trace name context forever, level 1';

還有一個參數 _very_large_object_threshold 用於設定(MB單位)使用DPR方式的上限,這個參數須要結合10949事件共同發揮做用。10949 事件設置任何一個級別都將禁用DPR的方式執行FTS,可是僅限於小於 5 BUFFER Cache的數據表,同時,若是一個表的大小大於 0.8 倍的 _very_large_object_threshold  設置,也會執行DPR

這些限定的目標在於:

對於大表的全表掃描,必須經過Direct Path Read方式執行,以減小對於Buffer Cache的衝擊和性能影響。可是咱們能夠經過參數調整來決定執行DPR的上限和下限。

Oracle經過隱含參數_small_table_threshold來界定大表小表的臨界,Oracle認爲對於大表執行直接路徑讀取的意義比較大,對於小表經過將其緩存可能受益更大。_small_table_threshold的單位爲block。默認爲db cache size2%大小,在實例啓動過程當中動態決定。11GR2以前,表的大小要是_small_table_threshold參數值的5倍纔會採起直接路徑讀取方式,11GR2後只須要知足_small_table_threshold定義的大小就會採起直接路徑讀取。

 

11g中,全表掃描可能使用direct path read方式,繞過buffer cache,這樣的全表掃描就是物理讀了 10g中,都是經過gc buffer來讀的,因此不存在direct path read的問題。

一個隱含參數_serial_direct_read能夠禁用串行直接路徑讀,11g默認值爲auto

禁用direct path read  _serial_direct_read = false

啓用direct path read  _serial_direct_read = true  

alter sytem set "_serial_direct_read"=never scope=both sid='*'; 能夠顯着減小direct path read

調整數據庫參數alter system setevent='10949 trace name context forever, level 1'來關閉「direct path read」(直接路徑讀)特性,使SQL語句能夠從緩存中查詢數據,達到下降I/O讀取量,使全表掃描的數據從緩存中讀取,加快SQL語句運行速度的目的。



場景:關於直接路徑讀的一個案例處理

Oracle 11g新特性direct path read引起的系統停運故障診斷處理 http://blog.itpub.net/26736162/viewspace-2123524/

深刻分析direct path read(11G) - Oracle數據庫管理 - ITPUB論壇-中國最專業的IT技術社區 http://www.itpub.net/thread-1815281-1-1.html


watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=



About Me:小麥苗●李華榮      

本文做者:小麥苗,只專一於數據庫的技術,更注重技術的運用

本文在itpub(http://blog.itpub.net/26736162)、博客園(http://www.cnblogs.com/lhrbest)和我的微信公衆號(xiaomaimiaolhr)上有同步更新,推薦pdf文件閱讀或博客園地址閱讀

QQ羣:230161599  微信羣:私聊

小麥苗分享的其它資料:http://blog.itpub.net/26736162/viewspace-1624453/

 聯繫我請加QQ好友(642808185),註明添加原因

【版權全部,文章容許轉載,但須以連接方式註明源地址,不然追究法律責任】



長按識別二維碼或微信客戶端掃描下邊的二維碼來關注小麥苗的微信公衆號:xiaomaimiaolhr,學習最實用的數據庫技術。

watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=

watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=


watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=


watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=



本文分享自微信公衆號 - DB寶(lhrdba)。
若有侵權,請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」,歡迎正在閱讀的你也加入,一塊兒分享。

相關文章
相關標籤/搜索