分割槽解決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/，如需轉載，請註明出處，否則將追究法律責任。