等待事件 oracle7 开始引入
v$event_name 记录当前数据库支持的等待事件及其基本信息
desc v$event_name
p1 p2 p3 不同等待事件参数其意义不同
wait_class（等待事件分类）
空闲等待 非空闲等待（调整数据库的时候需要研究的）
v$system_wait_class 视图显示各类主要等待事件的等待时间和等待次数等信息。分类统计。
V$SESSION 视图记录的是数据库当前连接的Session信息。
V$SESSION_WAIT 视图记录的是当前数据库连接的活动Session正在等待的资源或
事件信息。
V$SYSTEM_EVENT 由于V$SESSION记录的是动态信息，和 Session 的生命周期相关，并不记录历史信
息， 所以 Oracle ᨀ供另外一个视图 V$SYSTEM_EVENT 来记录数据库自启动以来所有等待事
件的汇总信息。 通过 V$SYSTEM_EVENT 视图， 可以迅速地获得数据库运行的总体概况。
10g 开始 v$session_wait整合到v$session 中。还增加了blocking_session字段。10gR2又增加了sql_trace相关信息。
11gR1又增加了sql_exec_start sql_exec_id prev_exec_start prev_exec_id等字段
v$session_event 同一会话在其整个周期等待事件的累积，因为v$session，v$session_wait都是动态变化的。和会话的生命周期相关。
v$system_event 数据库整体等待信息的累积。
v$event_histogram 同一等待事件，不同等待时长的柱状分布图。比如shared pool latch 10毫秒以内的等待有几次，200毫秒以上的等待有几次。
oracle 11g 实时sql监控 （通过在v$session中增加sql_exec_start等字段实现）
11g之前，某个操作超过6s，会被记录在v$session_longops视图中
11g开始，超过5s的CPU或者IO等操作，会被记录在v$sql_monitor视图中，还包含一些sql执行的统计信息，如buffer gets等。结合v$sql_plan_monitor视图可以进一步查询sql的执行计划等信息。每秒刷新一次，接近实时。sql执行完毕，信息不会被立即删除，而是会在这两个视图中保留1分钟。
根据session id获取当前session正在执行的sql语句：
SELECT sql_text FROM v$sqltext a
WHERE a.hash_value = (SELECT sql_hash_value FROM v$session b WHERE b.SID = '&sid')
ORDER BY piece ASC;
v$session_wait_history 记录session最近10次等待事件。可以查看该session过去某个时间所经历的等待事件，解决了现象消失后，无法获取发生问题时系统正在经历那些等待的问题。追溯。不是累积。
10g开始ASH v$active_session_history 以v$session为基础，每秒采样一次，记录活动session等待信息，不活动的会话不记录。由10g新引入的后台进程MMNL完成。
ASH信息存储在shared pool内存中，存满了，需要的时候可以被覆盖。
oracle提供的ASH报告工具，可以以几分钟或者几小时或者几天为跨度，对数据库提供概要分析。
内存中记录的ASH的信息毕竟是有限的，为了保存历史数据，这些数据最终要写入磁盘。这些信息就是AWR信息。
oracle以固定的时间间隔（默认每小时一次）为其所有重要的统计信息和负载信息执行一次快照，并将这些信息保存在AWR中。这些信息在AWR中保留给定的时间（默认为一周），然后被清除。AWR采样工作由后台进程MMON每60分钟执行一次。ASH信息同样会被采样写出到AWR负载库。
虽然ASH buffers 被设计为保留 1 小时的信息，但是很多时候这个内存是不足够的，当ASH buffers 写满之后，另外一个后台进程 MMNL 将会主动将 ASH 信息写出。 由于数据量巨大， 把所有的 ASH 数据写到磁盘上是不可接受的。一般是在写到磁盘的时候过滤这个数据，写出的数据占采样数据的10%，写出时通过direct-path insert 完成，尽量减少日志生成，从而最小化数据库性能影响。
AWR报告 $ORACLE_HOME/rdbms/admin/awrrpt.sql
AWR比较报告 $ORACLE_HOME/rdbms/admin/awrddrpt.sql
AWR信息的导入导出 awrextr.sql awrload.sql
oracle 10g ADDM
db file sequential read(数据文件顺序读取)，与单个数据块相关的读取操作。大多数情况下是读取一个索引块或者通过索引读取一个数据块。
如果此等待事件比较显著，可能是在多表连接中，表的连接顺序存在问题，驱动表选择错误。或者使用索引并非总是最好的选择。
但是在一个编码规范，调整良好的数据库中，这个等待事件很大通常是正常的。——————定期的数据整理和空间回收是必须的。
db file scattered read 离散读，将存储上连续的数据块离散的读取到多个不连续的内存位置（并发，性能考虑），通常是多块读。 DB_FILE_MULTIBLOCK_COUNT
应用问题，或者索引缺失。
direct path read/write 直接路径读写。直接路径读通常发生在oracle直接读数据到进程PGA，而不经过SGA。通常是磁盘排序IO，在DSS系统中常见，OLTP中意味着应用有问题。 直接路径写通常发生在直接从PGA写数据到数据文件或临时文件，绕过SGA。直接路径加载，并行DML，磁盘排序等。
存在过多的磁盘排序，会导致临时表空间操作频繁。
重要性能指标：内存排序率 in-memory-sort ratio = sort(memory）/ sort(disk) + sort(memory)
9i之前，增加sort_area_size，9i开始，增加P_A_T，避免磁盘排序。同时检查应用，避免过度排序。
并行操作也会direct path read/write。但并行不一定带来性能提升。
10g开始 direct path read/write temp
日志文件相关等待：
log file switch 日志切换，在此期间所有DML处于停顿状态，直至切换完成
两个子事件 log file switch(archiving needed) 归档未完成，磁盘IO，log_archive_max_processes。
log file switch (checkpoint incomplete)脏数据没写完，不能覆盖日志文件，DBWR。
log file sync 用户提交或回滚数据，LGWR将重做由缓冲写入重做日志的过程。LGWR写出太慢，或者提交过于频繁（LGWR过度激活，系统产生redo很多，但每次写的较少）。
log file single write 写日志文件头块相关，通常发生在日志切换或增加新的组成员期间。
log file parallel write 从log buffer写redo到日志文件，主要指常规操作（相对于log file sync的commit操作）。
log buffer space 数据库产生日志的速度比LGWR的写出速度快，或者日志切换慢发生等待。通常表明log buffer设置过小，考虑增大buffer大小或者增加日志文件大小。或者磁盘IO出问题。
enqueue（队列等待） 一种保护共享资源的锁定机制。排队机制，FIFO。
10g之前，是一组锁定事件的集合。
10g之后，对于队列等待进行了细分。
oracle的锁按类型可以分为排它锁（X)和共享锁（S）。
oracle通过enqueue等待来记录锁定，通过latch free等待事件来记录闩。
最重要，最常见的锁定：TM 、 TX
TX：事务锁，在行级获得。每行都存在一个锁定为（lb-Lock Byte） ，用于判断该记录是否被锁定，同时在数据块的头部存在一个称为ITL的结构，用于记录事务等信息。只有排他模式，没有共享模式。
TM：表级锁，可以通过手工发出lock命令获得，或者通过DML操作以及select for update获得，表级锁可以防止其他进程对表加X排他锁，防止在对数据修改时，其他任务通过DDL来修改表结构或者执行truncate、drop等操作。
当执行DML操作室，首先加TM锁，如果能获得锁定，则继续加TX事务锁。
最常见的锁定：MR与AE
MR：介质恢复锁（media recovery），用户保护数据库文件，使得文件在数据库打开，表空间online时不能执行恢复。
AE：11g开始，每个登录数据库的会话都会获得一个AE锁。
ST：空间事务锁，用于空间管理和字典管理的表空间的区间分配。
latch free（闩锁释放）：
低级排队机制（串行），用于保护SGA中共享内存结构。快速获取释放的内存锁，用于防止共享内存被多个用户同时访问。
v$latch 视图记录不同类型latch统计信息
按获取和等待方式不同进行分类：willing-to-wait （愿意等待类型） 、 immediate（立即类型）
willing-to-wait ：如果所请求的latch不能立即得到，则等待一段很短时间再请求，一直重复此过程直到获得latch。
immediate：所请求的latch不能立即得到，进程不再等待，继续执行下去。
gets 、 misses 、 sleeps、 immediate_gets 、 immediate_misses
获得 等待 休眠 立即获得 立即模式不成功
willing-to-wait （愿意等待类型）模式时，如果没有获得latch，且系统存在多个CPU，则进程围绕该latch进行自旋（spin），自旋的过程中，进程会一直持有CPU。如果直接采用sleep的方式，引起的上下文切换会非常昂贵。
immediate类型的latch通常是因为存在多个可用的latch，比如常见的redo copy latch。另外一个原因是latch有level的概念。
10g开始，latch被细分。
10g开始引入mutex机制，来代替传统的latch机制。更轻量，所需指令数更少，占用空间更小。使用更少的CPU资源获得更好的性能。
