和buffer相关的等待事件是因为热块，根据数据块类型，解决方法不同：
*表数据块：考虑将数据分布在更多的数据块上，减少数据块被多用户同时访问的频率。
*索引数据块：当一个表的主键用sequence生成键值时，索引最右边的叶子节点容易成为热块，可以考虑使用反向索引。
当把数据块从磁盘读入内存时，如果内存已无空闲空间，则会产生该等待事件，可能的原因有：
1）Data buffer太小，需增大Data buffer
2）内存中脏数据太多，需增加DBWR进程数
当用户频繁地读取或修改同样的数据块时，就会出现该等待事件，如果该等待事件很长，表示数据库中存在热块。
当发出一个commit命令时，LGWR进程会将相应的redo log从log buffer写到磁盘上，此时就会产生该事件。
如果存在大量该事件，则应检查存在用户在频繁的提交，多出现在OLTP系统中。
如果log buffer无空闲空间可用，则会出现该等待事件。
一般情况下，该等待事件出现的可能性很少，除非log buffer过小或I/O太差。
当对日志文件进行读时（如日志归档），会出现该等待事件。
该事件又分为两种类型：
1）checkpoint incomplete
日志切换时，如果下一个日志对应的某些脏数据库还未被写到磁盘上，则必须等待checkpoint完成，减少该等待事件的方法有：增大日志文件大小、增加日志文件组或提高DBWR的性能。
2）archiving needed
如果数据库处于归档模式，当日志切换时，如果下一个日志还为被归档，则必须等到该日志被归档后，才能完成切换。产生这种等待事件的原因一般都是arch进程死掉或太慢。
enqueue可以等同于锁，如果出现长时间的该等待，说明数据库中出现阻塞和锁。
*library cache
*library cache pin
*library cache pin allocation
*library cache load lock
和library cache相关的等待事件可以断定是共享池出现的问题，基本上是由不良SQL语句导致，如没有使用绑定变量等。