等待事件是總個性能調優的入口。

在總體查看ORACLE數據庫性能時，總是會先看TOP? N WAIT,比如：

下面我切了一段我的AWR報表內容：

	Top Timed Events
???? '*' Cnt : count of instances with wait times for the event
	Wait?	Event?	Wait Time?
I#	Class	Event	Waits
*		DB CPU
	User I/O	db file sequential read	203,391
*
	Commit	log file sync	173,402
*
	Network	LNS wait on SENDREQ	230,029
*
	Other	LGWR-LNS wait on channel	403,571
*
	System I/O	log file parallel write	213,373
*		?	?
?	System I/O	db file parallel write	82,579
*	?	?	?
?	System I/O	control file sequential read	31,898
*	?	?	?
?	System I/O	control file parallel write	6,894

這時可以看出，每一種等待事件的分類，從分類我們很清楚就知道，在哪種等待

消耗了更多的資源。

再成分類細化，對性能優化就有了一個很清晰的方向了。

（1.如果是USER I/O ，那么查看最大消耗的應對的 SQL SCRIPT,

? 2.如果是 SYSTEM I/O 查看 是什么等待事件，看是否能在數據庫級別進行調優.....）

從我的報表中可以看到，第一位的還是? User I/O，并且等待事件為： db file sequential read，

引起此等待事件的原因大體為：

通常顯示與單個數據塊相關的讀取操作，在大多數情況下，讀取一個索引塊或者通過索引讀取一個數據塊時，都會記錄這個等待。

如果這個等待事件比較顯著，可能表示在多表連接中，表的連接順序存在問題，可能沒有正確的使用驅動表；或者可能索引的使用存在問題，并非索引總是最好的選擇。

在大多數情況下，通過索引可以更為快速地獲取記錄，所以對于一個編碼規范、調整良好的數據庫，這個等待事件很大通常是正常的。但是在很多情況下，使用索引并不是最佳的選擇，比如讀取較大表中大量的數據，全表掃描可能會明顯快于索引掃描，所以在開發中就應該注意，對于這樣的查詢應該避免使用索引掃描。

ORACLE 等待事件的分類?

1	ADMINISTRATIVE	DBA的命令導致的等待，如重建索引
2	APPLICATION	可能是應用的代碼導致的等待，比如：行級鎖和顯式的表鎖；
3	CLUSTER	RAC集群相關的等待，全局內存的等待，一個實例等待另一個實例的復制。心跳線帶寬不夠，實例間內存交換過于頻繁。
4	COMMIT	這個類別僅和一個等待事件相關，在發出commit命令后等待redo log write 確認，這個事件是log file sync,
5	CONCURRENCY	內部資源造成的等待，如latches?
6	CONFIGURATION	由于實例或數據庫資源配置不當而造成的等待，如不適當的redo log buffer size 和 shared_pool size;
7	IDLE??	Session為非活動的且等待工作，此類事件屬于此范疇，典型的如 'SQL*Net message from client'；
8	NETWORK	基于網絡的等待，如'SQL*Net more data to dblink'
9	QUEUE	基于隊列的一些等待，如 'wait for EMON to spawn'；
10	SCHEDULER	資源管理器相關等待，如'resmgr: become active'；
11	SYSTEM I/O	系統后臺產生的I/O等待，比如DBWR寫LOG產生的，如DBWR wait for 'db file parallel write'，比如DBWR進程不夠時，這時可以添加DBWR進程。
12	USER I/O	用戶產生的I/O等待
13	OTHER	通常不會發生的等待，如 'wait for EMON to spawn'；

總結

以上是生活随笔為你收集整理的ORACLE 等待事件的分类的全部內容，希望文章能夠幫你解決所遇到的問題。

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