　　在11g中，全表掃描可能使用direct path read方式，繞過buffer cache，這樣的全表掃描就是物理讀了．最近遇到了這樣一個測試環境的案例，表現為direcy path read事件等特很高．

[@more@]

主機效能資料

Operating System Statistics - Detail

Snap Time	Load	%busy	%user	%sys	%idle	%iowait
22-1月 18:00:28	0.00
22-1月 19:00:45	0.00	1.56	1.20	0.36	0.00	98.44

Cpu的的sys和user呼叫都比較低，cpu主要是消耗在io的等待上。

資料庫效能

效能情況透過主要透過AWR報告來體現. 後臺的job每1小時對資料庫的效能資料進行取樣，本報告中選取了系統工作峰值的兩個時間段進行分析，時間分別是：系統負載

系統負載資料，主要反映資料庫的壓力情況：

Load Profile

從以上資料可以得出以下二點結論：

資料庫產生的Redo size很小，說明資料的修改和插入非常少;一小時僅僅產生2.2*3600=7920k日誌。說明資料庫的效能瓶頸不在於Insert和Update的處理上,經過了解這個庫本身為測試用。

物理讀很高，物理讀就是直接從磁碟讀取的資料塊數，由於磁碟速度與記憶體速度的差異，物理讀的速度是很低的;透過統計資訊中的physical read total bytes(物理讀位元組數)可計算出每秒從磁碟讀取的io量,相關的統計資訊如下：

physical IO disk bytes	153,422,859,264	42,421,637.91	3,692,754.21
physical read IO requests	800,647	221.38	19.27
physical read bytes	153,040,289,792	42,315,856.91	3,683,546.10
physical read total IO requests	805,412	222.70	19.39
physical read total bytes	153,165,194,752	42,350,393.31	3,686,552.45

每秒磁碟讀IO = 153,165,194,752/3600/1024/1024=40.7M

以40.7M/s的速度從磁碟讀取資料，可能是造成資料庫效能下降的原因之一。

資料庫例項效能命中率

以下列出的是資料庫例項效能的各項的命中率，它們的最佳值是100%

Instance Efficiency Percentages (Target 100%)

Buffer Nowait %:	100.00	Redo NoWait %:	99.99
Buffer Hit %:	99.22	In-memory Sort %:	100.00
Library Hit %:	93.90	Soft Parse %:	91.50
Execute to Parse %:	60.56	Latch Hit %:	100.00
Parse CPU to Parse Elapsd %:	0.00	% Non-Parse CPU:	99.21

Shared Pool Statistics

Buffer NowWait和Buffer Hit都在99%以上，說明目前系統中的資料庫快取記憶體基本夠用。

Redo Nowait在99%以上，表示引數log_buffer 的設定滿足系統要求。
In-mem sort 為100%，表示不存在磁碟排序。
Soft Parse在90%以上，Exe-to-parse 為負值，說明應用系統中的sql的有一定的共享性，但shared pool 偏小了一些，導致共享池緊張的原因可能是採用連線池，不使用常連線的原因。
- Memory Usage %在80%左右，說明共享池相對比較緊張

共享池相對比較緊張，由於是開啟了SGA自動管理，由於Oracle分配sga的各個部分，這部分的設定不必過分關注，但為了解決後面提及的全表掃描問題，可能需要做一些調整。

等待事件(Top Wait Events)

以下列出的資料庫主要的等待事件

Event	Waits	Time(s)	Avg wait (ms)	% DB time	Wait Class
direct path read	790,366	7,376	9	92.45	User I/O
DB CPU		455		5.70
db file sequential read	8,342	97	12	1.21	User I/O
db file scattered read	259	5	20	0.06	User I/O
enq: KO - fast object checkpoint	1,271	4	3	0.05	Application

從上述資訊發現佔總的等待時間92.45%的事件是direct path read 。

指標：direct path read較高的可能原因有：

大量的磁碟排序操作，無法在排序區中完成排序，需要利用temp表空間進行排序.
大量的Hash Join操作，利用temp表空間儲存hash區。
SQL語句的並行處理
大表的全表掃描，在Oracle11g中，全表掃描的演算法有新的變化，根據表的大小、快取記憶體的大小等資訊，決定是否繞過SGA直接從磁碟讀取資料。而10g則是全部透過快取記憶體讀取資料，稱為table scan(large)。11g認為大表全表時使用直接路徑讀，可能比10g中的資料檔案雜湊讀(db file scattered reads)速度更快，使用的latch也更少。

從In-memory Sort來看，記憶體排序的比率為100%，不存在磁碟排序，排除了原因1.在NECHIS中也沒有使用並行sql的特性，可能原因就只有是2和4了。我們繼續在統計資訊中發現了有關全表掃描的統計資訊：

table scans (direct read)	1,272	0.35	0.03
table scans (long tables)	1,273	0.35	0.03
table scans (rowid ranges)	0	0.00	0.00
table scans (short tables)	25,637	7.09	0.62

從這裡可以看到，1273個"大"表掃描，1272個都使用了直接路徑讀取，由此可基本判斷，是由於全表掃描引起的大量的direct path read等待.

TOP sql分析

由於前面的判斷是物理讀很高引起了資料庫的效能問題，需要關注引起大量物理讀的SQL語句,以下列出的是Physical reads 最高的SQL語句:

SQL ordered by Reads

Physical Reads	Executions	Reads per Exec	%Total	CPU Time (s)	Elapsed Time (s)	SQL Id	SQL Module	SQL Text
13,003,306	698	18,629.38	69.60	237.48	5397.86			SELECT pub_patient_arch.pbirth...
5,658,569	193	29,319.01	30.29	120.50	2288.77			Select Pub_Patient_Arch.Pbirth...
2,019	28	72.11	0.01	0.16	8.05			SELECT Id , Parentid , Icon ...
1,522	1	1,522.00	0.01	0.05	3.59			select o.obj#, u.name, o.nam...
1,467	60	24.45	0.01	0.47	8.94			DECLARE job BINARY_INTEGER := ...
1,082	137	7.90	0.01	0.25	10.15			UPDATE Resourceinfo ...
981	107	9.17	0.01	0.09	3.56			來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/7839206/viewspace-1031102/，如需轉載，請註明出處，否則將追究法律責任。 0 0 分享到：上一篇：用Table變數返回多行資料下一篇： Oracle的並行操作[轉] 請登入後發表評論登入全部評論 StudyCow 註冊時間：2008-10-14 博文量 27 訪問量 115274 最新文章 Oracle系統統計資訊一個效能調優的案例在rhel下錯誤設定了lvm卷組叢集屬性的處理 DBA_HIGH_WATER_MARK_STATISTICS檢視 Oracle的並行操作[轉] 用Table變數返回多行資料一次RAC節點當機的解決過程查詢gv$session引發大量的PX Deq Credit: send blkd事件 NFS儲存rman備份時的mount選項 mysql的安裝支援我們作者招募使用者協議 FAQ Contact Us 北京盛拓優訊資訊科技有限公司. 版權所有京ICP備16024965號-8 北京市公安局海淀分局網監中心備案編號：11010802021510 niuxiaotong@pcpop.com 17352615567 未成年人舉報專區廣播電視節目製作經營許可證(京) 字第1234號中國網際網路協會會員

11g中direct path read事件等待很高的一個案例