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"

二.oracle 12c新增的診斷事件：

以下分別 通 過 命令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 的用法：

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

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

sql_trace 用例語法：

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

sql_monitor 的借鑒語法

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

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

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

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

sql_monitor_test 的用法：

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

ALTER system SET EVENTS ' sql_monitor_test [sql:sql_id=f3yfg50ga0r8n]level 12';

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

3. 診斷事件：fault

Event used to inject  fault  in  RDBMS  kernel

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

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

ALTER system SET EVENTS  'fault’;

執行之后并無出現任何異常，沒有生成任何trace文件，alert日志也沒有告警，這更無法去探究其真正用途了。

4.        其他診斷事件

awrdiag[]     AWR Diagnostic Event

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

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

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

三.小結：

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