Советы по настройке производительности -Plsql/sql-База данных

Question

Мы сталкиваемся с проблемой производительности в производстве. Mv Referh программа работает долго, почти от 13 до 14 часов.

В программе MV ссылается, что программа пытается ссылаться на 5 MV. Среди этого один из MV работает долго.

Ниже приведен скрипт MV, который выполняется долго.

SELECT rcvt.transaction_id,
    rsh.shipment_num,
    rsh.shipped_date,
    rsh.expected_receipt_date,
    (select rcvt1.transaction_date from rcv_transactions rcvt1
    where rcvt1.po_line_id = rcvt.po_line_id
    AND rcvt1.transaction_type   = 'RETURN TO VENDOR'
    and rcvt1.parent_transaction_id=rcvt.transaction_id
    )transaction_date
  FROM rcv_transactions rcvt,
    rcv_shipment_headers rsh,
    rcv_shipment_lines rsl
  WHERE 1                     =1
  AND rcvt.shipment_header_id =rsl.shipment_header_id
  AND rcvt.shipment_line_id   =rsl.shipment_line_id
  AND rsl.shipment_header_id  =rsh.shipment_header_id
  AND rcvt.transaction_type   = 'RECEIVE';

Таблица отгрузки содержит миллионы записей, и вышеупомянутый запрос пытается извлечь почти 60-70% данных. Мы подозреваем, что причиной является загрузка данных. Мы пытаемся улучшить производительность вышеупомянутого сценария. Поэтому мы добавили фильтр даты, чтобы ограничить данные.

SELECT rcvt.transaction_id,
    rsh.shipment_num,
    rsh.shipped_date,
    rsh.expected_receipt_date,
    (select rcvt1.transaction_date from rcv_transactions rcvt1
    where rcvt1.po_line_id = rcvt.po_line_id
    AND rcvt1.transaction_type   = 'RETURN TO VENDOR'
    and rcvt1.parent_transaction_id=rcvt.transaction_id
    )transaction_date
  FROM rcv_transactions rcvt,
    rcv_shipment_headers rsh,
    rcv_shipment_lines rsl
  WHERE 1                     =1
  AND rcvt.shipment_header_id =rsl.shipment_header_id
  AND rcvt.shipment_line_id   =rsl.shipment_line_id
  AND rsl.shipment_header_id  =rsh.shipment_header_id
  AND rcvt.transaction_type   = 'RECEIVE'
    AND TRUNC(rsh.creation_date)  >=  NVL(TRUNC((sysdate - profile_value),'MM'),TRUNC(rsh.creation_date) );

Для 1-летнего профиля это показывает некоторое улучшение, но если мы дадим в течение 2-х лет диапазон, он будет хуже, чем предыдущий запрос.

Любые предложения по улучшению производительности.

Пожалуйста, помогите

Answer 1

Я бы вытащил этот скалярный подзапрос в обычное внешнее соединение.

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

Msgstr "Основной запрос имеет скалярный подзапрос в списке выбора.

Поэтому Oracle показывает два независимых плана в таблице планов. Один для основного запроса, стоимость которого равна двум, и один для скалярного подзапроса, стоимость которого составляет 2083 при каждом выполнении.

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