Оптимизация Oracle SQL: иерархический запрос

#sql #oracle #hierarchical

#sql #Oracle #иерархический

Вопрос:

У меня есть этот запрос, который получает список записей и отслеживает генеалогию каждой записи, но он выполняется вечно. Кто-нибудь может помочь мне повысить производительность?

   WITH root_nodes AS
  (SELECT distinct dlot.dim_lot_key AS lot_key, facility, lot
    FROM pedwroot.dim_lot dlot
    JOIN AT_LOT a
    ON (a.at_lot = dlot.lot AND a.at_facility = dlot.facility)
   WHERE (dlot.has_test_lpt = 'Y'
      or dlot.has_post_test_lpt = 'Y') and a.at_facility = 'MLA'),

    upstream_genealogy AS
    (SELECT /*  INDEX(fact_link_lot IX_R_FLLOT_DLOT_2)*/DISTINCT CONNECT_BY_ROOT         
           fllot.dst_lot_key AS root_lot_key,
           fllot.src_lot_key
     FROM pedwroot.fact_link_lot fllot
     CONNECT BY NOCYCLE PRIOR fllot.src_lot_key = fllot.dst_lot_key
     START WITH fllot.dst_lot_key IN (SELECT lot_key FROM root_nodes)),

   at_lst AS
    (Select *
      FROM pedwroot.dim_lot dlot_lst
       JOIN upstream_genealogy upgen
        ON (upgen.src_lot_key = dlot_lst.dim_lot_key)
        where dlot_lst.has_assembly_lpt = 'Y')

      SELECT distinct dlot_root.lot         AS AT_LOT,
            dlot_root.facility    AS AT_FACILITY,
            dfac_root.common_name AS AT_SITE,
            dlot_root.LTC         AS AT_LTC,
            al.lot                AS AT_LST,
            dlot_src.lot          AS FAB_LOT,
            dlot_src.facility     AS FAB_FACILITY,
            dfac_src.common_name  AS FAB_SITE
       FROM upstream_genealogy upgen
       JOIN at_lst al
       ON (upgen.root_lot_key = al.root_lot_key)
       JOIN pedwroot.dim_lot dlot_src
       ON (upgen.src_lot_key = dlot_src.dim_lot_key)
       JOIN pedwroot.dim_lot dlot_root
       ON (upgen.root_lot_key = dlot_root.dim_lot_key)
       JOIN pedwroot.fact_lot flot
       ON (dlot_root.dim_lot_key = flot.lot_key)
       JOIN pedwroot.dim_facility dfac_root
       ON (flot.facility_key = dfac_root.dim_facility_key)
       JOIN pedwroot.dim_facility dfac_src
      ON (flot.fab_facility_key = dfac_src.dim_facility_key)
       WHERE dlot_src.has_fab_lpt = 'Y';
  

Ниже приведен план объяснения этого запроса
введите описание изображения здесь

введите описание изображения здесь

Комментарии:

1. извините, explain_plan нечитаем из-за разрешения

2. но позвольте мне спросить — какие существуют индексы?

3. Лучше скопируйте план выполнения в виде обычного текста во что-то вроде pastebin.com

4. пожалуйста, просмотрите изображение плана объяснения на новой вкладке, и вы сможете увидеть более четкую копию, надеюсь, это поможет.

Ответ №1:

Внезапное изменение количества элементов с 11 миллионов до 1 выглядит как проблема. Удаляйте таблицы и предикаты из запроса, пока не выясните, что именно вызывает эту плохую оценку.

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

Комментарии:

1. что вы подразумеваете под удалением таблиц и предикатов из запроса? И если все в порядке, можете ли вы указать план объяснения, я не совсем понимаю, спасибо

2. Разбейте ваш запрос на более мелкие части, запустите их и сравните фактическое количество строк с расчетным количеством строк (количество элементов). Оценки мощности обычно ухудшаются по мере увеличения запроса, вы хотите найти первое место, где он идет не так. Например, если вы запускаете только root_nodes, каково фактическое и предполагаемое количество строк?

3. Я попытался запустить каждый из небольших запросов и обнаружил, что для запуска upstream_genealogy требуется вечность, но я не знаю, как его улучшить, есть предложения?