【Oracle Database 12c新特性】SYS_AUTO_SPM_EVOLVE_TASK 自动作业

Oracle Database 12c中引入了一个新的自动系统作业,即SYS_AUTO_SPM_EVOLVE_TASK。 该作业将在每天的自动维护作业窗口中自动执行。 SYS_AUTO_SPM_EVOLVE_TASK负责检索和排序SPM中未被接受的执行计划non-accepted plan以便verification。 当此执行计划经过verified,过该计划满足性能阀值则将被自动接受accepted 。因此,当优化器将一个non-accepted的执行计划加入到SQL statement plan history中,在很多情况下若该计划确实是更好的,则会在第二天被接受并可以使用。

 

注意该自动task存在时间上的限制为一个小时(默认TIME_LIMIT=3600s),因此可能造成部分计划未被verified。 在此种场景下,下一个维护窗口该task执行时将处理剩余的执行计划。

 

 

SYS_AUTO_SPM_EVOLVE_TASK

  1  SELECT parameter_name, parameter_value
  2  FROM   dba_advisor_parameters
  3* WHERE  task_name = 'SYS_AUTO_SPM_EVOLVE_TASK'
SQL> /

PARAMETER_NAME                 PARAMETER_VALUE
------------------------------ ----------------------------------------
DAYS_TO_EXPIRE                 UNLIMITED
END_SNAPSHOT                   UNUSED
END_TIME                       UNUSED
INSTANCE                       UNUSED
JOURNALING                     INFORMATION
MODE                           COMPREHENSIVE
START_SNAPSHOT                 UNUSED
START_TIME                     UNUSED
TARGET_OBJECTS                 1
TIME_LIMIT                     3600
DEFAULT_EXECUTION_TYPE         SPM EVOLVE
CON_DBID_MAPPING               UNUSED
ORA_EM_PARAM1                  UNUSED
ORA_EM_PARAM2                  UNUSED
ORA_EM_PARAM3                  UNUSED
ORA_EM_PARAM4                  UNUSED
ORA_EM_PARAM5                  UNUSED
ORA_EM_PARAM6                  UNUSED
ORA_EM_PARAM7                  UNUSED
ORA_EM_PARAM8                  UNUSED
ORA_EM_PARAM9                  UNUSED
ORA_EM_PARAM10                 UNUSED
EXECUTION_DAYS_TO_EXPIRE       30
SQLSET_NAME                    UNUSED
SQLSET_OWNER                   UNUSED
ACCEPT_PLANS                   TRUE
_SPM_VERIFY                    TRUE
APPLY_CAPTURED_COMPILENV       UNUSED
LOCAL_TIME_LIMIT               UNUSED

已选择 29 行。

 select execution_name,status,execution_start,execution_end from dba_advisor_executions where task_name='SYS_AUTO_SPM_EVOLVE_TASK';


  --     time_limit  (IN) - Time limit in number of minutes.  The time limit
  --                        is global and it is used in the following manner.
  --                        The time limit for first non-accepted plan is equal
  --                        to the input value. The time limit for the second
  --                        non-accepted plan is equal to (input value - time
  --                        spent in first plan verification) and so on. The
  --                        default DBMS_SPM.AUTO_LIMIT means let the system
  --                        choose an appropriate time limit based on the
  --                        number of plan verifications required to be done.
  --                        The value DBMS_SPM.NO_LIMIT means no time limit.
  
  
  
DECLARE
   job                   BINARY_INTEGER := :job;
   next_date             TIMESTAMP WITH TIME ZONE := :mydate;
   broken                BOOLEAN := FALSE;
   job_name              VARCHAR2 (30) := :job_name;
   job_subname           VARCHAR2 (30) := :job_subname;
   job_owner             VARCHAR2 (30) := :job_owner;
   job_start             TIMESTAMP WITH TIME ZONE := :job_start;
   job_scheduled_start   TIMESTAMP WITH TIME ZONE := :job_scheduled_start;
   window_start          TIMESTAMP WITH TIME ZONE := :window_start;
   window_end            TIMESTAMP WITH TIME ZONE := :window_end;
   chain_id              VARCHAR2 (14) := :chainid;
   credential_owner      VARCHAR2 (30) := :credown;
   credential_name       VARCHAR2 (30) := :crednam;
   destination_owner     VARCHAR2 (30) := :destown;
   destination_name      VARCHAR2 (30) := :destnam;
   job_dest_id           VARCHAR2 (14) := :jdestid;
   log_id                NUMBER := :log_id;
