성능 조정 팁 -Plsql/sql-Database

프로덕션 환경에서 성능 문제가 있습니다. Mv 참조 프로그램은 거의 13-14 시간 동안 오래 실행됩니다.성능 조정 팁 -Plsql/sql-Database

MV 참조 프로그램에서 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 %의 데이터를 추출하려고합니다. 우리는 데이터로드가 이유라고 생각합니다. 우리는 위의 스크립트에 대한 성능을 향상 시키려고 노력하고 있습니다. 그래서 우리는 날짜 필터를 추가하여 데이터를 제한했습니다. 1 년 프로파일에 대한

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));

, 그것은 몇 가지 개선을 보여줍니다하지만 우리는 2 년 주면 그것보다 더 이전 쿼리보다 더 다양합니다.

성능을 개선하기위한 제안 사항.

Pls는 내가 정기적으로 외부에 스칼라 하위 쿼리가 조인 꺼내 줄

출처

2016-08-16 Ajay Shetty

설명 플랜, tkprof 및 ADDM 보고서와 같은 기본 프로파일 링 도구를 실행 했습니까? 여기에서는 시스템, 환경 및 많은 기타 세부 사항을 자세히 이해하지 않고도 몇 가지 쿼리를보고 성능 문제를 진단 할 사람이 없습니다. 죄송합니다. – OldProgrammer

점진적 새로 고침을 수행하고 있습니까? 아니면 완전 새로 고침? 두 번째 접근법은 비 결정적 함수 호출 ('sysdate')을 참조하기 때문에 완전히 새로 고침해야합니다. 소스 테이블의 MV 로그에 따라 첫 번째가 점진적 새로 고침을 수행 할 수 있습니다 (단순히 외부 조인을 수행하거나 인수 분해하는 것보다는 인라인 서브 쿼리가 확실하지 않습니다). 일반적으로 MV는 데이터를 집계하거나 원격 데이터베이스의 데이터를 복제하는 데 사용되지만 데이터베이스 링크 또는 집계 함수는 표시되지 않습니다. –

@JustinCave가 업데이트 주셔서 감사합니다. 빠른 새로 고침이 아닌 완전 새로 고침을하고 있습니다. 이유는 매일 평균 10k 레코드가 기본 테이블에 삽입되며 빠른 참조를 사용하면 시스템 성능이 저하됩니다. –

도움이됩니다.

스칼라 하위 쿼리의 원가 계산은 poor 일 수 있으며 다른 옵션을 지정하는 대신 많은 수의 단일 레코드 조회 (인덱스를 통한 것으로 추정)를 수행해야합니다.

는 "주요 질의는 선택 목록에 스칼라 하위 쿼리가

오라클 따라서 계획 테이블에 두 개의 독립적 인 계획 운전 쿼리에 대한 하나 보여줍니다 -.. 두 가지의 비용을 가지고 있으며, 하나 스칼라 서브 쿼리는 실행될 때마다 2083의 비용을 갖는다. 그러나 오라클은 스칼라 서브 쿼리가 실행되는 횟수를 "알지 못한다"(대부분의 경우 최악의 시나리오를 예측할 수 있음에도 불구하고). 쿼리의 총 비용에서 그 실행을 위해 어떠한 비용 공제도하지 않습니다. "

출처

2016-08-17 00:37:12

답변을 11g 및 이전 버전과 관련있는 것으로 표시하는 것이 좋습니다. Oracle 12c에서 옵티마이 저는 스칼라 서브 쿼리를 무효로하고 (일반적으로) 해시 조인으로 변환 할 수 있습니다. –

답변

관련 문제