探索系列_神人steve adams之著oracle8i interal service(三）

timed statistics 定時統計

  如果設定timed_statistics引數配置為true,等待會以定時方式顯示結果。讓我確認，以前其它人也說過如此的話，這樣開啟此引數的成本可以忽略了.
如果你相信你自己，使用set timing on;
  如果不配置timed statistics,oracle只是記錄等待前後的原因，當等待結束時，它記錄是否超時。但如果開啟timed statistics,oracle會在等待前後檢查時間,
同時記錄等待佔用的時間。等待佔用的時間以百分之一秒單位計算，也叫微秒.


wait types  等待型別

    v$system_event 顯示等待的總次數及超時，每種等待事件的總計等待時間.它是整個例項生命週期所有程式的累計值。
根據總體等待事件所花費時間，以降序對這些等待事件進行顯示，它是每種等待型別嚴重程式的一個指示燈.
    但是，總體花費的等待時間，只是對於等待某些資源這種情況有用。如果程式等待是因為目前沒有工作而作，這時等待時間就不重要的或沒有意義了。假如它們在等待某種常規的操作,
比如disk i/o，這時總的等待時間將依賴於工作負荷.這種情況下，平均等待時間就比總的等待時間更為有用或有效.



session waits 會話等待
    v$session_event顯示每個會話的等待統計資訊。雖然等待影響的是程式而非會話，但是v$session_event因為會話可以在多個程式之間遷移（比如像多執行緒伺服器的配置），記錄會話。累積的會話等待統計
有兩大作用.首先，如果一個特定有使用者發現出現某段時間出現效能問題，此時根據這個會話的等待統計就可以診斷使用者程式.
第二，如果發現過度等待某種資源，會話等待統計也可以確認哪些會話，是導致這個問題的根源.

 
wait parameters 等待引數
   等待統計非常有用，因為它們可以告訴你哪些會話在等待，它們在等待什麼資源。它們可能在等待lathes,database blocks,enqueue locks,或其它的資源型別.一旦你瞭解了等待的資源型別，對你調優工作很有幫助.
等待統計僅僅給你提供相關的線索，但只有等待引數能讓你定位到具體的問題.
   不幸的是，等待引數很難抓取。它們在v$session_wait的出現非常短暫。這個檢視顯示每個會話對於目前或最近每個等待的等待引數資訊，還有等待的持續時間。但是查詢v$session_wait相對於大量多等待的長度，要花更多的時間.
假如你在短暫的會話中執行兩次它的查詢，會發現大多等待事件已現不再出現，這很正常。另外重複查詢這個檢視代價太高，因此它僅適用於限制性的工作範圍.
    幸運的是，用dbms_support包產生trace file，發現等待引數，或者用10046.這個trace過程作用和執行sql_trace工具一樣，但也包括每個等待，包括等待引數.
每種等待事件型別的等待引數含義，可以查詢v$event_name。

    引數列表

引數                                     描述
_use_vector_posts                        vector posts允許在單一訊號量操作中，開啟傳送通知給多個等待程式

post_wait_device                         一種偽裝置驅動。當操作是針對一個裝置型別的裝置特定檔案，這個功能會開啟。使用了這個引數，它指定
                                         post-wait driver裝置檔案的路徑


timed_statistics                         需要調優，開啟它吧

use_post_wait_driver                     如果存在這個引數，為了使用post-wait driver,配置它為true,而不是正常的訊號量操作



events 事件

事件                                     描述
10046                                    實現dbms_support trace,它是sql_trace工具的超集。設定為level 4,trace結果包含bind calls,
                                         設定為level 8,包含等待事件，這是dbms_support的預設level;如果設定為level 12, 同時包含binds和等待