Рекомендации по настройке производительности -Plsql/sql-Database

Question

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

В MV referh программа пытается ссылаться на 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-х лет в пределах его более хуже предыдущего запроса.

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

Pls помочь

Answer 1

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

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

«Основной запрос, то есть скалярный подзапрос в списке выбора поэтому

Oracle показывает два независимых планов в таблице плана один для вождения запроса -.., Который имеет стоимость два, и один для скалярный подзапрос, который имеет стоимость 2083 каждый раз, когда он выполняется.

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