分区解决LATCH FREE #98

系统有个详单的程序出现了阻塞，10000多个话单无法处理

打开pl/sql developer的SESSION工具一看，几乎所有相关进程都在等待98号latch

98 latch free -> cache buffers chains，相关的原因一般为低效率的SQL，热块，长散列链，一般处理该问题的方法应该是降低逻辑读

看了下相关的SQL，都基本是：
SELECT t.log_id, t.local_file_name, t.month_no, t.create_date
  from TB_ETL_FILE_Log_mtq t
 where t.rule_id = 241210
   and t.share_synchro = 1
   and t.treatment_flag = 0
   and not exists (select 1
          from pu_etl.tb_etl_file_log b
         where b.src_log_id = t.log_id
           and b.rule_id = 241110)
 order by log_id

首先，TB_ETL_FILE_Log_mtq 300W条数据，经过3个条件过滤后，还有40W条数据
该语句由8个进程以8组rule_id并发的跑，都是全表扫描

看来，这个LATCH FREE就是由于全表扫描+高并发引起的，通过索引来优化该语句已经不现实，取出的数据太多。

于是，考虑按照rule_id分区，做list分区，共8个分区
同时，将tb_etl_file_log 也按照rule_id分区，分8个区
为tb_etl_file_log添加src_log_id和rule_id上的local分区复合索引，避免回表

经过分区后，latch free消失，堵塞的队列得到释放

其实，这个latch free就是由于太高的程序的并行引起的。开始，我告诉开发，让其串行跑这个过程，他告诉我无法改，而且，并行肯定比串行快。。。晕，并口和串口的硬盘那个快？FC channel也是一种SCSI的串行实现。如果想这个代码并行跑加快速度，在没考虑分区的情况下，也应该是单个SQL的并行为好

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/8242091/viewspace-617725/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/8242091/viewspace-617725/