BEGIN
   DECLARE
      ename   VARCHAR2 (30);
   BEGIN
      ename := DBMS_SQLTUNE.execute_tuning_task ('SYS_AUTO_SQL_TUNING_TASK');
      ename := DBMS_SPM.execute_evolve_task ('SYS_AUTO_SPM_EVOLVE_TASK');
   END;

   :mydate := next_date;

   IF broken
   THEN
      :b := 1;
   ELSE
      :b := 0;
   END IF;
END;




/* Formatted on 2013/8/4 10:48:19 (QP5 v5.163.1008.3004) */
  SELECT pl.signature,
         pl.category,
         pl.name,
         pl.plan_id,
         DECODE (BITAND (pl.flags, :1), 0, :2, :3) flags,
         pl.sql_handle,
         pl.sql_text,
         pl.comp_data,
         pl.optimizer_env,
         pl.bind_data,
         pl.parsing_schema_name,
         pl.creator,
         (CASE                                  /* plan is already accepted */
             WHEN (BITAND (pl.flags, :4) <> 0)
             THEN
                :5                       /* plan has recently been verified */
             WHEN (pl.is_auto IS NOT NULL
                   AND pl.last_verified >
                          SYSTIMESTAMP
                          - :6)
             THEN
                :7    /* plan's SQL statement hasn't been recently executed */
             WHEN (pl.is_auto
                      IS NOT NULL
                   AND pl.last_verified
                          IS NOT NULL
                   AND pl.sql_last_executed <
                          SYSTIMESTAMP
                          - :8)
             THEN
                :9
             ELSE
                :10
          END)
            pruned
    FROM (SELECT so.signature,
                 so.category,
                 so.name,
                 so.plan_id,
                 so.flags,
                 st.sql_handle,
                 st.sql_text,
                 (DECODE (
                     BITAND (so.flags, 128),
                     128, (SELECT EXTRACT (XMLTYPE (pl.other_xml),
                                           '/*/outline_data').getClobVal ()
                             FROM sys.sqlobj$plan pl
                            WHERE     pl.signature = so.signature
                                  AND pl.category = so.category
                                  AND pl.obj_type = so.obj_type
                                  AND pl.plan_id = so.plan_id
                                  AND pl.other_xml IS NOT NULL),
                     (SELECT sod.comp_data
                        FROM sys.sqlobj$data sod
                       WHERE     sod.signature = so.signature
                             AND sod.category = so.category
                             AND sod.obj_type = so.obj_type
                             AND sod.plan_id = so.plan_id)))
                    comp_data,
                 sox.optimizer_env,
                 sox.bind_data,
                 sox.parsing_schema_name,
                 sox.creator,
                 sox.last_verified,
                 sox.optimizer_cost,
                 sox.created,
                 :11 is_auto,
                 (SELECT MAX (last_executed)
                    FROM sys.sqlobj$ ob
                   WHERE     ob.signature = so.signature
                         AND ob.obj_type = so.obj_type
                         AND ob.category = so.category)
                    sql_last_executed
            FROM sys.sqlobj$ so, sys.sqlobj$auxdata sox, sys.sql$text st
           WHERE (:12 IS NULL
                  OR so.name IN (SELECT EXTRACTVALUE (VALUE (p), '/plan') pname
                                   FROM TABLE (
                                           XMLSEQUENCE (
                                              EXTRACT (XMLTYPE (:13),
                                                       '/plan_list/*'))) p))
                 AND (:14 IS NOT NULL
                      OR (BITAND (so.flags, :15) <> 0
                          AND BITAND (so.flags, :16) = 0))
                 AND so.obj_type = :17
                 AND so.signature = sox.signature
                 AND so.category = sox.category
                 AND so.obj_type = sox.obj_type
                 AND so.plan_id = sox.plan_id
                 AND so.signature = st.signature) pl
ORDER BY DECODE (:18, 0, NULL, pl.name),
         pl.last_verified NULLS FIRST,
         pl.sql_last_executed DESC NULLS LAST,
         pl.optimizer_cost,
         pl.created,
         pl.name

【Oracle Database 12c新特性】Online Statistics Gathering for Bulk-Load 针对批量数据加载的在线统计信息收集

Oracle database 12c中提出了Online Statistics Gathering for Bulk-Load 针对批量数据加载的在线统计信息收集的新特性。

 

