导致BUFFER CACHE内存不足主要有以下3个因素：
BUFFER CACHE内存不足。这是客观因素，巧妇难为无米之炊。如果短时间内无法解决内存不足的问题，在I/O和CPU资源足够的前提下，可以考虑将部分表使用直接路径读取，从而减少BUFFER CACHE的争用。此外，可以考虑将一些使用频率较低的大表放进RECYCLE POOL，减少DEFAULT BUFFER POOL内存的使用。
糟糕的SQL语句写法或执行计划。在这种情况下会将大量不必要的数据块读取至BUFFER CACHE中，进而冲击BUFFER CACHE的其他数据块。比如，T1表占用10000个数据块，应用程序却只需要其中1个数据块的数据。但全表扫描会将10000个数据块全部读进BUFFER CACHE。虽然服务进程会将这10000个数据块放在LRU链的COLD区域尾端，但难免需要牺牲一些本来在BUFFER CACHE中的数据块。另外，从磁盘上读取数据块需要调用操作系统内核指令，进入到BUFFER CACHE之前获得一系列相应的LATCH，这些操作都是非常消耗CPU资源的，CPU资源不足又会反过来影响BUFFER CACHE中LATCH资源的获取效率，进而造成恶性循环。所以在CPU资源不足的系统中，如果不综合考虑，盲目增加BUFFER CACHE将会导致更多的数据块涌进BUFFER CACHE，这可能会造成更加严重的后果。此外，CPU资源不足可能还会影响SHARED POOL中的LATCH的释放和获取，从而引发更大面积的数据库性能问题。
DBWR进程数不足或者存储性能缓慢。DBWR进程扫描LRU-W列表，然后将脏块写进数据文件。在写操作完成之后，脏块在BUFFER CACHE中的位置就可以被其他数据块使用，并重新挂载到LRU辅助列中了。如果系统突然运行大批量的DML语句，将会导致LRU-W列表中的脏块数量剧增。如果DBWR进程数不足或者存储性能缓慢，那么脏块的产生速度将远大于DBWR的写出速度，从而出现FREE BUFFER WAITS或者WRITE COMPELETE WAITS等相关的等待事件。当出现此类问题时，一般来讲主要看依次查看存储以下5个指标：
（1）磁盘繁忙程度------是否达到100%。
（2）磁盘的响应时间------大的I/O不超过20ms，小的I/O一般在5ms左右。
（3）IOPS是否正常------平均每张盘在150个左右。
（4）存储的CACHE是否正常。
（5）和存储相关的硬件是否正常。
如果以上5个指标全部正常，那么就要考虑是否可以通过设置数据库参数db_writer_processes来加大DBWR进程数了。在多CPU系统中，一般建议DBWR的进程数不要超过CPU数（在Oracle 10g中，db_writer_processes设置不能超过20个）。其理由很简单，整个系统并不是只有DBWR进程在运行，我们需要预留CPU时间片来给其他进程。但并不是说DBWR数绝对不能超过CPU数，在特殊的场景下这可能还会有特殊的用途，不能一概而论。接下来主要讨论BUFFER CACHE内存紧张导致数据库性能问题的一个案例。
注意 ：在系统出现FREE BUFFER WAITS等待事件时，不要贸然地执行刷BUFFER CACHE的SQL语句，执行该SQL语句反而会加大DBWR的负担，使得系统性能更加恶化。