一、常见等待事件
1. Buffer busy waits
会话等待buffer（数据块），会话修改或读取数据块时，这个数据块被另一个会话占用。
要修改一条记录，也需要对记录所在的数据块进行操作，而其他的会话就会被阻止，当修改完后，要释放数据块上的排他锁，这样其他用户就可以进行操作了。等待事件多出现于多个用户频繁占用同一个数据块。解决方法：最早是对查询到读取/修改整个过程进行锁，可以优化成对查询和读取/修改分别进行两次锁过程，能减少锁的时间。
2. Db file sequential read / Db file scattered read
Oracle需要每次I/O只读取单个数据块时，常见的情况是索引访问，回滚操作，以ROWID访问表数据，重建控制文件，对数据文件头做读操作时，对读取的数据在内存中按连续的方式存放。
用户操作引起的等待事件，用户发出I/O需要读取多个数据块时，常见的情况是全局扫描和索引快速扫描，对读取的数据在内存中按分散的方式存放。
Read事件是对数据的读取花费了时间，可以减少不必要的IO、优化SQL语句、增大缓存池来缓冲更多的数据块、对数据表进行优化。
3. SQL*Net message from client
会话创建成功后，客户端对服务器发送请求，服务器处理后，将结果返回客户端，并继续等待客户端的请求，是空闲等待，如果不在发送请求，服务器一直处于等待状态。而小部分问题可能是网络问题。
4. Log file sync
用户会话行为导致，当一个会话发出commit命令时，等待LGWR将事务产生的redo写入重做日志文件中，当所有的redo保存到磁盘中后，另一个用户会话才能继续操作，而出现此等待事件原因是频繁commit或者rollback，过于频繁操作；LGWR写入磁盘慢影响IO性能缓慢。日志缓冲区太大会让LGWR懒惰，LOG_BUFFER写入的数量达不到_LOG_IO_SIZE无法触发LGWR写入日志的条件，只有提交或者3s醒来才能写入，这样会有太多的数据堆放在日志缓冲区等待处理；CPU负载高，RAC私有网络差。解决：可以分批处理操作，将日志文件放在raid0或raid10中，将_LOG_IO_SIZE参数调小，确保cpu的资源充足，CPU负载高时采用polling：主动监测LGWR完成，CPU负载低时用post/wait：用户会话等待LGWR通知操作完成。在两种方式之间切换，也不能太频繁。
5. Library cache lock / Library cache pin
在不同用户并发操作同一个数据库对象时导致资源争用，即一个用户在对数据库表进行DDL操作时，另一个用户也要访问这个表，就会发生这个事件，要等DDL操作完成后，才能继续操作。Lock和pin可以看成锁，lock管理进程并发，pin管理缓冲区的一致性。任何想要对已经锁住的对象进行操作时，就会出现等待事件。可能出现的情况：存储过程或函数运行时被编译或者对他们的权限进行更改，表DDL执行中，其他会话对这个表进行了DML或DDL操作。避免高峰时间操作。解决方法：了解相关的表和视图，查询信息，可以根据实际情况kill掉阻塞的会话，或者等待操作完毕再编译。
6. Log file switch (archiving needed / checkpoint incomplete)
归档模式下，在线日志切换时，需要切换的在线日志还没有被归档进程归档完成。在线日志切换到下一个日志时，要确保下一个日志归档完成，否则不允许覆盖，可能会导致归档日志信息不完整。出现事件原因可能是归档进程写入归档文件未成功。
日志切换时，要保证切换到的日志信息写入磁盘，比如脏数据库产生的redo log 写入磁盘，这样做可以在信息覆盖时可以通过redo信息恢复。
出现这个事件的原因可能时日志文件太小或日志组太少，有可能数据写入太慢。
7. Enqueue
队列等待，Lock的另一种描述，保护管理共享资源，数据库出现阻塞和等待，避免并发操作而损坏数据，比如保护一组数据，避免多个用户同时更新。常见的锁有ST、TM等。当有用户请求一个锁定的数据库对象资源时，会被放在一个队列中按排序等待被唤起。
8. Free buffer waits
当会话将数据块从磁盘读取到内存，就需要内存中有空闲的空间存放数据，而如果空间不足就产生等待事件。原因：data buffer太小，没有空闲空间；内存中脏数据太多，脏块写的太慢，数据库写入无法写入磁盘从而导致无法释放空间，dbwr数量太少。
9. Control file parallel write/ Control file sequential read
write数据库多个控制文件拷贝时，Oracle要保证信息能够同步到各个控制文件，这是一个并行的操作，而控制文件并行时，会产生写入频繁更新，日志文件切换频繁，会产生等待事件。一般控制文件的更新次数不多，不会发生这个等待事件，而当日志文件太小时，频繁的日志切换，控制文件更新时，发生控制文件的占用，就会出现等待事件的时间延长。也可能是过短或人为过多的检查点、日志下频繁的数据文件修改要更新控制文件、DML操作过多、I/O的性能缓慢等问题。可以考虑增大日志文件大小或者降低控制文件的拷贝数量。是否可以考虑异步IO能够实现并行写入，也可以将控制文件放在高速磁盘中，负载相对低的磁盘中，也可以将控制文件放在不同的磁盘中缓解争用。
read数据库读取控制文件信息时，要按顺序读取控制文件。就会产生这个事件。出现情况：备份控制文件、不同实例下的控制文件的共享、读取控制文件信息。和write相同的解决方法，考虑异步IO能够实现并行写入，也可以将控制文件放在负载相对低的运行速度快的磁盘中。
10. Direct path read / Direct path write
read会话将数据块直接读取到PGA中，这些被读取的数据是这个会话私有的，所以不需要放在SGA共享数据，出现这个事件是因为磁盘中有大量的临时数据或者PGA空闲空间不足、进程认为数据块会被用到而发出IO请求进行预读取、临时数据写入临时表空间被读到内存中但不适合位于内存中、并行查询中的子查询进程可能会产生等待事件。
write而相反，是会话将数据从PGA写入磁盘数据文件，而不经过SGA。出现原因是使用临时表空间排序内存不足，数据的直接加载，并行DML操作。多数是磁盘排序导致的，可以找到操作最频繁的数据文件临时文件，分散负载。
二、AWR报告分析
分析Elapsed和DB time
1057.92/16=66
66/140.03=0.47
cpu利用率47%
2h中DB_time 用了1057.92分钟，cpu的运行了47%
cpu60*16=960分钟
1057.92/60*16*100%=1.1
Cpu有110%花费在处理Oracle操作上，服务器平均负载很高
Top10的等待事件
wait avg (ms)超过20ms就要注意可能出现问题了
SQL执行消耗时间排序
Top1的问题语句是update，观察其2小时执行了10万次，相当于1s10次，相当不正常。
解决方法：去和业务确认语句，是否可以删除语句，如果可以，删除后和业务分析问题，恢复数据库，找原因，可能是业务的语句逻辑问题
