Oracle10g數(shù)據(jù)庫最佳新特性：等待界面

2024-08-29 13:51:01

字體：大中小

供稿：網(wǎng)友

Oracle10g等待界面為還沒有被ADDM 捕捉的即時性能問題提供了有價值的診斷數(shù)據(jù)。 “數(shù)據(jù)庫太慢了！” 這句話通常出自一位嚴格的用戶之口。假如您和我一樣，那么在您的 DBA 生涯中您肯定無數(shù)次聽到過這句話。那么，您又怎樣解決該問題呢？除了對用戶置之不理之外（這是我們大多數(shù)人都不敢奢望的想法），您可能要做的第一件事就是查看是否有任何會話在等待數(shù)據(jù)庫內(nèi)部或外部的任何事件。 Oracle 提供了一個簡單但一流的機制來達到此目的：V$session_WAIT 視圖。該視圖顯示了有助于您的診斷的各種信息，如一個會話正在等待或已經(jīng)等待的事件，以及等待了多長時間和多少次。例如，假如會話在等待事件 "db file sequential read"，列 P1 和 P2 將顯示會話正在等待的塊的 file_id 和 block_id。對于大多數(shù)等待事件而言，這個視圖足夠了，但它還不是一個強健的調(diào)整工具，之所以如此說，至少是因為以下兩個重要原因：該視圖是當前情況的一個快照。當?shù)却辉俅嬖跁r，會話先前出現(xiàn)的那些等待的歷史也將消失，從而使得事后診斷非常困難。V$SESSION_EVENT 提供了累積的但不是非常具體的數(shù)據(jù)。 V$SESSION_WAIT 包含了只與等待事件相關(guān)的信息；要獲得所有其它的相關(guān)信息（如用戶 ID 和終端），您必須將它和 V$SESSION 視圖結(jié)合使用。在 Oracle 數(shù)據(jù)庫 10g 中，等待界面經(jīng)過了徹底的重新設計，從而只需更少的 DBA 干預即可提供更多的信息。在本文中，我們將瀏覽這些新的特性，并了解它們?nèi)绾螏椭覀冊\斷性能問題。對于大多數(shù)性能問題，您可以從自動數(shù)據(jù)庫診斷治理器 (ADDM) 中獲得擴展分析，但對于還沒有被 ADDM 捕捉的即時問題，等待界面將提供有價值的診斷數(shù)據(jù)。增強的會話等待第一個增強涉及到 V$SESSION_WAIT 本身。這一點通過示例可以很好地說明。假定您的用戶抱怨會話掛起了。您查明了該會話的 SID，并在 V$SESSION_WAIT 視圖中選中了該 SID 的記錄。輸出顯示如下。

　　　　SID　　　　　　　　　　　: 269　　SEQ#　　　　　　　　　　 : 56　　EVENT　　　　　　　　　　:enq:TX - row lock contention　　P1TEXT　　　　　　　　　 :namemode　　P1　　　　　　　　　　　 : 1415053318　　P1RAW　　　　　　　　　　: 54580006　　P2TEXT　　　　　　　　　 :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 中新增的列。列 WAIT_CLASS 指示等待的類型，必須將其作為有效的等待事件解決或者作為空閑的等待事件退出。在上面的例子中，等待類顯示為 Application，這表示它是一個需要您注重的等待。該列突出顯示那些能夠證實與您的調(diào)整最相關(guān)的少數(shù)幾條記錄。例如，您可以使用如下查詢來獲取事件的等待會話。

　　　　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　　73row lock contention　　　　Idle　　　　Queue Monitor Wait　　　　　270 WAITING　　　　　 0　　40Idle　　　　SQL*Net message from client 265 WAITING　　　　　　0　　73Idle　　　　jobq slave wait　　　　　　 259 WAITING　　　　　　0　　8485Idle　　　　pmon timer　　　　　　　　　280 WAITING　　　　　　0　　73Idle　　　　rdbms ipc message　　　　　 267 WAITING　　　　　　0　　184770Idle　　　　wakeup time manager　　　　 268 WAITING　　　　　　0　　40Network　　 SQL*Net message to client　 272 WAITED SHORT TIME -1　　0

在這，您可以看到幾個事件（如 Queue Monitor Wait 和 JobQueue Slave）被明確地歸為 Idle 事件。您可以將它們作為非阻塞等待消除掉；不過，有時這些“空閑”事件可能指示一個內(nèi)在的問題。例如，與 SQL*Net 相關(guān)的事件可能指示高網(wǎng)絡延遲（除其他因素外）。另一件要注重的重要的事情是，WAIT_TIME 的值為 -2。某些平臺（如 Windows）不支持快速計時機制。假如在這些平臺上沒有設定初始化參數(shù) TIMED_STATISTICS，那么將無法獲得準確的計時統(tǒng)計數(shù)據(jù)。在這種情況下，在 Oracle9i 中，該列將顯示一個非常大的數(shù)字，這使問題變得更加不清楚。在 10g 中，值 -2 指示這種情況 — 平臺不支持快速定時機制并且沒有設定 TIMED_STATISTICS。（對于本文剩下的部分，我們將假定存在一個快速計時機制。）會話也顯示等待記得長期以來一直需要將 V$SESSION_WAIT 與 V$SESSION 結(jié)合使用以獲得有關(guān)會話的其他具體信息嗎？嗯，這已經(jīng)成為歷史了。在 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 中，您所要做的就是執(zhí)行以下查詢：

　　　　select BLOCKING_SESSION_STATUS, BLOCKING_SESSION　　from v$session 　　where sid = 269　　　　BLOCKING_SE BLOCKING_SESSION　　----------- ----------------　　VALID　　　　　　　　　　265

找到了：SID 為 265 的會話阻塞了會話 269。還能更輕易嗎？用戶仍然在纏著您，因為用戶的問題仍然沒有得到滿足的解答。為什么用戶的會話花了這么長時間才完成？您可以執(zhí)行以下命令來找出原因：

　　　　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

注重這里有關(guān)會話等待的大量信息。現(xiàn)在您知道了，該會話已經(jīng)為與應用程序相關(guān)的等待等待了 873 次（共 261,537 厘秒），在與網(wǎng)絡相關(guān)的事件中等待了 15 次等等。

上一篇：Oracle數(shù)據(jù)庫中物化視圖的原理剖析

下一篇：Oracle數(shù)據(jù)庫物理文件大小的限制簡介