１．shared pool latch和library cache latch：

共享池基本上由库缓存和字典缓存构成
ＳＱＬ语句的操作过程中服务器进程需要访问共享池和高速缓存，如：发出 一个ＳＱＬ语句时，服务器进程首先要向共享池的库缓存中查看是否缓存有已编译过的版本，如果没有，就要重新分析，重新申请一个共享的ＳＱＬ区放置这个语句 的执行计划等等，这些操作都需要申请shared pool latch和library cache latch. 　如果本来可以共享的ＳＱＬ语句因为没有使用绑定变量，而频繁被重新分析，这样势必导致这些申请过多。还有一方面原因，如果library cache 太小，就会引起语句游标被挤出内存的现象。因此需要调整共享池，更有效解决方法是查看ＳＱＬ，避免低效率的ＳＱＬ。
如果使用共享服务器连接方式， 这种连接方式在ＳＧＡ方面要设置的内存高一些，用户个人ＵＧＡ可以小一些。设置大池，可以使共享池更加专用于缓存sql 和pl/sql, 这样有大内存调用要求时，如ＲＭＡＮ备份时，启用多个Ｉ／Ｏslaves，并行处理时，不会影响共享中缓存的经常被访问的而没有被cache进内存的块。 如果连接数太多时，应改变连接方式，使用专有服务器连接。

２．cache buffer lru chain latch

到ＳＱＬ语句 执行阶段，比如一个更新语句，更新某个数据块，服务器进程这时以要向高速缓存发出请求查询其中是否已经缓存有它要找的数据，如果没有，要从硬盘上把相应的 数据块拷贝一份放进高速缓存，这样还要搜索ＬＲＵ列表，找到一个自由buffer放置服务器进程从磁盘上读来的拷贝。这就需要申请cache buffers lru latch。当脏块需要被ＤＢＷｎ进程写入磁盘时，ＤＢＷｎ进程需要访问ＬＲＵ列表以便写脏块，具体的不必赘述。　全表扫描过的表会被放在ＬＲＵ列表的 lru端很快地被剔除出内存，会导致经常访问的数据块在高速缓存中停留的时间很短，因此建议经常访问的小型表要cache在内存里。不适当的索引导致优化 器不会去选择索引扫描而是选择全表扫描。　同样高速缓存设置得太大，导致ＤＢＷｎ进程经常疲于搜索ＬＲＵ列表去写脏块。因此，这方面的锁冲突要看具体情 况，如果因为全表扫描太多，那么就需要创建合适的索引，如果高速缓存太大，就调整调整缓存，如果高速缓存不能减少的话，而且你有多个ＣＰＵ的话，可以增加 ＤＢＷｎ进程。如果只有一个ＣＰＵ，那么使用dbwr I/O slaves进程效果要差些，因为slaves进程只能帮助Ｉ／Ｏ写脏块，不能帮助ＤＢＷＲ进程搜索ＬＲＵ列表。