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 的用法：

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';

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 的用法：

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

 

按照以上，其开启诊断事件可以通过以下命令。

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，我在自己的实验环境上进行测试，建议千万不要在生成环境进行操作。

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

 

ALTER system SET EVENTS  'fault’;

执行之后并无出现任何异常，没有生成任何trace文件，alert日志也没有告警，这更无法去探究其真正用途了。

4.        其他诊断事件

awrdiag[]     AWR Diagnostic Event

我较为感兴趣的是awrdiag[]，从描述来看是AWR相关的诊断事件，我猜想是否是对某些对象或操作做某些awr的诊断，但查看其使用语法：

SQL> oradebug doc event name awrdiag[] Error: " awrdiag[] " 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[] 事件对我们来说作用较大，特别是在遇到某些较为疑难的的等待事件问题上。