熱點推薦:
您现在的位置: 電腦知識網 >> 編程 >> Oracle >> 正文

Oracle 10G 最佳20位新特性:等待界面

2013-11-13 15:33:32  來源: Oracle 

  g 等待界面為還沒有被 ADDM 捕獲的即時性能問題提供了有價值的診斷數據
  
  數據庫太慢了!
  這句話通常出自一位嚴格的用戶之口如果您和我一樣那麼在您的 DBA 生涯中您肯定無數次聽到過這句話
  
  那麼您又怎樣解決該問題呢?除了對用戶置之不理之外(這是我們大多數人都不敢奢望的想法)您可能要做的第一件事就是查看是否有任何會話在等待數據庫內部或外部的任何事件
  
  Oracle 提供了一個簡單但一流的機制來達到此目的V$SESSION_WAIT 視圖該視圖顯示了有助於您的診斷的各種信息如一個會話正在等待或已經等待的事件以及等待了多長時間和多少次例如如果會話在等待事件 db file sequential read列 P 和 P 將顯示會話正在等待的塊的 file_id 和 block_id
  
  對於大多數等待事件而言這個視圖足夠了但它還不是一個強健的調整工具之所以如此說至少是因為以下兩個重要原因
  該視圖是當前情況的一個快照當等待不再存在時會話先前出現的那些等待的歷史也將消失從而使得事後診斷非常困難V$SESSION_EVENT 提供了累積的但不是非常詳細的數據
  V$SESSION_WAIT 包含了只與等待事件相關的信息要獲得所有其它的相關信息(如用戶 ID 和終端)您必須將它和 V$SESSION 視圖結合使用
  
  在 Oracle 數據庫 g 中等待界面經過了徹底的重新設計從而只需更少的 DBA 干預即可提供更多的信息在本文中我們將浏覽這些新的特性並了解它們如何幫助我們診斷性能問題對於大多數性能問題您可以從自動數據庫診斷管理器 (ADDM) 中獲得擴展分析但對於還沒有被 ADDM 捕獲的即時問題等待界面將提供有價值的診斷數據
  
  增強的會話等待
  第一個增強涉及到 V$SESSION_WAIT 本身這一點通過示例可以很好地說明
  
  假定您的用戶抱怨會話掛起了您查明了該會話的 SID並在 V$SESSION_WAIT 視圖中選中了該 SID 的記錄輸出顯示如下
  
  SID           :
  SEQ#           :
  EVENT          :enq:TX row lock contention
  PTEXT          :name|mode
  P            :
  PRAW          :
  PTEXT          :usn<<16 | slot
  P2            : 327681
  P2RAW          : 00050001
  P3TEXT          :sequence
  P3            : 43
  P3RAW          :0000002B
  WAIT_CLASS_ID      : 4217450380
  WAIT_CLASS#       : 1
  WAIT_CLASS        : Application
  WAIT_TIME        : -2
  SECONDS_IN_WAIT     : 0
  STATE          :WAITED UNKNOWN TIME
  注意以黑體顯示的列;在這些列中,WAIT_CLASS_ID、WAIT_CLASS# 和 WAIT_CLASS 是 10g 中新增的列。TW.WINgwIt.CoM列 WAIT_CLASS 指示等待的類型,必須將其作為有效的等待事件解決或者作為空閒的等待事件退出。在上面的例子中,等待類顯示為 Application,這表示它是一個需要您注意的等待。
  
  該列突出顯示那些能夠證明與您的調整最相關的少數幾條記錄。例如,您可以使用如下查詢來獲取事件的等待會話。
  
  select wait_class, event, sid, state, wait_time, seconds_in_wait
  from v$session_wait
  order by wait_class, event, sid
  /
  下面是一個樣例輸出:
  
  WAIT_CLASS EVENT            SID STATE   WAIT_TIME SECONDS_IN_WAIT
  ---------- -------------------- ---------- ------------------- ---------- ---------------
  Application enq:TX -          269 WAITING       0  73
  row lock contention    
  Idle    Queue Monitor Wait     270 WAITING       0  40
  Idle    SQL*Net message from client 265 WAITING      0  73
  Idle    jobq slave wait       259 WAITING      0  8485
  Idle    pmon timer         280 WAITING      0  73
  Idle    rdbms ipc message      267 WAITING      0  184770
  Idle    wakeup time manager     268 WAITING      0  40
  Network   SQL*Net message to client  272 WAITED SHORT TIME -1  0
  在這,您可以看到幾個事件(如 Queue Monitor Wait 和 JobQueue Slave)被明確地歸為 Idle 事件。您可以將它們作為非阻塞等待消除掉;不過,有時這些“空閒”事件可能指示一個內在的問題。例如,與 SQL*Net 相關的事件可能指示高網絡延遲(除其他因素外)。
  
  另一件要注意的重要的事情是,WAIT_TIME 的值為 -2。某些平台(如 Windows)不支持快速計時機制。如果在這些平台上沒有設定初始化參數 TIMED_STATISTICS,那麼將無法獲得准確的計時統計數據。在這種情況下,在 Oracle9i 中,該列將顯示一個非常大的數字,這使問題變得更加不清晰。在 10g 中,值 -2 指示這種情況 — 平台不支持快速定時機制並且沒有設定 TIMED_STATISTICS。(對於本文剩下的部分,我們將假定存在一個快速計時機制。)
  
  會話也顯示等待
  記得長期以來一直需要將 V$SESSION_WAIT 與 V$SESSION 結合使用以獲得有關會話的其他詳細信息嗎?嗯,這已經成為歷史了。在 10g 中,V$SESSION 視圖還顯示由 V$SESSION_WAIT 顯示的等待。下面是 V$SESSION 視圖其余的列,這些列顯示了會話當前等待的等待事件。
  
  EVENT#           NUMBER
  EVENT           VARCHAR2(64)
  P1TEXT           VARCHAR2(64)
  P1             NUMBER
  P1RAW           RAW(4)
  P2TEXT           VARCHAR2(64)
  P2             NUMBER
  P2RAW           RAW(4)
  P3TEXT           VARCHAR2(64)
  P3             NUMBER
  P3RAW           RAW(4)
  WAIT_CLASS_ID       NUMBER
  WAIT_CLASS#        NUMBER
  WAIT_CLASS         VARCHAR2(64)
  WAIT_TIME         NUMBER
  SECONDS_IN_WAIT      NUMBER
  STATE           VARCHAR2(19)
  這些列與 V$SESSION_WAIT 中的那些列相同,且顯示相同的信息,從而不再需要在那個視圖中查看它們了。因此,對於等待任意事件的任意會話,您僅需要查看一個視圖。
  
  讓我們回到原來的問題:SID 為 269 的會話正等待事件 enq:TX — row lock contention,指示它正等待被另一個會話占用的鎖。要診斷該問題,您必須識別占用鎖的那個會話。但您如何才能做到這一點?
  
  在 Oracle9i 及更低版本中,您可能得編寫復雜(和極耗資源)的查詢來獲得占用鎖的會話的 SID。而在 10g 中,您所要做的就是執行以下查詢:
  
  select BLOCKING_SESSION_STATUS, BLOCKING_SESSION
  from v$session
  where sid = 269
  
  BLOCKING_SE BLOCKING_SESSION
  ----------- ----------------
  VALID          265
  
  找到了:SID 為 265 的會話阻塞了會話 269。還能更容易嗎?
  
  有多少等待?
  用戶仍然在纏著您,因為用戶的問題仍然沒有得到滿意的解答。為什麼用戶的會話花了這麼長時間才完成?您可以執行以下命令來找出原因:
  
  select * from v$session_wait_class where sid = 269;
  
  輸出返回為:
  
  SID SERIAL# WAIT_CLASS_ID WAIT_CLASS# WAIT_CLASS  TOTAL_WAITS TIME_WAITED
  ---- ------- ------------- ----------- ------------- ----------- -----------
  269  1106  4217450380  1 Application   873   261537
  269  1106  3290255840  2 Configuration  4      4
  269  1106  3386400367  5 Commit      1      0
  269  1106  2723168908  6 Idle       15   148408
  269  1106  2000153315  7 Network     15      0
  269  1106  1740759767  8 User I/O     26      1
  注意這裡有關會話等待的大量信息。現在您知道了,該會話已經為與應用程序相關的等待等待了 873 次(共 261,537 厘秒),在與網絡相關的事件中等待了 15 次等等。
  
  以此類推,您可以使用以下查詢來查看系統范圍的等待類的統計數據。同樣,時間是以厘秒為單位的。
  
  select * from v$system_wait_class;
  
  WAIT_CLASS_ID WAIT_CLASS# WAIT_CLASS  TOTAL_WAITS TIME_WAITED
  ------------- ----------- ------------- ----------- -----------
  1893977003   0 Other        2483    18108
  4217450380   1 Application     1352   386101
  3290255840   2 Configuration     82     230
  3875070507   4 Concurrency      80     395
  33864003
From:http://tw.wingwit.com/Article/program/Oracle/201311/16917.html
    推薦文章
    Copyright © 2005-2013 電腦知識網 Computer Knowledge   All rights reserved.