解决Oracle BUFFER CACHE的数据块争用问题主要有以下两种思路：
重新设计应用。前面已经提到过，如果有1000个并发进程同时对一张表的同一个块进行扫描，那么要彻底解决“热”块问题就只能通过修改应用来解决。
利用已有的数据库技术，减少“热”块对系统性能的影响。减少“热”块对系统性能产生影响的一个核心思想就是让数据块中的数据尽可能地分散。一般来讲主要有以下几种分散数据的技术：
（1）从Oracle 9i开始，Oracle允许在同一个数据库中存在不同块大小的数据块，为了将数据尽可能地分散到不同的数据块中，可以考虑将数据存放在BLOCK SIZE较小的数据块中（如 2KB、4KB的数据块）。
（2）数据块的PCTFREE默认值为10%，即数据块中有10%的空间会留于UPDATE操作，为了将数据尽可能地分散到不同数据块，可以考虑将数据存放在PCTFREE较大的数据块中（如将PCTFREE设置为90）。
（3）表中添加固定大小的列，如，使用char（2000）增加行长度，进而使得数据分布到不同的数据块中。
Oracle至今没有提供一种特殊的语法以使创建表或者插入数据时可以指定数据存储到某个数据文件和数据块中，所以我们只能迂回地采用以上3种方法尽可能地将数据分布到不同数据块。但是，这3种方法在减少数据块争用的同时，却增加了管理数据块的负担。数据块数的增加意味着进程需要扫描块数的增加，意味着在BUFFER CACHE 中LATCH争用的增加。鱼和熊掌不可兼得，所以读者在使用以上技术时需要根据应用特点进行仔细的衡量和评估。
除了以上3种方法外，还可以使用以下常见的技术来解决数据块争用的问题：
（4）使用HASH分区表和HASH 簇表（HASH CLUSTER TABLE）。使用HASH 分区表可以使得原本在同一个块的数据经过HASH算法计算后分布到不同的数据块中。采用此方法同样可以有效减少数据块的争用，但是却加大了索引的CLUSTERING FACTOR，也就意味着当执行计划为索引范围扫描时，数据库的性能反而可能会急剧恶化。所以在采用这项技术时，需要评估系统中关于这张表的SQL语句执行计划情况，仔细权衡。
（5）使用反转键索引（REVERSE INDEX）。和HASH分区表类似，反转键索引适用于主键等值的查询，并不适合范围扫描查询。如果执行计划中多用范围扫描查询，那么使用反转键索引之后，系统的性能也可能急剧下降。
（6） 增大BUFFER CACHE大小。增大BUFFER CACHE到某个阀值之后，系统会自动调整BUFFER CACHE中的HASH BUCKET数量，原来的“热”链就有可能会被打散。如果内存和CPU资源都充足，配置比较大的BUFFER CACHE并不是一件坏事。但是有个原则，不能使系统产生交换。在RAC系统中，系统交换甚至会引起CLUSTER发生脑裂（Brain Split），导致某个节点自动重启。
（7）合理使用KEEP POOL和RECYCLE POOL。对于一些响应时间比较敏感的“热”表，如果在内存允许的情况下，可以将其KEEP进KEEP POOL中，由于KEEP POOL和DEFAULT POOL使用的是不同的WORKING SET，在产生CACHE BUFFERS LRU CHAIN LATCH争用时，使用多重缓冲池可以从某种程度上提高数据库性能。
（8）使用ASSM（自动段空间管理）。ASSM技术管理数据块使用位图代替了原来的FREELIST管理，使用该技术可以有效地减少段头的数据块争用。但使用ASSM技术会让索引的CLUSTER FACTOR有增大的趋势。此外在ASSM管理的表中，并发执行大量INSERT语句时可能会导致L1位图块争用，除了用分区技术分散L1位图块之外，还可以预先插入大批量的数据来提前递增表高水位线，产生更多可用的数据块和L1位图块，进而达到降低L1位图块争用的目的。
（9）加大数据块INTRANS参数可以有效减少事务槽等待而产生的块冲突。
