Script:列出本会话的细节信息

以下脚本可以用于列出本会话(local session)的sid、pid、spid、trace 路径等有用信息; 因为不依赖于dbms_session等包体,所以仅需要select_catalog_role的角色即可执行,更为灵活。

 

 

set serveroutput on
set linesize 200 pagesize 1400
set time on
declare
  l_audsid number;
  l_sid    number;
  l_serial number;
  l_module varchar2(128);
  l_pid    number;
  l_spid   number;
  l_trace  varchar2(2000);
  l_user   varchar2(128);
begin
  DBMS_APPLICATION_INFO.SET_MODULE(module_name => 'Maclean Liu OppO',
                                   action_name => 'ACTIVE');
  select audsid, sid, SERIAL#, module,username
    into l_audsid, l_sid, l_serial, l_module,l_user
    from v$session
   where sid = (select distinct sid from v$mystat);
  select pid, spid
    into l_pid, l_spid
    from v$process
   where addr = (select paddr
                   from v$session
                  where sid = l_sid
                    and serial# = l_serial);
  SELECT d.VALUE || '/' || LOWER(RTRIM(i.INSTANCE, CHR(0))) || '_ora_' ||
         p.spid || '.trc'
    into l_trace
    FROM (SELECT p.spid
            FROM v$mystat m, v$session s, v$process p
           WHERE m.statistic# = 1
             AND s.SID = m.SID
             AND p.addr = s.paddr) p,
         (SELECT t.INSTANCE
            FROM v$thread t, v$parameter v
           WHERE v.NAME = 'thread'
             AND (v.VALUE = 0 OR t.thread# = TO_NUMBER(v.VALUE))) i,
         (SELECT VALUE FROM v$parameter WHERE NAME = 'user_dump_dest') d;

  dbms_output.enable(9999999);
  dbms_output.put_line('===============================================');
  dbms_output.put_line(' USERNAME=' || l_user);
  dbms_output.put_line(' SESSION ID=' || l_sid || '  SERIAL#=' || l_serial);
  dbms_output.put_line(' AUDSID=' || l_audsid || '      MODULE#=' ||
                       l_module);
  dbms_output.put_line(' PID=' || l_pid || '          SPID#=' || l_spid);
  dbms_output.put_line(' TRACE_FILE_LOCATION=' || l_trace);
  dbms_output.put_line('===============================================');
  commit;
end;
/

Oracle Internal Event:10200 Consistent Read诊断事件

10200(consistent read buffer status)内部诊断事件可以用于探测一致性读CR(consistent read)块的访问情况,虽然cr读的统计信息可以从v$sysstat或AWR/statspack中获取,但是10200 event还是我们研究Consistent Read一致性读的有力工具。该事件可以通过在会话session级别设置ALTER SESSION SET EVENTS 或 DBMS_SYSTEM.SET_EV. Set 来开启,一般调用级别为Level 10。

该事件返回的trace跟踪文件,记录了为了实现一致性读的目的,哪些数据块以及这些块的各历史版本在执行过程中被创建(CR block creation)并检验(CR block inspection),以找出Best CR block满足Consistent一致性。

注意10200 Internal Event主要是被ktrgtc和ktrget(call ktrget to get one block ->calling KTR layer to apply RBS to have consistent read Block;)这2个Oracle内核功能函数触发,这2个内部函数Internal Function的主要作用:

ktrget:

  • Initializes a buffer cache CR scan request
  • Calls kcbgtcr for the best resident buffer to start from to build the CR buffer
  • Calls ktrgcm to build the CR buffer by applying undo
  • Returns CR buffer to the requestor

kcbgtcr:

  • If successful, returns the “best” candidate (performed by ktrexf or examination function)
  • Scans the hash bucket for the DBA for buffers that may be used to build a CR buffer
  • If not successful, calls kcbget

 

10200 event trace example:

 

[oracle@rh2 ~]$ sqlplus / as sysdba

SQL*Plus: Release 10.2.0.4.0 - Production on Fri Sep 30 21:23:47 2011

Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.

Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing option

SQL> select * from global_name;

GLOBAL_NAME
--------------------------------------------------------------------------------
www.askmaclean.com & www.askmaclean.com

SQL> create table tv(t1 int);

Table created.

SQL> alter session set events '10200 trace name context forever,level 10';

Session altered.

SQL> select * from tv;

        T1
----------
         1

10200 trace

Consistent read started for block 0 : 0040081a
  env: (scn: 0x0000.000cf852 xid: 0x0000.000.00000000 uba: 0x00000000.0000.00  statement num=0

parent xid: xid: 0x0000.000.00000000  scn: 0x0000.00000000 8sch: scn: 0x0000.00000000)
 CR exa ret 2 on: 0x600139d0  scn: 0xffff.ffffffff  xid: 0x0000.000.00000000  uba: 0x00000000.0000.00

scn: 0xffff.ffffffff  sfl: 0

Consistent read finished for block 0 : 40081a

Consistent read started for block 0 : 0040e508
  env: (scn: 0x0000.000cf852  xid: 0x0000.000.00000000  uba: 0x00000000.0000.00  statement num=0
parent xid: xid: 0x0000.000.00000000  scn: 0x0000.00000000 8sch: scn:
 0x0000.00000000)
Consistent read finished for block 0 : 40e508

 

以上trace中各代码的含义如下:

Consistent read started for block 0 : 0040081a
0 -> tablespace number 0040081a -> DBA

 

env: (scn: 0x0000.000cf852 xid: 0x0000.000.00000000 uba: 0x00000000.0000.00
以上为环境/会话信息,这个scn是env_scn ,一般就是数据库的current_scn

 

SFL :0  -> SFL 为 Snapshot Flag

 

CR exa ret 2 -> 此处的ret为reture code返回代码,是ktrgtc/ktrget函数的返回码

 

以下为ktrgtc/ktrget函数部分可能返回代码的含义:

 

#define KCBRSTOP (8|0) /* return this one now */
#define KCBRSAVE (8|1) /* save this one and continue */
#define KCBRSKIP (0|1) /* skip over this one and continue */
#define KCBRQUIT (0|2) /* chuck all, return nothing and stop */
#define KCBRLAST (0|3) /* quit if read from disk else skip */

 

10200诊断事件在11g中得到了加强,通过该event我们可以获得更多有用的trace信息了:

 

SQL> select * from v$version;

BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
PL/SQL Release 11.2.0.3.0 - Production
CORE    11.2.0.3.0      Production
TNS for Linux: Version 11.2.0.3.0 - Production
NLSRTL Version 11.2.0.3.0 - Production

SQL> select * from global_name;

GLOBAL_NAME
--------------------------------------------------------------------------------
MACLEAN

SQL> alter session set events '10200 trace name context forever, level 10';

Session altered.

SQL> select * from tv;

        T1
----------
         1

SQL> oradebug setmypid;
Statement processed.

SQL> oradebug tracefile_name;
/s01/orabase/diag/rdbms/vprod/VPROD1/trace/VPROD1_ora_28365.trc

trace content

ktrget2(): started for block   objd: 0x000040e1
env [0x2b54cde2a704]: (scn: 0x0000.0026b064  xid: 0x0000.000.00000000  uba: 0x00000000.0000.00
statement num=0  parent xid: 0x0000.000.00000000  st-scn: 0x0000.00000000  hi-scn: 0x0000.00000000
ma-scn: 0x0000.0026b053  flg: 0x00000660)
ktrexf(): returning 9 on:  0xbb132d0  cr-scn: 0xffff.ffffffff  xid: 0x0000.000.00000000
uba: 0x00000000.0000.00  cl-scn: 0xffff.ffffffff  sfl: 0
ktrgcm(): completed for block   objd: 0x000040e1
ktrget3(): completed for  block  objd: 0x000040e1

Discover Your Missed ASM Disks

经常有网友在构建10g/11g中ASM存储环境的时候遇到ASM磁盘无法识别的问题,虽然已经为存储设备赋予了适当的权限,也为ASM实例修改了asm_diskstring初始化参数,可是在DBCA的ASM Diskgroup创建页面里就是无法显示候选的ASM Disk磁盘。

实际上因为ASM存储方式比起裸设备或GPFS来说更为黑盒,我们也无法利用ASM instance中的一些动态性能视图或内部视图来排查造成这一问题的原因,使得这类问题显得十分棘手。

下面我来介绍一种使用操作系统调用追踪工具来排查ASM无法找到磁盘问题的方法。

[oracle@vrh1 raw]$ cd /dev/rdsk 

/* 演示中我们要用到的三个裸设备位于/dev/rdsk下 */

[oracle@vrh1 rdsk]$ ls
hdisk1  hdisk2  hdisk3

[oracle@vrh1 rdsk]$ sqlplus / as sysdba

SQL> select * from v$version;

BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Prod
PL/SQL Release 10.2.0.4.0 - Production
CORE    10.2.0.4.0      Production
TNS for Linux: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production

SQL>  select path from v$asm_disk;
no rows selected

SQL> alter system set asm_diskstring='/dev/rdsk/hdisk*';
System altered.

SQL> select * from v$asm_disk;
no rows selected

/* 以上虽然设置了asm_diskstring参数,ASM instance依然无法在指定路径下找到合适的设备
    这是为什么呢?!
*/

[oracle@vrh1 rdsk]$ ps -ef|grep rbal|grep -v grep
oracle   31375     1  0 15:40 ?        00:00:00 asm_rbal_+ASM1

/* 找出当前ASM实例中的rbal后台进程  */

/* 针对该后台进程做系统调用的trace,一般Linux上使用strace,而Unix上使用truss */

strace -f -o /tmp/asm_rbal.trc -p $OS_PID_OF_RBAL_BGPROCESS
truss  -ef -o /tmp/asm_rbal.trc -p $OS_PID_OF_RBAL_BGPROCESS

[oracle@vrh1 rdsk]$ strace -f -o /tmp/asm_rbal.trc  -p 31375
Process 31375 attached - interrupt to quit

/* 在另外一个终端窗口中打开sqlplus登录ASM实例,执行对v$ASM_DISK或者X$KFDSK的查询 */

SQL> select * from x$kfdsk;

no rows selected

/* 完成以上查询后使用Ctrl+C中断strace命令,并分析生成的system call trace */

/* 因为在不同Unix平台上rbal后台进程可能使用不同的system call function函数以达到相同的目的,
    所以在你的平台上可能并不像在Linux上使用open和access2个关键词搜索就可以得到答案了!     */

[oracle@vrh1 rdsk]$ cat /tmp/asm_rbal.trc |egrep "open|access"
31375 open("/dev/rdsk", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 15
31375 access("/dev/rdsk/hdisk3", R_OK|W_OK) = -1 EACCES (Permission denied)
31375 access("/dev/rdsk/hdisk2", R_OK|W_OK) = -1 EACCES (Permission denied)
31375 access("/dev/rdsk/hdisk1", R_OK|W_OK) = -1 EACCES (Permission denied)

可以看到以上系统调用中使用access函数访问候选的hdisk*ASM磁盘设备时出现了”Permission denied”的问题,很显然是因为权限不足导致了ASM实例无法利用这部分的磁盘设备,我们来纠正这一问题后再次尝试:

[root@vrh1 ~]# chown oracle:dba /dev/rdsk/hdisk*

SQL> select path_kfdsk from x$kfdsk;

PATH_KFDSK
--------------------------------------------------------------------------------
/dev/rdsk/hdisk3
/dev/rdsk/hdisk2
/dev/rdsk/hdisk1

SQL> select path from v$asm_disk;

PATH
--------------------------------------------------------------------------------
/dev/rdsk/hdisk3
/dev/rdsk/hdisk1
/dev/rdsk/hdisk2

以上丢失ASM Disk诊断方法的原理是在查询v$asm_disk或者x$kfdsk视图时Oracle会让RBAL这个ASM特别的后台进程去访问asm_diskstring参数指定路径下的所有可用设备,只要我们了解了在访问过程中RBAL遭遇的问题,那么一般来说都可以很简单地予以解决,如果strace/truss也无法给予你任何启示的话,也许你不得不去提交一个SR让Oracle Support来进一步协助你了,当然在正式提交SR之前你有必要再次确认一下你的ASM Disk是否都满足了以下的这些硬指标:

1.合理地设置ASM_DISKSTRING参数,若没有设置ASM_DISKSTRING参数那么ASM实例会尝试到默认的一些路径去搜索磁盘设备,这些默认路径在不同操作系统上略有不同:

操作系统 默认搜索路径
Solaris /dev/rdsk/*
Windows \\.\orcldisk*
Linux /dev/raw/*
Linux with ASMLIB ORCL:*
Linux with ASMLIB /dev/oracleasm/disks/*
HPUX /dev/rdsk/*
HP-UX(Tru 64) /dev/rdsk/*
AIX /dev/*

2.候选磁盘设备应当属于安装ASM的Oracle软件的用户,否则使用chown或卷管理软件修改磁盘拥有者,并保证磁盘被正确加载

3.候选磁盘设备应当设置合理的权限,一般为660,如果存在问题那么可以临时设为770以便测试

4.RAC环境中需要注意所有的磁盘设备应当在所有节点都可见,建议使用cluvfy工具验证

Oracle中如何追踪savepoint

Oracle中的savepoint是事务中的标示符,以帮助我们做到部分操作的回滚。

我们可以通过trace找出会话中自上次commit以来所有的savepoint保存点,要阅读这些trace内容你需要有user_dump_dest目录的相关权限。

SQL> oradebug setmypid;
已处理的语句
SQL>
SQL>
SQL> insert into  system.linktest values(2);

已创建 1 行。

SQL> savepoint a;

保存点已创建。

SQL> insert into system.linktest values(3);

已创建 1 行。

SQL> savepoint b;

保存点已创建。

SQL> insert into system.linktest values(4);

已创建 1 行。

SQL> savepoint d;

保存点已创建。

SQL> oradebug event immediate trace name savepoints level 1;

已处理的语句
SQL> oradebug tracefile_name;
e:\oracle\product\10.2.0\admin\orcln\udump\orcln_ora_1756.trc

其中 oradebug setmypid;  表示要trace的session为当前会话。

在非mts环境下,我们也可以通过如:

oradebug setospid OSPID;         — 通过指定OS中的进程号,即v$process中的spid

oradebug setorapid ORAPID;      — 通过指定Oracle 中的进程号,即v$process中的pid

来定制我们需要trace的相关session。

退回到命令行格式,该trace主要内容如下:

*** 2009-09-15 12:39:37.828
*** SERVICE NAME:(SYS$USERS) 2009-09-15 12:39:37.828
*** SESSION ID:(151.83) 2009-09-15 12:39:37.828
====================================================
SAVEPOINT FOR CURRENT PROCESS
——————————
flag: 0x1
name: D
dba: 0x800084, sequence #: 177, record #: 51, savepoint #: 81
status: VALID, next: 28236068
name: B
dba: 0x800084, sequence #: 177, record #: 50, savepoint #: 66
status: VALID, next: 282373F4
name: A
dba: 0x800084, sequence #: 177, record #: 49, savepoint #: 52
status: VALID, next: 00000000

metalink中的相关介绍如下:

Subject:

How To Find Out The Savepoint For Current Process

Doc ID:

108611.1

Type:

BULLETIN

Modified Date:

16-JUN-2004

Status:

PUBLISHED

PURPOSE

——-

This information shows you how to get the savepoints you have

issued since the last commit was issued.

SCOPE & APPLICATION

——————-

Any user can follow the steps to find out the savepoints in

their own session.  However, only the the user who have read

permission to the user_dump_dest directory can view the

output.

Steps to Retrieve the Savepoint Issued after the Last Commit

————————————————————

In the following illustration, two savepoints are created in

the same session.  Then a savepoints dump is issued to get

the savepoint information.  An example of the dump file is

included.

SQL> insert into emp (empno, ename)

2  values (9995, ‘vso’);

1 row created.

SQL> savepoint pt1;

Savepoint created.

SQL> insert into emp (empno, ename)

2  values (9994, ‘vso’);

1 row created.

SQL> savepoint pt2;

Savepoint created.

SQL> alter session set events

2  ‘immediate trace name savepoints level 1’;

Session altered.

A trace file is generated in the user_dump_directory.  The

content of the trace file is included in the following:

Dump file /u04/app/oracle/admin/R805/udump/r805_ora_18763.trc

Oracle8 Enterprise Edition Release 8.0.5.2.1 – Production

With the Partitioning and Objects options

PL/SQL Release 8.0.5.2.0 – Production

ORACLE_HOME = /u04/app/oracle/product/8.0.5

System name:    SunOS

Node name:      rtcsol1

Release:        5.6

Version:        Generic_105181-17

Machine:        sun4u

Instance name: R805

Redo thread mounted by this instance: 1

Oracle process number: 8

Unix process pid: 18763, image: oracleR805

*** 2000.04.18.14.11.37.000

*** SESSION ID:(7.391) 2000.04.18.14.11.37.000

====================================================

SAVEPOINT FOR CURRENT PROCESS

——————————

flag: 0x1

name: PT2

dba: 0x80020e, sequence #: 0, record #: 9, savepoint #: 131

status: VALID, next: 10a0868

name: PT1

dba: 0x80020e, sequence #: 0, record #: 7, savepoint #: 109

status: VALID, next: 0

Trace obtained enqueue information by set event 10704

Oracle事件10704可以帮助我们了解队列Enqueue的使用情况,使用方法如下:

[oracle@rh2 bdump]$ oerr ora 10704
10704, 00000, "Print out information about what enqueues are being obtained"
// *Cause:  When enabled, prints out arguments to calls to ksqcmi and
//          ksqlrl and the return values.
// *Action: Level indicates details:
//   Level: 1-4: print out basic info for ksqlrl, ksqcmi
//          5-9: also print out stuff in callbacks:  ksqlac, ksqlop
//          10+: also print out time for each line

SQL> oradebug setmypid;
Statement processed.

SQL> oradebug event 10704 trace name context forever,level 10;
Statement processed.

SQL> lock  table tm in share mode;
Table(s) Locked.

SQL> oradebug tracefile_name;
/s01/admin/G10R2/udump/g10r2_ora_28400.trc

ksqgtl *** CU-9fec6e30-00000000 mode=6 flags=0x10 timeout=300 ***
ksqgtl: no transaction
ksqgtl: use existing ksusetxn DID
ksqgtl:
        ksqlkdid: 0001-0017-00000008
*** 2011-05-07 21:17:16.139
*** ksudidTrace: ksqgtl
        ksusesdi:   0000-0000-00000000
        ksusetxn:   0001-0017-00000008
ksqgtl: RETURNS 0
*** 2011-05-07 21:17:16.160
ksqrcl: CU,9fec6e30,0
ksqrcl: returns 0
*** 2011-05-07 21:17:23.884
ksqgtl *** CU-9fec69f8-00000000 mode=6 flags=0x10 timeout=300 ***
ksqgtl: no transaction
ksqgtl: use existing ksusetxn DID
ksqgtl:
        ksqlkdid: 0001-0017-00000008
*** 2011-05-07 21:17:23.884
*** ksudidTrace: ksqgtl
        ksusesdi:   0000-0000-00000000
        ksusetxn:   0001-0017-00000008
ksqgtl: RETURNS 0
*** 2011-05-07 21:17:23.898
ksqrcl: CU,9fec69f8,0
ksqrcl: returns 0
*** 2011-05-07 21:17:23.899
ksqgtl *** TM-0000d06b-00000000 mode=4 flags=0x401 timeout=21474836 ***
ksqgtl: xcb=0xa69d0a00, ktcdix=2147483647, topxcb=0xa69d0a00
        ktcipt(topxcb)=0x0
*** 2011-05-07 21:17:23.899
ksucti: init txn DID from session DID 0001-0017-00000008
ksqgtl:
        ksqlkdid: 0001-0017-00000008
*** 2011-05-07 21:17:23.899

*** ksudidTrace: ksqgtl
        ktcmydid(): 0001-0017-00000008
        ksusesdi:   0000-0000-00000000
        ksusetxn:   0001-0017-00000008
ksqgtl: RETURNS 0

该10704事件可以配合10046事件一起诊断异常的队列锁问题,记以录之!

EVENT:10228 trace application of redo by kcocbk

Error:  ORA 10228
Text:   trace application of redo by kcocbk
-------------------------------------------------------------------------------

Explanation:
        This is NOT an error but is a special EVENT code.
        It should *NOT* be used unless explicitly requested by RD support.

        Event 10228 is potentially useful in recovery situations since it
        traces the application of redo. Therefore, if cache recovery
        appears to hang or corrupt blocks then this can help track the dba
        and operations upon it.

        This event is available in Oracle 6 and 7.

        The code just calls the same routines used to dump a redo log using
        'alter system dump logfile' so has the same output.
        The benefit is that it'll stop when it hits the corruption.

Articles:
        Interpreting DUMP LOGFILE Output <Note:29726.1>

Setting an Oracle event:The structure of the trace syntax

PURPOSE
-------
The purpose of this article is to explain briefly the structure of the syntax to
event-based trace generation.
Setting an event: The structure of the trace syntax
---------------------------------------------------
@ A comprehensive/full overview of the event syntax can be found in:
@ Note:9331.1 - Full Event Syntax (from ksdp.c)
@ Note:45217.1 - Summary Event Syntax for WWCS
0. "Setting an Event" - Abstract definition:
============================================
"Setting an event" means to tell oracle to generate information in form of a
so called trace file in the context of the event.
1. Event Classes to be traced:
==============================
There are 4 Classes of traceable events:
Class 1 "Dump something": Traces are generated upon so called unconditioned,
immediate, events. This is the case when oracle data has
to be dumped like, e.g., the headers of all redolog files
or the contents of the controlfile. These events can not
be set in the init<SID>.ora.
Class 2 "Trap on Error" : Setting this class of (error-) events cause oracle to
generate a so called errorstack everytime the event happens.
Class 3 "Change execution path" : Setting such an event will cause oracle to
change the execution path for some specific code segment.
For example, setting event "10269" prevents SMON from doing
free space coalescing.
Class 4 "Trace something": Events from this class are set to obtain traces that are
used for, e.g., sql tuning. A common event is "10046" which
will cause oracle to trace  the sql access path on each
sql-statement.
II. Event based trace generation syntax - Overview and examples:
================================================================
1. Session:         alter session set events '10181 trace name context forever, level 1000';
2. init<sid>.ora:   event="10181 trace name context forever, level 1000";
-------------------------------------------------------------------------------------------
| TRACE      |                        TRACE SYNTAX                                          |
| CLASS      |                                                                              |
|-------------------------------------------------------------------------------------------|
|            | <event name> |                     <action>                                  |
|-------------------------------------------------------------------------------------------|
|            |              | <action key word> | "name" | <trace name> | <trace qualifier> |
-------------------------------------------------------------------------------------------|
|            |              |                   |        |              |                   |
|            |  immediate   |   trace           | "name" | blockdump    |    level 67110390 |
|            |  immediate   |   trace           | "name" | redohdr      |    level 10       |
|            |  immediate   |   trace           | "name" | file_hdrs    |    level 10       |
| "Dump      |  immediate   |   trace           | "name" | controlf     |    level 10       |
| Something" |  immediate   |   trace           | "name" | systemstate  |    level 10       |
|            |              |                   |        |              |                   |
|-------------------------------------------------------------------------------------------
|            |              |                   |        |              |                   |
|            |        942   |   trace           | "name" | errorstack   |    forever        |
|            |        942   |   trace           | "name" | errorstack   |    off            |
| "Trap      |         60   |   trace           | "name" | errorstack   |    level 1        |
| on         |       6501   |   trace           | "name" | processstate |    level 10       |
| Error"     |       4030   |   trace           | "name" | heapdump     |    level 2        |
|            |              |                   |        |              |                   |
|-------------------------------------------------------------------------------------------
|            |              |                   |        |              |                   |
| "Change    |      10269   |   trace           | "name" | context      | forever, level 10 |
| Execution  |              |                   |        |              |                   |
| path"      |              |                   |        |              |                   |
|            |              |                   |        |              |                   |
|-------------------------------------------------------------------------------------------
|            |              |                   |        |              |                   |
|            |      10046   |   trace           | "name" | context      | forever, level 12 |
| "Trace     |      10046   |   trace           | "name" | context      | off               |
| something" |              |                   |        |              |                   |
|            |              |                   |        |              |                   |
-------------------------------------------------------------------------------------------
III: Trace syntax: Annotations
===============================
0. There are tools like oradebug that allow for setting an event in another
session; this is useful, e.g., for tracing the export utility.
@Setting Events from Oracle Tools <Note:45219.1">
@For a list of common ACTIONS see <Event:List>
@For COMMON numeric events see    <event:Numeric>
1. The general syntax of setting an event is:  <event name>  <action>
<action> consists of three parts:           <action key word> <trace name> <trace qualifier>
@<action key word> can be either "trace", "crash", or "debug".
@ See <Note:9331.1">
<event name> is either "immediate", by this indicating an unconditioned event
or an event name given as a symbolic number from the system event name table.
An unconditioned event (keyword "immediate") cannot be set in the parameter file.
<trace qualifier> "forever" means: Activate a trace whenever this event occurs.
<trace name> "context" is a special trace name and pertains only to events set up
to either trace a diagnostic event or to change the behaviour of the oracle
code execution path. It cannot be used in conjunction with errorstack- ("errorstack")
or dump-generating ("immediate") events.
2. There are exactly 2 types of events, session-events and process-events.
Process-events are initialized in the parameter file, session-events
are initialized with the "alter session..." or "alter system ..."command.
When checking for posted events, the oracle server first checks for session events
then for process-events.
RELATED DOCUMENTS
-----------------
@     Event Syntax for most common forms of event setting <Note:45217.1>
@     The FULL Event syntax <Note:9331.1>
@     Setting Events from Oracle Tools <Note:45219.1>
@     List of common ACTIONS <Event:List>
@     COMMON numeric events <Event:Numeric>

沪ICP备14014813号

沪公网安备 31010802001379号