oracle 12c 新增的診斷事件的初步嘗試

Oracle 在11g的版本中已 經對 可 診 斷 性功能 進 行了大量改 進 ，而在Oracle 11g版本之前 診 斷 事件的 語 法的比 較 有限的，11g的版本中的核心 除錯 和 診 斷 功能已 經讓 我 們 可以更 詳細 精確地的 查 看到跟蹤和 轉儲 診 斷 資訊，在oracle 12c的新版本中，oracle 繼續對 診 斷 功能 進 行 優 化改 進 ，並且提供了更加 實 用性的功能，以更加方便我 們進 行故障 診 斷 和 處 理。

一.關於oracle 診 斷 事件的介 紹 ：

在 MOS 文件中《 Introduction to ORACLE Diagnostic EVENTS ( 文件  ID 218105.1) 》 對 oracle 診斷事件 做了一些介 紹 ，以下 僅簡單進 行介 紹 ，本文的重點是介 紹 oracle 12c  中新增的 診 斷 事件功能。

 

Introduction to ORACLE Diagnostic EVENTS

----------------------------------------

1. 診 斷 事件主要當沒有足 夠 的資訊來解決 某個 的 問題 用於生成更多的 診 斷 資訊。

2. 診 斷 事件也用於通 過 更改 Oracle 的行 為 或啟用某些未 記錄 的特性來解決某些 問題。

 

Setting EVENTS

--------------

有多種方式可以 設 置事件。

設 置事件要取決於事件的性 質 和當 時的情況。 ORACLE 一再 強調設 置事件 應 有明確的 Oracle 支援服 務 或相關文章 為 依據。切 記 生 產 系 統 中不要隨意 設 置使用。

大多數事件可以使用以下多種方法 設 置：

(1)      通 過 初始化引數 ：

EVENT = "<event_name><action>"

(2)      通 過 當前會 話 ：

ALTER SESSION SET EVENTS '<event_name><action>';

(3)      使用 除錯 工具

o ORADEBUG

oradebug event <event_name><action>

      o ORAMBX (VMS only)

 

EVENT Categories

----------------

最常用的事件具體分 為以下 四 類 ：  :

o 根據要求 轉儲出 診 斷 資訊 (Immediate Dump)

例如可以 轉儲 出以下相關資訊： SYSTEMSTATE, ERRORSTACK, CONTROLF, FILE_HDRS and REDOHDR

o  發生錯誤時轉儲診斷信 息 (On-Error Dump)

例如當某個ora 錯誤發 生 時 dump 出 現 相關資訊： EVENT "942 trace name ERRORSTACK level 3"

o  改 變 oracle 的行 為

常用解決某些缺陷或啟用某些 隱 藏的功能 。

o 在 實 例執行 時 生成跟蹤 診 斷 資訊 (Trace Events)

例如 ：10046

EVENT = "10046 trace name context forever, level 12"

以下分別 通 過 命令oradebug doc event name 可以檢視查詢oracle 11g 和12c版本支援的event列表：

oracle 11g 中的部分 診 斷 事件功能：

oracle 12c  中的部分 診 斷 事件功能（ 紅 色框中 為 12c 新增的events）：

從以上所 查詢 的 結 果可以看出 oracle 12c events in library RDBMS 增加了 不了events，實際上即使是11g在日常的資料庫運維中我們真正會使用的非常少，因此也無法都瞭解熟悉，我選取了部分新新增的event 進行測試瞭解。

1. 診斷事件：wait_event[]

描述：event to control wait event post-wakeup actions

從關於 該 事件的解 釋 可以初步估 計 其 與資料庫中 等待事件有關，看起來 是 與某些等待事件 喚 醒之後的某些 動 作有關。

oracle 提供了 診 斷 事件的功能，但 實際 關於其的 詳細 描述的 資 料非常少，在之前 讀過 某個案例是 剛 好使用12c的 這 個新功能去 診 斷 了一個“log file sync”的 問題 ， 該問題 在oracle 12.1.0.1版本上，用 戶 會 話長時間 的等到“log file sync”，儘管當 時 沒有出 現 “log file parallel write” 的等待 時間 異常以及在“log buffer”也沒有明 顯 的爭用等。

     在 該 案例中，作者通 過該 新功能 單 獨 獲 取了log file sync等待的 調 用堆 棧 跟蹤資訊去弄清楚Oracle在出 現 此 問題時 執行的函式 調 用 順 序以及呼叫的是否是異常函式。

如果在12c之前需要 獲 取同 樣 的資訊，可能通 過像 Solaris 上 DTrace 操作系 統 工具可以捕 獲 ，但是如果 僅針對 某個等待事件，那是其 實 是非常 難 的事，更何況在其他操作系 統 平臺下。

       於此，我 們 可以 嘗試 模 擬 使用 該 診 斷 事件來跟蹤等待事件。

使用以下命令 語 法 進 行跟蹤 調 用堆 棧資訊 ：

