常見等待事件

cccgw發表於2008-03-02
statspack wait events 總結 .[@more@]

DB file scattered read:

經常是全表掃描引起的,檢查全表掃描的必要性,試著把小的表cache住避免重複讀進,因為全表掃描放在LRU的最近最少使用端。

1、 DB File Sequential Read:

一般是單個塊讀,如索引讀等。在事務多的系統中正常會偏高。確認索引讀的必要性, 調整DB_CACHE_SIZE。一般是較差的表連線順序、低效率的索引。

2、 Free Buffer

系統記憶體在等待空閒的buffer。如果已SQL調優,需增大DB_BUFFER_CACHE。可能特定的SQL引起資料佔用大量BUFFER,一般是大量的DML操作產t生,而DBWR寫得不夠快。可以增加DBWR程式或增加磁碟數量。

3、 Buffer Busy:

一般不能大於1%。檢視Buffer Wait Satics部份或V$WAITSTAT,如果是segment header的等待,增大freelist groupspctused。如果是undo header,增大rollback segments,如果是undo block,需要降低相應表格的資料密度或增大DB_CACHE_SIZE。如果是data block,可以移動資料到另一個塊來避免熱塊,增大表的freelists或使用自動管理表空間。或者使用更小的block size來避免熱塊.如果是index block,可重建索引、分割槽索引或使用反向鍵索引。

4、 Latch Free

一般不超過0.5%Most latch problems are related to the failure to use bind variables (library cache latch), redo generation issues (redo allocation latch), buffer cache contention issues (cache buffers LRU chain), and hot blocks in the buffer cache (cache buffers chain).

5、 Enqueue:

Enqueue是保護共享資源的一種鎖,FIFO。如防止兩個人同時更新一條資料等。有ST enqueue,HW enqueue,TX4 enqueue,TM enqueueST enqueue是字典管理表空間的管理和分配鎖,HW is used with high-Water mark of a segment,分配extents會引起鎖。TX4 有三種,第一種是複寫唯一索引,要回滾或提交來釋放鎖,第二種是rowids,當有多使用者update the same fragment時要回滾或提交來釋放鎖。第三種是多使用者同時update the same block。如果沒有空餘的ITL slots,會產生lock.增加initransmaxtrans 來允許 multiple ITl slots,或加大pctfreeTM enqueues 在進行DML操作時為了防止DDL操作影響到物件而加的lock.

6、 Log Buffer Space

log buffer的速度比LGWR寫進redo logs的速度快時,或者日誌切換太慢導致的。可以加大log fileslog buffer,或者將日誌放在I/O更好的磁碟。

7、 Log File Switch

提交請求在等待logfiles switch (archivechkpt)。確保歸檔磁碟沒有滿或太慢,DBWR是不是因為I/O而太慢。增加或增大redo logs,增加DBWR程式。

8、 Log File Sync.

Log file sync 程式等待LGWRLog buffer寫到redo logs完成。將redo log 放在更快的磁碟上,或分在不同盤上,不用RAID 5(寫效能不好),用直接I/O的系統或RAW

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/668365/viewspace-1000260/,如需轉載,請註明出處,否則將追究法律責任。

相關文章