DB2 V9 ZOS - Настройка производительности

Question

Фон

В настоящее время я использую версию DB2 V9. Одна из моих хранимых процедур требует времени для выполнения. Я посмотрел BMC apptune и нашел следующий SQL. Существуют три таблицы, которые мы использовали для выполнения следующего запроса.
СЧЕТ стол, имеющий 3413 записи EXCHANGE_RATE оказывает 1267K записи БАЛАНС оказывает 113m записи

Кто-то недавно добавили следующий фрагмент кода в запросе. Я думаю, из-за этого у нас была проблема.

AND (((A.ACT <> A.EW_ACT)    
     AND (A.EW_ACT <> ' ')      
     AND (C.ACT = A.EW_ACT))   
    OR (C.ACT = A.ACT))     

Запрос

SELECT F1.CLO_LED        
INTO :H :H 
FROM (SELECT A.ACT, A.BNK, A.ACT_TYPE,         
      CASE WHEN :H = A.CUY_TYPE THEN DEC(C.CLO_LED, 21, 2)     
      ELSE DEC(MULTIPLY_ALT(C.CLO_LED, COALESCE(B.EXC_RATE, 0)), 21, 2)   
      END AS CLO_LED       
     FROM ACCOUNT A        
     LEFT OUTER JOIN EXCHANGE_RATE B     
     ON B.EFF_DATE = CURRENT DATE - 1 DAY   
     AND B.CURCY_FROM = A.CURNCY_TYPE  
     AND B.CURCY_TO = :H   
     AND B.STA_TYPE = 'A'     
     , BALANCE C       
     WHERE A.CUSR_ID = :DCL.CUST-ID 
     AND A.ACT = :DCL.ACT 
     AND A.EIG_RTN = :WS-BNK-ID     
     AND A.ACT_TYPE = :DCL.ACT-TYPE  
     AND A.ACT_CAT = :DCL.ACT-CAT 
     AND A.STA_TYPE = 'A'      
     AND (((A.ACT <> A.EW_ACT)    
      AND (A.EW_ACT <> ' ')      
      AND (C.ACT = A.EW_ACT))   
      OR (C.ACT = A.ACT))     
     AND C.BNK = :WS-BNK-ID     
     AND C.ACT_TYPE = :DCL.ACT-TYPE 
     AND C.BUS_DATE = :WS-DATE-FROM) F1            
WITH UR 

Answer 1

Там есть ряд Wierd вещей происходит в этом запросе. Наиболее подозрительным из них является смешивание явных объединений с синтаксисом implicit-join; честно говоря, я не уверен, как система интерпретирует это. Вы также используете одну и ту же переменную хоста для ввода и вывода; пожалуйста не делайте.
Кроме того, почему имена столбцов настолько коротки? DB2 (эта версия, по крайней мере) поддерживает имена столбцов, которые намного длиннее. Пожалуйста, сохраните здравомыслие людей, если это вообще возможно.

Мы не можем полностью сказать, почему все идет медленно - возможно, нам придется увидеть планы доступа. В то же время, вот ваш запрос, перестроенный в какой может быть быстрее форма:

SELECT CASE WHEN :inputType = a.cuy_type THEN DEC(b.clo_led, 21, 2) 
      ELSE DEC(MULTIPLY_ALT(b.clo_led, COALESCE(c.exc_rate, 0)), 21, 2) END 
INTO :amount :amountIndicator -- if you get results, do you need the indiciator? 
FROM Account as a 
JOIN Balance as b -- This is assumed to not be a 'left', given coalesce not used 
ON b.bnk = a.eig_rtn 
AND b.act_type = a.act_type 
AND b.bus_date = :ws-date-from 
AND ((a.act <> a.ew_act  -- something feels wrong here, but 
     AND a.ew_act <> ' ' -- without knowing the data, I don't 
     AND c.act = a.ew_act) -- want to muck with it. 
    OR c.act = a.act) 
LEFT JOIN Exchange_Rate as c 
ON c.eff_date = current_date - 1 day 
AND c.curcy_from = a.curncy_type 
AND c.sta_type = a.sta_type 
AND c.curcy_to = :destinationCurrency 
WHERE a.cusr_id = :dcl.cust-id 
AND a.act = :dcl.act 
AND a.eig_rtn = :ws-bnk-id 
AND a.act_type = :dcl.act-type 
AND a.act_cat = :dcl.act-cat 
AND a.sta_type = 'A' 
WITH UR 
FECTCH FIRST 1 ROW ONLY 

Несколько другие ноты:

1. указать только точно те столбцы, которые необходимы - при определенных обстоятельствах, это позволяет получить доступ только по индексу, в противном случае может потребоваться последующий доступ к таблице. Однако это, вероятно, не поможет.
2. COALESCE(c.exc_rate, 0) чувствует себя как-то - если обменный курс отсутствует, вы возвращаете сумму 0, которая в противном случае могла бы быть действительна сумма. Возможно, вам нужно будет вернуть какой-то индикатор или сделать его нормальным, а не внешним.

Кроме того, попробуйте и эту версию, и, возможно, вариант, где переменные хоста указаны в дополнение к условий между таблицами. Оптимизатор должен иметь возможность автоматически коммутировать значения, но не может быть в некоторых условиях (подробности реализации).