通过online statistics gathering,当出现某些批量数据加载操作例如CREATE TABLE AS SELECT CTAS操作 或者 针对一个空表的INSERT INTO … SELECT操作时,统计信息将被自动收集。

 

online statistics gathering省略了当一个批量数据加载后的必要手动统计信息收集操作; 大家还记得我们在讲10/11g 性能调优时 关于数据量大幅变化操作后的手动收集统计信息建议吗? 实际上这个特性一定程度就是为了解决这里还需要手动去收集一次的麻烦。  这个特性表现的很像之前的CREATE INDEX或REBUILD INDEX时自动完成的统计信息收集。  Oracle通过内部维护操作来维护CTAS或物化视图刷新的统计信息更新 。

 

在数据仓库中,用户经常需要加载大量的数据到数据库中; 这里online statistics gathering 就可以起到作用。

Oracle Database 12c中默认启用这种自动统计信息收集特性,主要的收益在于提升批量加载数据后的SQL性能和可管理性,不在需要用户介入来人工收集了。 由于不在需要手动收集统计信息, 所以也就避免了后续的一次可能的全表扫描。

当使用Online Statistics Gathering时,数据库不收集索引统计信息和直方图。如果确实需要索引统计信息和直方图,则Oracle推荐在批量加载数据后再次使用DBMS_STATS.GATHER_TABLE_STATS。   默认情况下 DBMS_STATS.GATHER_TABLE_STATS仅收集缺失的统计信息,因此当你在bulk load批量加载后执行DBMS_STATS.GATHER_TABLE_STATS,数据库将仅仅收集索引统计信息和直方图histograms, 而表和字段的统计信息将不再被收集。

 

补充1点: SYS用户的对象不启用Online Statistics Gathering,不要使用SYS用户去测试该特性。

 

Online Statistics Gathering for Bulk-Load 的其他限制:

 

  1. It is in an Oracle-owned schema such as SYS.
  2. It is a nested table.
  3. It is an index-organized table (IOT).
  4. It is an external table.
  5. It is a global temporary table defined as ON COMMIT DELETE ROWS.
  6. It has virtual columns.
  7. It has a PUBLISH preference set to FALSE.
  8. It is partitioned, INCREMENTAL is set to true, and extended syntax is not used.

 

FROM 孟买-老托拉呱的笔记:

在Oracle Database 12c中,如下两种Bulk-Load方式下,系统将会自动收集表上的统计信息
¤ CTAS – Create Table As Select …
¤ IIS – Insert Into … Select …

说明:(1)必须是使用direct path insert到一个空表/空分区的情况下

(2)如果是空分区表,收集的是global statistics而不是partition-level statistics。

如果是插入到指定的分区/子分区(空),则收集partition-level statistics而不是global statistics。比如Insert Into sales PARTITION(sales_q1_2013) Select …
如果在插入前,分区sales_q1_2013是空的(其他分区不论是否为空),那么就会收集统计信息。如果表上启用了Incremental Statistics Maintenance属性(11gR2开始提供的特性),那么同时也会自动该分区的摘要(synopsis)信息。

(3)如果rollback,统计信息自动删除。

(4)这个特性,不收集index statistics or histograms,所以,如果需要,Oracle推荐通过DBMS_STATS.GATHER_TABLE_STATS(options => ‘GATHER AUTO’…)
来收集index statistics or histograms。

这就有点象从10g版本开始create index/rebuild index自动收集统计信息的意思了。在12c之前的版本,DBA是需要及时(数据插入之后)手工去收集Statistics,否则可能会在后面的使用中导致不正确的执行计划的出现。

 

 

 

隐藏参数_optimizer_gather_stats_on_load(enable/disable online statistics gathering,默认为TRUE)控制该Online Statistics Gathering for Bulk-Load特性是否打开,默认是打开的。

除了设置_optimizer_gather_stats_on_load=false之外还可以通过NO_GATHER_OPTIMIZER_STATISTICS(QKSFM_DBMS_STATS)的HINT来避免使用Online Statistics Gathering特性。 与之相对的是 GATHER_OPTIMIZER_STATISTICS。

 

测试1: Create table AS select 耗时上启用Online Statistics Gathering大约增加15%

 

 

SQL> create table online_gather as select rownum t1, 'maclean' t2 from dual connect by level<=900000; 

表已创建。 

已用时间:  00: 00: 01.09 

SQL> select num_rows,blocks from dba_tables where table_name='ONLINE_GATHER';

  NUM_ROWS     BLOCKS