SQL> alter session set events 'wait_event["<wait event name>"]  trace("%s\n", shortstack())';

單 獨生成log file sync出 現 的call stack 資訊，根據 這 個資訊可以知道函式是被那些函式按照什麼 順 序 調 用的，以便 進 一步分析：

另外，以上可以配合開啟SQL 跟蹤功能去來跟蹤每個 “log file sync” 的等待的 時長 來配合分析。

這樣配合的話我們可以進行跟蹤對比每次出現問題等待事件時其執行情況，包括時長等，再檢視其呼叫堆疊資訊是否與正常時有無差別。特別是在針對單個等待事件的跟蹤，這樣是非常方便的。

 

2. 診斷事件：sql_monitor_test   

sql_monitor          event to force monitoring SQL statements

sql_monitor_test     event to test SQL monitoring

sql_monitor_test  看起像是基於sql_monitor的基礎再增加的功能，在原來就有的sql_monitor的作用是強制去監控某些sql語句，而sql_monitor_test的作用是測試SQL的監控。由於沒有其他相關的文件說明，這裡只能進行推算。

在此我能想到的應該與Oracle 11G後新增SQL MONITORING功能，透過SQL MONITORING可以知道整個SQL執行過程中消耗的哪一類資源最多，以及一個正在執行的SQL語句知當前執行到哪一步？ 還可以輕鬆獲取語句的繫結變數、監控索引的整個建立過程及建立完索引剩餘的工作量。

查詢 sql_monitor 的用法：

SQL> oradebug doc event name  sql_monitor sql_monitor: event to force monitoring SQL statements Usage ------- sql_monitor    recursive       < false | true >,    force           < false | true >

recursive ：應該是一併監控sql的遞迴sql,force也即是強制的意思。

由於沒有更多詳細的文件說明，我只能借鑑sql_trace的用法，可以指定某個sql_id進行設定。

sql_trace 用例語法：

ALTER session SET EVENTS 'sql_trace [sql: sql_id=56bs32ukywdsq] bind=true, wait=true';

的借鑑語法

ALTER system SET EVENTS 'sql_monitor [sql:sql_id=56bs32ukywdsq] recursive = true , force = true';

在資料庫中可以執行成功，說明語法應該沒問題，設定之後應該就可以強制的針對一些sql進行監控了。

而在10G資料庫中執行以上命令oracle是無法識別的應該是不支援的。

而再根據event的描述，sql_monitor_test僅僅是用於做一個SQL monitoring的測試。

的用法：

SQL> oradebug doc event name  sql_monitor_test   sql_monitor_test: event to test    Usage ------- sql_monitor_test    level           <ub4>

 

按照以上，其開啟診斷事件可以透過以下命令。

sql_monitor_test [sql:sql_id=f3yfg50ga0r8n]level 12';

以上也是可以正常設定了，但可能受環境影響或者方式正確，沒有生成相關的資訊，苦於無法找到更多的相關描述的資料，因此關於該新的功能仍需進一步研究。

 

 

3. 診斷事件：fault

Event used to inject  in   kernel

從描述看來，是用來向RDBMS核心注入故障，難道是透過設定事件使資料庫產生故障？我想可能性不大，目前看來也無法真正瞭解其真正的用途,再擔當描述來看不應該是屬於追蹤作用，也許是在某些特殊場景下規避某些問題。

而其使用方法也是進行需要設定event成 fault，我在自己的實驗環境上進行測試，建議千萬不要在生成環境進行操作。

SQL> oradebug doc event name fault   fault: Event used to inject fault in RDBMS kernel   Usage -------

 

'fault’;

執行之後並無出現任何異常，沒有生成任何trace檔案，alert日誌也沒有告警，這更無法去探究其真正用途了。

awrdiag[]     AWR Diagnostic Event

我較為感興趣的是awrdiag[]，從描述來看是AWR相關的診斷事件，我猜想是否是對某些物件或操作做某些awr的診斷，但檢視其使用語法：

SQL> oradebug doc event name awrdiag[] Error: " " not a known event/library name Use <event_name>, <library_name> or <library_name>.<event_name>

    其引數內容要使用<event_name>, <library_name>難道這裡的event_name指的是診斷事件名，而library_name指的是其歸類庫，例如我們所看到的Events in library RDBMS，但我嘗試去使用語句去執行後是錯誤的。

而報出ora-49115說明event的目標沒有指定，對於awrdiag[]目前還未找到的相關的其他說明，因此就沒有繼續進行分析。

三.小結：

oracle 在12c 版本新增不上新的特性，同時也對原來的某些功能進行改進新增。實際上，某些oracle診斷事件的功能一般都只在某些極端的情況下才使用，oracle對此部分的功能沒有公開更多的說明，我們只能憑著嘗試的角度去了解它們，實際某些新增的功能具有很大的意義，從此次對oracle 12c 新增一些的診斷事件的初步瞭解過程中，發現wait_event[] 事件對我們來說作用較大，特別是在遇到某些較為疑難的的等待事件問題上。