Oracle Database 10 g : 為 DBA 提供的最佳前 20 位的特性（十一）

2024-08-29 13:46:59

字體：大中小

供稿：網(wǎng)友

Oracle Database 10 g : 為 DBA 提供的最佳前 20 位的特性（十一） 作者 Arup Nanda 來源： OTN 第 11 周
等待界面 10 g 等待界面為還沒有被 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)整工具，之所以如此說，至少是因為以下兩個重要原因：

該視圖是當(dāng)前情況的一個快照。當(dāng)?shù)却辉俅嬖跁r，會話先前出現(xiàn)的那些等待的歷史也將消失，從而使得事后診斷非常困難。 V$SESSION_EVENT 提供了累積的但不是非常具體的數(shù)據(jù)。
V$SESSION_WAIT 包含了只與等待事件相關(guān)的信息；要獲得所有其它的相關(guān)信息（如用戶 ID 和終端），您必須將它和 V$SESSION 視圖結(jié)合使用。

在 Oracle 數(shù)據(jù)庫 10 g 中，等待界面經(jīng)過了徹底的重新設(shè)計，從而只需更少的 DBA 干預(yù)即可提供更多的信息。在本文中，我們將瀏覽這些新的特性，并了解它們?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 是 10 g 中新增的列。列 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 　　　　　　　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 事件。您可以將它們作為非阻塞等待消除掉；不過，有時這些 “ 空閑 ” 事件可能指示一個內(nèi)在的問題。例如，與 SQL*Net 相關(guān)的事件可能指示高網(wǎng)絡(luò)延遲（除其他因素外）。另一件要注重的重要的事情是， WAIT_TIME 的值為 -2 。某些平臺（如 Windows ）不支持快速計時機制。假如在這些平臺上沒有設(shè)定初始化參數(shù) TIMED_STATISTICS ，那么將無法獲得準確的計時統(tǒng)計數(shù)據(jù)。在這種情況下，在 Oracle9 i 中，該列將顯示一個非常大的數(shù)字，這使問題變得更加不清楚。在 10 g 中，值 -2 指示這種情況 — 平臺不支持快速定時機制并且沒有設(shè)定 TIMED_STATISTICS 。（對于本文剩下的部分，我們將假定存在一個快速計時機制。） 會話也顯示等待 記得長期以來一直需要將 V$SESSION_WAIT 與 V$SESSION 結(jié)合使用以獲得有關(guān)會話的其他具體信息嗎？嗯，這已經(jīng)成為歷史了。在 10 g 中， V$SESSION 視圖還顯示由 V$SESSION_WAIT 顯示的等待。下面是 V$SESSION 視圖其余的列，這些列顯示了會話當(dāng)前等待的等待事件。 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 ，指示它正等待被另一個會話占用的鎖。要診斷該問題，您必須識別占用鎖的那個會話。但您如何才能做到這一點？在 Oracle9 i 及更低版本中，您可能得編寫復(fù)雜（和極耗資源）的查詢來獲得占用鎖的會話的 SID 。而在 10 g 中，您所要做的就是執(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)為與應(yīng)用程序相關(guān)的等待等待了 873 次（共 261,537 厘秒），在與網(wǎng)絡(luò)相關(guān)的事件中等待了 15 次等等。以此類推，您可以使用以下查詢來查看系統(tǒng)范圍的等待類的統(tǒng)計數(shù)據(jù)。同樣，時間是以厘秒為單位的。 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 3386400367 　　　　　　　5 Commit 　　　　　　　　2625 　　　　 1925 2723168908 　　　　　　　6 Idle 　　　　　　　　645527 　　219397953 2000153315 　　　　　　　7 Network 　　　　　　　　2125 　　　　　　2 1740759767 　　　　　　　8 User I/O 　　　　　　　 5085 　　　　 3006 4108307767 　　　　　　　9 System I/O 　　　　　 127979 　　　　18623 大多數(shù)問題不是孤立出現(xiàn)的；它們留下了揭示真相的線索，模式可以識別這些線索。可以按如下方式從等待類的一個歷史視圖中查看模式。 select * from v$waitclassmetric; 這個視圖存儲了最后一分鐘內(nèi)與等待類相關(guān)的統(tǒng)計數(shù)據(jù)。 select wait_class#, wait_class_id, average_waiter_count "awc", dBTime_in_wait, time_waited, wait_count from v$waitclassmetric / WAIT_CLASS# WAIT_CLASS_ID AWC DBTIME_IN_WAIT TIME_WAITED WAIT_COUNT ----------- ------------- ---- -------------- ----------- ---------- 　　　　　0 　　1893977003 　　0 　　　　　　　0 　　　　　0 　　　　　1 　　　　　1 　　4217450380 　　2 　　　　　　 90 　　　 1499 　　　　　5 　　　　　2 　　3290255840 　　0 　　　　　　　0 　　　　　4 　　　　　 3 　　　　　3 　　4166625743 　　0 　　　　　　　0 　　　　　0 　　　　　 0 　　　　　4 　　3875070507 　　0 　　　　　　　0 　　　　　0 　　　　　 1 　　　　　5 　　3386400367 　　0 　　　　　　　0 　　　　　0 　　　　　 0 　　　　　6 　　2723168908 　 59 　　　　　　　0 　　 351541 　　　　 264 　　　　　7 　　2000153315 　　0 　　　　　　　0 　　　　　 0 　　　　　25 　　　　　8 　　1740759767 　　0 　　　　　　　0 　　　　　 0 　　　　　 0 　　　　　9 　　4108307767 　　0 　　　　　　　0 　　　　　 8 　　　　 100 　　　　 10 　　2396326234 　　0 　　　　　　　0 　　　　　 0 　　　　　　0 　　　　 11 　　3871361733 　　0 　　　　　　　0 　　　　　 0 　　　　　　0 注重 WAIT_CLASS_ID 和相關(guān)的統(tǒng)計數(shù)據(jù)。對于值 4217450380 ，我們看到 2 個會話在最后一分鐘內(nèi)總共等待了該類 5 次（ 1,499 厘秒）。但該等待類是什么？您可以從 V$SYSTEM_WAIT_CLASS 中獲取這一信息（如上所示） — 就是 Application 類。注重名稱為 DBTIME_IN_WAIT 的列，這是一個非常有用的列。在我們第 6 周關(guān)于自動工作負載信息庫 (AWR) 的部分中，您可能還記得在 10 g 中是以更細粒化的方式來報告時間的，并且可以確定在數(shù)據(jù)庫中花費的準確時間。 DBTIME_IN_WAIT 顯示在數(shù)據(jù)庫中花費的時間。 一切都留有線索 用戶終于離開了，您長舒了一口氣。但您可能仍然想尋根究底，希望查明主要是哪些等待造成用戶會話中的問題。當(dāng)然，您可以通過查詢 V$SESSION_WAIT 而輕易地得到答案 — 但不幸的是，等待事件現(xiàn)在不存在了，因此該視圖沒有它們的任何記錄。您該怎么辦？
在 10 g 中，自動保留活動會話最后 10 個事件的會話等待歷史。這個歷史可通過 V$SESSION_WAIT_HISTORY 視圖查看。要找出這些事件，您可以簡單地執(zhí)行： select event, wait_time, wait_count from v$session_wait_history where sid = 265 / EVENT 　　　　　　　　　　　　　　WAIT_TIME WAIT_COUNT ------------------------------ ---------- ---------- log file switch completion 　　　　　2 　　　　1 log file switch completion 　　　　　1　　　　 1 log file switch completion 　　　　　0　　　　 1 SQL*Net message from client 　　49852 　　　　 1 SQL*Net message to client 　　　　　0 　　　　　1 enq:TX - row lock contention 　　　28 　　　　　1 SQL*Net message from client 　　　131 　　　　1 SQL*Net message to client 　　　　　0 　　　　　1 log file sync 　　　　　　　　　　　2 　　　　　1 log buffer space 　　　　　　　　　　1 　　　　　1 當(dāng)會話變?yōu)榉腔顒訝顟B(tài)或斷開時，記錄從該視圖中消失。不過，這些等待的歷史保留在 AWR 表中，以便進一步分析。從 AWR 中顯示會話等待的視圖是 V$ACTIVE_SESSION_HISTORY 。（同樣，有關(guān) AWR 的更多信息，請參考本系列的第 6 周。） 結(jié)論 通過 Oracle 數(shù)據(jù)庫 10 g 中的等待模型的增強，分析性能問題變得非常輕易。提供的會話等待歷史可以幫助您在會話經(jīng)歷等待后診斷問題。將等待歸為各種等待類還有助于您了解每種類型等待所造成的影響，這在研究正確的糾正方法時將帶來便利。有關(guān)等待事件動態(tài)性能視圖和等待事件本身的更多信息，請參考《 Oracle 數(shù)據(jù)庫性能調(diào)整指南 10g 第 1 版 (10.1) 》的第 10 章。

上一篇：Oracle Database 10 g : 為 DBA 提供的最佳前 20 位的特性（十）

下一篇：Oracle Database 10 g : 為 DBA 提供的最佳前 20 位的特性（九）