---------- ----------
    900000       2282

已用时间:  00: 00: 00.17

SQL> alter session set "_optimizer_gather_stats_on_load"=false;

会话已更改。

已用时间:  00: 00: 00.00

SQL> create table online_gather2 as select rownum t1, 'maclean' t2 from dual connect by level<=900000; 

表已创建。 

已用时间:  00: 00: 00.93 

SQL> select num_rows,blocks from dba_tables where table_name='ONLINE_GATHER2';

  NUM_ROWS     BLOCKS
---------- ----------

已用时间:  00: 00: 00.09

 

 

 

 

2、测试 bulk load insert

 

 

conn malcean/maclean

SQL> create table online_load (t1 int, t2 varchar2(200));

表已创建。

SQL> insert into online_load select rownum t1, 'maclean' t2 from dual connect by level<=900000;

已创建 900000 行。

SQL> commit;

提交完成。

SQL> select num_rows,blocks from dba_tables where table_name='ONLINE_LOAD';

NUM_ROWS BLOCKS
---------- ----------

// 注意仅有INSERT APPEND的情况下才会触发Online Statistics Gathering

SQL> create table online_load1 (t1 int, t2 varchar2(200));

表已创建。

SQL> insert /*+ append */ into online_load1 select rownum t1, 'maclean' t2 from dual connect by level<=900000; 已创建 900000 行。 SQL> commit;

提交完成。

SQL> select num_rows,blocks from dba_tables where table_name='ONLINE_LOAD1';

  NUM_ROWS     BLOCKS
---------- ----------
    900000       2282

【Oracle Database 12c新特性】32k varchar2 max_string_size

在Oracle Database 12c中,我们可以为varchar2、nvarchar2和RAW数据类型指定32767 bytes 的最大长度了, 以便用户将更长的字符串存储在数据库中。

 

在12c之前的版本中,varchar2和nvarchar2数据类型的最大长度是4000 bytes,而raw是2000 bytes。

varcha2、nvarchar2和raw字段的定义长度将影响字段的内部存储方式

  • 定义为4000字节或更小的varchar2、nvarchar2以及2000字节或更小的raw字段,将被inline存放
  • 定义为4000字节以上的varchar2、nvarchar2以及2000字节以上的raw字段的话,被称作extended character data type columns,以out of line方式存储。

 

参数MAX_STRING_SIZE控制扩展数据类型extended data type的最大长度:

  • STANDARD 代表12c之前的长度限制,即varchar2、nvarchar2 4000 bytes, raw 是2000  bytes
  • EXTENDED 代表12c 32k strings新特性,varchar2、nvarchar2、raw最大长度32k  bytes

 

Extended character data types 扩展字符类型存在以下的限制:

  • 不支持cluster table 簇表和index-organized tables索引组织表
  • 不支持intrapartition的并行DDL、UPDATE和DELETE DML
  • 不支持在Automatic Segment Space Management (ASSM)表空间上的intrapartition parallel direct-path inserts

[Read more…]

【12c新特性】RAC Cluster Hub Node-Leaf Node

原帖地址:http://www.askmaclean.com/archives/12c-rac-cluster-hub-node-leaf-node.html

 

在12c的cluster中引入了很多新特性和新概念,其中重复最多的几个名词除了flex cluster、flux asm之外 还有Hub Node和Leaf Node,这里来介绍Hub Node和Leaf Node.

 

flex cluster arch

 

  • Hub Node官方解释:
    • A node in and Oracle Flex Cluster that is tightly connected with other servers and has direct access to a shared disk.
  • Leaf Node官方解释:
    • Servers that are loosely coupled with Hub Nodes, which may not have direct access to the shared storage.

可以看到主题区别在于 Leaf Node不能直接访问shared storage ,这意味着leaf node不是share disk的。 这里Hub Node与12c之前的普通cluster node无区别, 而Leaf Node是新技术。

 

Leaf Node的特性:

  • 与 Hub Node相比 更松散地与cluster捆绑
  • 在启动时自动发现Hub Node
  • 通过一个Hub Node连接到集群
  • Hub Node或网络失败都会造成相关的Leaf Node被驱逐
  • 不要求直接访问共享存储
  • 与Hub Node在同一网络

 

