waits 等待
  oracle实例有好多进程（或者每个进程有许多线程）在一起工作，它们必须要相互通讯。它们通讯的方式是采用semaphores(信号量），类似于
铁道上的信号灯，告诉火车是否可以开动或停止，何时可以开启或停止.其实oracle服务进程经常也需要停止或者等待
   
   停止或等待的情形如下：
     某种资源不可用
     目前没有工作可作
     有时它们需要等待其它的服务进程完成必备的工作或任务


sepaphores 信号量(灯）
  oracle服务器进程有一个对应的信号量，进程需要某种资源时，等待它们的信号量，或者要作工作，或需要它的工作完成之时。
当它们需要的资源可以用，或它们可以开始工作，或它们前提工作已经完成了，然后信号量就会发一个信号，你们不用再等待了.

  比如，lgwr可能会等待完成某项工作的信号量，是这样一种情形，当一个用户进程拷重作数据到redo log buffer。当用户提交时，
lgwr必须把重作和提交标志的相关信息写到log file（此时用户在等待）.
为了实现这个目标，用户进程给lgwr进程抛出一个信号量，表示lgwr可以停止等待某个工作，因为现在可以作这些工作了.这时，用户
进程等待它的信号量.当log file i/o完成了，lgwr发送一个信号量，告诉用户进程，你啊，现在可以继续产生新的事务，因为提交操作已经
完成了。最后lgwr又等待它的信号量，因为它又没有更多的工作可以作了。


  另一种情况，进程a可能要更新一个记录，但发现进程b对这个记录在以前作过更改，但没有提交。此时进程a必须等待进程b完成提交。为了实现这个,
进程a将等待它的信号量。当进程b提交，它发送一个信号量告诉进程a，你可以完成你的更新操作了.
 


  semaphore facilities 信号量工具
     它是一种操作系统的工具。当oracle进程等待它的信号量时，按照os的讲法，os不会调度cpu的资源给它用。这时，这个oracle就叫阻塞，不能运行。直至重新得到信号量。
现在一些操作系统支持多种类型的信号量。system v信号量用得最多。system v信号量的数据结构，根据semmns核心参数定义的大小，会在内核内存中构成一个固定的阵列（数组）.
为了了解（发送）一个信号量的信号或等待，进程必须使用semop()系统调用.因为实现他们要通过操作系统的内核，system v信号量会导致非常高的不必要的系统调用上下文切换成本
，由于访问内核数据结构的序列式方法，也造成低效的伸缩性（系统）.
     为了实现更好的性能和灵活性,好多操作系统也提供一种对于信号量操作的替代方法。其实就是通过一种伪设备驱动来实现，叫作一个post-wait driver(译为：等待后的驱动）.
这些信号量的数据结构是驻存在用户的进程中，而非内核的内存中，因此操纵它们其实是在用户的上下文环境之中的伪设备驱动.这样就会减少系统调用上下文切换的次数，提升了伸缩性，
但是这一切皆与特定的os有关.
     posix实时扩展委员会，一致同意用户内存信号量工具的使用。posix.1b标准（以前是posix.4)定义如何实现内存信号量工具的优雅与高效的必备条件，包括：实现接口与实施预备条件
而不涉及它的可移动性。posix.1b信号量现在大多os皆支持.

     oracle到底使用哪位信号量工具，与os和特定版本有关。如果oracle安装手册，描述了如何配置semmns核心参数，这意味着默认会使用system v信号量.不幸的是，大多会把semmns设置为200，
根据没去考虑oracle进程到底需要多少数量，或者其它的系统及应用软件的相关要求,我认为这是自以为是。我认为你要给每个oracle进程分配一个信号量，当然也要想到其它的进程要求.你也应该
意想到，在一些平台上，每个信号量要在单一的信号量集中进行分配。因此要为每个实例设置semmni参数（表示信号量的标识）,另外semmsl（如何定义）绝对至少等待oracle的参数processes值。
有必要开启vector posts，主要像lgwr,dbwn后台进程会使用它，为了发送（发解）单一信号量操作之中的多个等待进程，vector posts的使用与_use_vector_posts参数有关


     而且，如果在os中semmnu核心参数，它应大于os层面并发的信号量大小.对于像许多信号量客户端进程的系统，默认配置肯定是不够的。这样信号量操作会在业务高峰出现间断，返回ora-7264或ora-7265错误.
为了避免这个，semmnu参数至少要等于cpu的个数加上cpu运行队列的峰值长度

    

system v信号量参数

参数名                                 描述
semmns                                 定义系统中的信号量数量.除了os必须的及其它软件的信号量，你应该至少为每个
                                       oracle实例的服务器进程分配一个信号量.也就是说至少等于processes的值.如果使用信号量的客户端
                                       并未严格遵守实行关闭和启动，你应额外至少配置它的值等于最大的oracle实例的信号量的值


                                       再者，内核参数可以控制一个指定的用户（经常是maxup核心参数）最多可以同时使用的进程数,它应当至少等于
                                       semmns的配置，同时也要想到oracle用户下面一些不需要信号量的管理进程的存在。但是，这个参数不要配置太大，导致产生
                                       其它用户创建太多的进程，导致内核进程表会填满的风险.因此，控制所有用户（经常是nproc核心参数）最大的并发进程数的参数，至少
                                       三倍于semmmns的值


semmsl                                 每个单一信号量集的大小限制。这个参数一般在大多os中不用定义。哪果它定义了，oracle需要会把实例的所有信号量分配在一个信号量集中，这个参数
                                       至少等于任何实例最大的processes的值。



semmni                                 系统中信号量集的标识符个数。除了os的必须及其它软件外，你应为每个实例分配一个，或者说，要分配更多，如果semmsl参数配置了，这样任何一个实例需要多个信号量集.





semmnu                                 系统中撤消结构的信号量的个数。当在信号量操作中出现一个进程的意外死亡，用撤销结构恢复内核信号量数据结构。这个参数的值要大于峰值时刻正在运行及运行着进程的个数






  如果在os中，oracle默认使用system v信号量,同时也支持一个post-wait driver的使用，这时你应使用post-wait driver。
 
正常use_post_wait_driver的值为true，有时设置post_wait_device也是必须的。






 scheduling latencies  调节延迟(两命令之间的反应间隔）

   当一个进程接到信号量的通知，它的os状态从阻塞变成可以运行。但这并不意味着cpu调度会把资源马上给它使用。它必须至少等待
到os进程调度器下一次运行才可以，这个等待时间也可能更少，如果比它更高优化级的进程等待着执行。从一个进程接到信号量的通知（可以执行）直到它开始真正执行的
的时间间隔，叫作调度延迟.调度延迟主要体现在oracle反应时间上。因此减少它对于oracle调优至关重要.
   大多数os调度器算法会动态根据正在执行的进程目前消耗的cpu time，调整进程的执行优先级.在非常繁忙的oracle环境中，这种配置可能对oracle一些关键的后台进程，比如:lgwr,dwn,lckn,lmdn的执行优先级
产生不良影响.这样无形就会增加这些进程的调度器延迟,甚至可能在极端情况下影响基于后台进程的服务产生极大的bottlebock.

   大多数os支持多种调度器算法。在可能情况下，选择不影响进程执行优先级的调度器算法。如果不行，os会采用一个默认的调度器算法。如果一个进程的优先级固定了，它会不被降级。在大多数情况下，所有用户可以使用
优先级固定的功能，oracle会自动采用此功能。在其它一些情况下，只有sa及特有权限的用户可能用它。

  
   timeouts  超时
  oracle服务器进程不会无限期的等待下去，以免它们无限期等待下去。幸运的是，信号量的等待可以被中断（打断）。因此假如oracle进程开始等待它的信号量时，它会设置一个警告时钟上，以此安排它的睡眼能被中断,或者叫超时。
假如某个进程接到通知，它就把alarm clock的状态置为off(关闭），然后继续处理下面的工作。但是，如果超时过期，等待通过一个sigalrm信号量中断它。此时这个进程就会重新分析及评估它的相关情况与资源，决定是否继续等待
比如，等待一个入队锁的进程，可能发现了死锁，此时等待超进了。如果发现了一个死锁，语句将被回滚，并触发一个异常，但如果不是这种情况，进程将重新配置一个新的延迟，继续再次等待它的信量号.



   有时有这样一种情况，延迟在过期前，一个进程时间在非常短的时间就接到通知，alarm进行入睡就像进程尝试关闭它.这种情况，oracle的相关进程会把一个信息写到它的trace file中: ignoring sigalrm

如果你在一些trace file发现这些信息，并没有什么有用的信息。它只是告诉你，等待进程有时并没有像它们所想的速度一样快速的被通知，不管如何，等待事件你总要时时关注




    wait statistics  等待统计
  oracle等待统计很有价值，但也不要过高估计它们的作用。如果发现oracle大量等待资源：比如latch,free cache buffers,enqueue locks等，这时等待统计能同时确认这个性能问题。经验越多，你也可以用它确认网络及磁盘的性能问题.
等待统计为你解决这些问题提供一个非常有价值的参考.
  但是如果你的应用发现过多的解析，或者发现与你的工作负荷不一致的大量的disk i/o。这时等待统计就用不上了。它们表现得好像非常健康，好像也确实如此。等待统计只能揭示数据服务层及以下层的低效问题，它们并不适用于诊断应用层的性能问题
，由此导致 增加了数据库服务的负荷，但这个问题并不会让工作低效工作.