Oracle在11g的版本中已经对可诊断性功能进行了大量改进，而在Oracle 11g版本之前诊断事件的语法的比较有限的，11g的版本中的内核调试和诊断功能已经让我们可以更详细精确地的查看到跟踪和转储诊断信息，在oracle 12c的新版本中，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进行测试了解。

描述：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”的等待的时长来配合分析。

这样配合的话我们可以进行跟踪对比每次出现问题等待事件时其执行情况，包括时长等，再查看其调用堆栈信息是否与正常时有无差别。特别是在针对单个等待事件的跟踪，这样是非常方便的。

sql_monitorevent to force monitoring SQL statements

sql_monitor_testevent 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 namesql_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 namesql_monitor_test

sql_monitor_test: event to testSQL monitoring

Usage

-------

sql_monitor_test

level<ub4>

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

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

以上也是可以正常设置了，但可能受环境影响或者方式正确，没有生成相关的信息，苦于无法找到更多的相关描述的资料，因此关于该新的功能仍需进一步研究。

Event used to injectfaultinRDBMSkernel

从描述看来，是用来向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日志也没有告警，这更无法去探究其真正用途了。

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