使用Leaf Node实现Flex Cluster的好处显而易见:

  • hub-and-spoke技术将cluster分化成可管理的节点组
  • 仅仅需要Hub Node直接访问OCR和Votedisk
  • 通过限制HUB node的数量,从而减少对关键clusterware资源的争用,例如ocr和Votedisk 。
  • 在节点间所需要的网络互动更少
  • 更少的管理用网络流量,例如节点间的心跳

 

 

对比下图可以看到,12节点的Flex cluster包含12个交互通路, 而普通集群则需要 [ n * (n-1)]/2共66个交互通路。

对于上1000节点的集群,上述的差异会更明显。假设有40个Hub Node,每一个Hub Node对应24个Leaf Node,则Flex Cluster将包含1740个交互通路。  与之对比,普通Cluster需要499500个交互通路。

 

flex cluster

 

 

在Flex Cluster中集群中被驱逐的节点无需重启,仅仅cluster software需要重启。

 

如果Hub Node 失败

  • 该节点将被集群驱逐 , 且如果可能则服务将被relocate到其他Hub Node
  • 该Hub Node对应的Leaf Node亦被集群驱逐,如果可能服务也将relocate到其他Leaf Node上

如果Leaf Node失败

  • 该节点将被集群驱逐,如果可能服务将被relocate到另一个Leaf Node上

 

【Oracle Database 12c新特性】ASM Scrubbing Disk Groups

在12.1中Oracle ASM提供了一个改善可用性和可靠度的的新特性 称作Scrubbing Disk Groups, Disk Scrubbing通过检查数据的逻辑讹误,从而能够在Normal 或者High Redundancy的disk group上修复它们。 Scrubbing 进程需要利用镜像盘来修复逻辑讹误。Disk Scrubbing可以与disk group rebalancing组合使用以减少I/O资源消耗。Disk Scrubbing对产品环境的I/O影响不大。

用户可以指定具体要Scrubbing的磁盘组,特定的磁盘,或者磁盘组内的某一个文件,具体要使用ALTER DISKGROUP命令。如下面的例子:

 

 

SQL> ALTER DISKGROUP data SCRUB POWER LOW;

SQL> ALTER DISKGROUP data SCRUB FILE '+DATA/ORCL/ASKMACLEAN/example.266.806582193' 
       REPAIR POWER HIGH FORCE;

SQL> ALTER DISKGROUP data SCRUB DISK DATA_0005 REPAIR POWER HIGH FORCE;

 

 

当执行如上SCRUB 时:

 

  • 选项REPAIR指定自动修复磁盘讹误,如果未指定REPAIR,则SCRUB仅检查和报告指定目标的逻辑讹误。
  • 选项POWER可以设置为AUTO LOW HIGH 或者MAX。 若POWER未指定,则使用AUTO自动调整。
  • 选项WAIT 指定该命令直到scrubbing 命令完成才返回。若WAIT不指定,则scrubbing操作将加入到scrubbing queue 队列,并命令立即返回
  • 若FORCE选项被指定,则即便系统I/O负载很高或者在系统级别已经禁用了scrubbing ,还是执行该命令。

 

【Oracle Database 12c新特性】TTnn TMON新的redo传输后台进程

在Oracle 11g中 Data Guard的redo传输工作主要由以下3组后台进程实现:

  • ARCi (FAL – archived redo shipping, ping, local only archivals)
  • NSAi (async) 12.1 name: TTnn ,
  • NSSi (sync) –– live redo shipping

 

但从版本12c开始 使用TTnn  例如TT00进程来负责async 异步的redo传输。 另一个后台进程TMON来负责做Redo transport monitor。

 

SQL> select banner from v$version where rownum=1;

BANNER
--------------------------------------------------------------------------------
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production

SQL> select program,pid from v$process where program like '%TMON%' or Program like '%TT%';

PROGRAM                               PID
------------------------------ ----------
ORACLE.EXE (TMON)                       7
ORACLE.EXE (TT00)                      24

 

 

 

 

这样做的目的是 在11g 中因为NSAi async redo ship异步传输进程仍需要LGWR进程的通知才能工作,造成短暂的redo 传输延迟; 所以在12c中TTnn进程的redo传输不再依赖于LGWR。

注意是  这里讨论的是async redo ship 异步redo传输!

11g时:

 

11g nsa

 

12c时

12c ttnn tmon

 

 

TTnn TMON Data Guard ASYNC

【12c database 新特性】Adaptive Execution Plans 自适应的执行计划

12c R1 中引入了SQL优化的新特性- Adaptive Execution Plans 自适应的执行计划,该特性让优化器optimizer 可以在运行时(runtime)自动适配一个性能不良的执行计划, 并避免在后续的仍选择该性能糟糕的执行计划。

 

