timed statistics 定时统计

  如果设置timed_statistics参数配置为true,等待会以定时方式显示结果。让我确认，以前其它人也说过如此的话，这样开启此参数的成本可以忽略了.
如果你相信你自己，使用set timing on;
  如果不配置timed statistics,oracle只是记录等待前后的原因，当等待结束时，它记录是否超时。但如果开启timed statistics,oracle会在等待前后检查时间,
同时记录等待占用的时间。等待占用的时间以百分之一秒单位计算，也叫微秒.


wait types  等待类型

    v$system_event 显示等待的总次数及超时，每种等待事件的总计等待时间.它是整个实例生命周期所有进程的累计值。
根据总体等待事件所花费时间，以降序对这些等待事件进行显示，它是每种等待类型严重程序的一个指示灯.
    但是，总体花费的等待时间，只是对于等待某些资源这种情况有用。如果进程等待是因为目前没有工作而作，这时等待时间就不重要的或没有意义了。假如它们在等待某种常规的操作,
比如disk i/o，这时总的等待时间将依赖于工作负荷.这种情况下，平均等待时间就比总的等待时间更为有用或有效.



session waits 会话等待
    v$session_event显示每个会话的等待统计信息。虽然等待影响的是进程而非会话，但是v$session_event因为会话可以在多个进程之间迁移（比如像多线程服务器的配置），记录会话。累积的会话等待统计
有两大作用.首先，如果一个特定有用户发现出现某段时间出现性能问题，此时根据这个会话的等待统计就可以诊断用户程序.
第二，如果发现过度等待某种资源，会话等待统计也可以确认哪些会话，是导致这个问题的根源.

 
wait parameters 等待参数
   等待统计非常有用，因为它们可以告诉你哪些会话在等待，它们在等待什么资源。它们可能在等待lathes,database blocks,enqueue locks,或其它的资源类型.一旦你了解了等待的资源类型，对你调优工作很有帮助.
等待统计仅仅给你提供相关的线索，但只有等待参数能让你定位到具体的问题.
   不幸的是，等待参数很难抓取。它们在v$session_wait的出现非常短暂。这个视图显示每个会话对于目前或最近每个等待的等待参数信息，还有等待的持续时间。但是查询v$session_wait相对于大量多等待的长度，要花更多的时间.
假如你在短暂的会话中运行两次它的查询，会发现大多等待事件已现不再出现，这很正常。另外重复查询这个视图代价太高，因此它仅适用于限制性的工作范围.
    幸运的是，用dbms_support包产生trace file，发现等待参数，或者用10046.这个trace过程作用和运行sql_trace工具一样，但也包括每个等待，包括等待参数.
每种等待事件类型的等待参数含义，可以查询v$event_name。

    参数列表

参数                                     描述
_use_vector_posts                        vector posts允许在单一信号量操作中，开启发送通知给多个等待进程

post_wait_device                         一种伪设备驱动。当操作是针对一个设备类型的设备特定文件，这个功能会开启。使用了这个参数，它指定
                                         post-wait driver设备文件的路径


timed_statistics                         需要调优，开启它吧

use_post_wait_driver                     如果存在这个参数，为了使用post-wait driver,配置它为true,而不是正常的信号量操作



events 事件

事件                                     描述
10046                                    实现dbms_support trace,它是sql_trace工具的超集。设置为level 4,trace结果包含bind calls,
                                         设置为level 8,包含等待事件，这是dbms_support的默认level;如果设置为level 12, 同时包含binds和等待