Oracle查詢運行速度太慢（大約需要5小時）

Question

SELECT t1.member_id , 
    SUM(t1.paid_amt) AS paid_amt 
FROM 
    (SELECT DISTINCT fm.member_id, 
    fc.claim_skey_no, 
    fc.claim_id, 
    fc.claim_line_no , 
    CASE 
     WHEN fc.claim_type_cd = 'RX' 
     THEN NVL(fc.rx_paid_amt,0) -- For RX claims use rx_paid_amt as paid amount 
     ELSE NVL(fc.approved_amt,0) 
    END AS paid_amt -- For all other claims use approved_amt 
    , 
    CASE 
     WHEN fc.claim_type_cd = 'RX' 
     THEN fc.submit_dt --For RX claims use submit_dt as paid date 
     ELSE NVL(fc.paid_dt,NVL(fc.edi_eob_dt,NVL(fc.eob_run_dt,fc.outsource_vndr_paid_dt))) 
    END AS paid_dt --For all other claims use paid_dt 
    FROM dwprod.fct_claim fc , 
    dwprod.fct_member fm 
    WHERE fc.mbr_skey_no = fm.member_skey_no 
    -- The service_from_dt on the claim must be between the reimbursement time period. 
    AND fc.service_from_dt BETWEEN '31-MAY-2013' AND '30-Jun-2014' 
    -- The follwong 2 conditions make sure that the calims selected are final-status (unadjusted) 
    -- For non-RX claims, the adjust_type_cd must be Null and the dw_backout_tag must be Null or 'N' 
    -- For RX claims only the dw_backout_tag must be Null or 'N', the adjust_type_cd is ignored 
    AND 
    CASE 
     WHEN fc.claim_type_cd = 'RX' 
     THEN 1 
     WHEN fc.claim_type_cd <> 'RX' 
     AND fc.adjust_type_cd IS NULL 
     THEN 1 
     ELSE 0 
    END       = 1 
    AND NVL(fc.dw_backout_tag,'N') = 'N' 
    -- The claim must be in an 'Approved' status, indicated by a status_type_cd = 'A' 
    AND fc.status_type_cd = 'A' 
    -- QNXT claims must be in a 'PAID' status 
    -- Non QNXT claims in the warehouse are assumed to be paid - There are no pended RX claims. 
    AND 
    CASE 
     WHEN fc.dw_source_cd <> 'QNXT' 
     THEN 1 
     WHEN fc.dw_source_cd = 'QNXT' 
     AND fc.last_status_nm = 'PAID' 
     THEN 1 
     ELSE 0 
    END = 1 
    -- Dental claims are excluded 
    AND fc.dw_source_cd <> 'DBP' 
    -- Excludes any Medicare Non-RCI claims 
    AND 
    CASE 
     WHEN NVL(fc.program_nm,'OTHER') = 'MEDICAID' 
     AND NVL(fc.enroll_ratecode,'RCI') IN ('RCII','RCV','RCVII') 
     THEN 0 
     ELSE 1 
    END = 0 
    -- It Fits! claims are excluded 
    AND NVL(fc.expense_cat_nm,'Other') <> 'FITNESS' 
    AND NVL(fc.proc1_skey_no,12345) NOT IN (21586,21588,21589) 
    -- 
    AND 
    CASE 
     WHEN NVL(fc.program_nm,'OTHER') = 'MEDICAID' 
     AND NVL(fc.enroll_ratecode,'RCI') IN ('RCII','RCV','RCVII') 
     THEN 1 
     WHEN EXISTS 
     (SELECT 1 
     FROM dwprod.fct_member_enroll me 
     WHERE fm.member_skey_no = me.mbr_skey_no 
     AND fc.service_from_dt BETWEEN me.segment_effect_dt AND me.segment_term_dt 
     AND me.program_nm  = 'MEDICAID' 
     AND me.enroll_ratecode IN ('RCII','RCV','RCVII') 
     ) 
     THEN 1 
     ELSE 0 
    END = 1 
) t1 
    --Where t1.paid_dt < '31-JAN-2014' 
GROUP BY t1.member_id 
HAVING SUM(t1.paid_amt) > 175000 

Answer 1

運行解釋計劃以查看導致放緩的原因。從我的頭頂，這是什麼「殺」你：

WHEN EXISTS 
     (SELECT 1 
     FROM dwprod.fct_member_enroll me 
     WHERE fm.member_skey_no = me.mbr_skey_no 
     AND fc.service_from_dt BETWEEN me.segment_effect_dt AND me.segment_term_dt 
     AND me.program_nm  = 'MEDICAID' 
     AND me.enroll_ratecode IN ('RCII','RCV','RCVII') 
     ) 

看看你是否能以某種方式改變這種邏輯存在的東西具有更好的性能。解釋計劃是必須的！

Answer 2

FROM dwprod.fct_claim fc , 
    dwprod.fct_member fm 
WHERE fc.mbr_skey_no = fm.member_skey_no 

這個交叉連接實際上是一個內部連接。我不能說甲骨文是否會優化這一點，但我們沒有理由不使自己的工作更輕鬆：

FROM dwprod.fct_claim fc , 
    INNER JOIN dwprod.fct_member fm 
    ON fc.mbr_skey_no = fm.member_skey_no 

Answer 3

我會做一個半盲猜這裏，基於DW I」類似的查詢與...合作。 Oracle的優化被容易被混淆的謂詞如：

where (case when ... then ... else ... end) = 1; 

的原因是，甲骨文在嚴重估計選擇性。 像其他人說的那樣查看解釋計劃。如果您發現表dwprod.fct_claim的估計基數看起來太低，請嘗試展開case語句。

例如，而不是：

AND CASE WHEN fc.dw_source_cd <> 'QNXT' THEN 1 
      WHEN fc.dw_source_cd = 'QNXT' AND fc.last_status_nm = 'PAID' THEN 1 
                      ELSE 0 
     END = 1 

寫：

and ( fc.dw_source_cd <> 'QNXT' 
    or (fc.dw_source_cd = 'QNXT' and fc.last_status_nm = 'PAID') 
    ) 

最後說明。這在版本11中似乎不太成問題，但我還沒有時間去調查原因。