SQL优化器将在运行时 最终确定其使用的执行计划, 这样可以检测到优化器一开始评估的执行计划可能不是最优的。这样执行计划就可以自动适配到实际的运行条件中。一个自适应的执行计划adaptive plan 是在优化器第一次硬解析得到执行计划后在运行时选择了与原计划有区别的子计划,选择子计划subplan的原因是优化器认为一开始的评估并不准确。

 

换大白话来说, 即便统计信息准确 优化器的评估也可能与实际有出入,但没法在执行前知道, 现在的办法是 先让优化器和平时一样给一个认为”最佳的”执行计划, 在执行过长中对某些数据源获得的结果集做buffer 来统计实际行数  然后和优化器评估的做比较,看是否准确,不准确则变化之后的可以改动的执行计划。

 

优化器optimizer 自适应执行计划是基于语句执行时的执行信息统计数据的,这些数据在执行时被收集。所有的自适应技术都可能执行一个不同于优化器最初硬解析获得的plan的计划。 这是12C中对查询处理引擎的重要提升, 优化器的判断将更注重了解过去的执行情况,即优化器有了 前事不忘后事之师的能力。

 

自适应执行计划主要有以下2个技术:

 

  • Dynamic Plans动态计划: 动态计划是指在语句执行期间在多个子计划之间选择;对于动态计划,优化器optimizer需要决定哪一个子计划subplans最终将包含在本次的动态计划中, 哪些执行统计信息需要收集以便选择子计划,以及做出选择需要机遇的阀值。
  • Reoptimization再次优化: 与Dynamic Plans不同的是,Reoptimization是在当前执行之后再次执行时改变执行计划。对于Reoptimization而言,优化器必须判断在原执行计划的哪一步收集哪些统计信息,以及reoptimization是否可行。

 

 

adaptive execution plans

OPTIMIZER_ADAPTIVE_REPORTING_ONLY 参数控制 report-only模式的自适应优化。当该参数设置为TRUE,则自适应的优化器以report-only模式运行,仅收集自适应优化器所需要的信息,但是不采取改变执行计划的行动。

 

Dynamic Plans

动态执行计划仍是一个执行计划,只是它有着多个不同的内置计划选项。在第一次执行时, 在某个特定的子计划激活之前,优化器将作出最终的决定,选择哪一个选项被使用。优化器的选择基于它运行到这一个步骤的整个过程间观察到的数据。 动态计划是优化器最终启用的final plan不同于硬解析时获得的默认计划default plan, 由于final plan比default plan更了解实际情况,所以往往可以改善查询性能。

 

subplan 子计划是整个执行计划的一个部分,优化器在运行时判断是否要切换到这个备选的子计划。

[Read more…]

【Oracle Database 12c新特性】wait event DISPLAY_NAME

在Oracle database 12c 中引入V$EVENT_NAME 视图新增字段DISPLAY_NAME,该字段用以更详细地解释对应的等待事件:

 

DISPLAY_NAME VARCHAR2(64) A clearer and more descriptive name for the wait event that appears in the NAME column. Names that appear in the DISPLAY_NAME column can change across Oracle Database releases, therefore customer scripts should not rely on names that appear in theDISPLAY_NAME column across releases.

 

可惜的是目前并非所有的event都有对应的DISPLAY_NAME,我们列出在12.1.0.1中现有的display name:

 

select name,display_name,wait_class from v$event_name  where name!=display_name order by name

 

NAME DISPLAY_NAME WAIT_CLASS
DFS db file lock quiesce for datafile offline Other
Image redo gen delay redo resource management Other
LGWR real time apply sync standby apply advance notification Idle
concurrent I/O completion online move datafile IO completion Administrative
control file sequential read control file read System I/O
control file single write control file write System I/O
datafile copy range completion online move datafile copy range completion Administrative
datafile move cleanup during resize online move datafile resize cleanup Other
db file parallel read db list of blocks read User I/O
db file parallel write db list of blocks write System I/O
db file scattered read db multiblock read User I/O
db file sequential read db single block read User I/O
db file single write db single block write User I/O
log buffer space log buffer full – LGWR bottleneck Configuration
log file parallel write log file redo write System I/O
log file sequential read log file multiblock read System I/O
log file single write log file header write System I/O
log file sync commit: log file sync Commit
wait for possible quiesce finish quiesce database completion Administrative