2012-05-31 2 views
0

나는 일련 번호를 계산하기 위해 윈도우 기능을 사용하고 있습니다 :비싼 오라클 윈도우 함수

SELECT R.ENCOUNTER_ID, 
     M.MEASURE_ID, 
     M.TAKEN_TIME, 
     M.VALUE, 
     row_number() OVER(PARTITION BY R.ENCOUNTER_ID, M.MEASURE_ID ORDER BY R.ENCOUNTER_ID, M.MEASURE_ID, TAKEN_TIME ASC) AS SEQ 

FROM RECORD R 
INNER JOIN MEASURE M ON R.ABC_ID=M.ABC_ID 

기록 테이블은 ABC_ID에 고유 인덱스 및 ENCOUNTER_ID에 고유하지 않은 인덱스가 있습니다.

MEASURE 테이블에는 ABC_ID 및 LINE (쿼리에 사용되지 않음)에 대한 고유 인덱스가 있습니다.

WINDOW     377871 
HASH JOIN     119702 
TABLE ACCESS RECORD FULL 278 
TABLE ACCESS MEASURE FULL 50696 

그것은 보인다

HASH JOIN     119702 
TABLE ACCESS RECORD FULL 278 
TABLE ACCESS MEASURE FULL 50696 

는 ROW_NUMBER()가있는 쿼리 계획을 설명하는 다음과 같은 수 있습니다 :는이 ROW_NUMBER()없이 쿼리에 대한 계획을 설명

이 (가) 다음 제공 (R.ENCOUNTER_ID 및 M.MEASURE_ID에서) 크로스 테이블 인덱스가 도움이되지만 지원되는지 확실하지 않습니다.

테이블의 통계가 업데이트되는 빈도를 모르겠습니다.

내 창 기능에서 더 나은 성능을 얻을 수있는 방법이 있습니까? 각 표가 추가 지표의 혜택을받을 수 있습니까?

+1

이것은 백그라운드에서 이미 최적화되었거나 도움이되지 않을 수도 있습니다.하지만'ORDER BY'에'R.ENCOUNTER_ID'와'M.MEASURE_ID'가 필요하다고 생각하지 않습니다. '분할 BY'. 각 파티션 내에서 각 열의 값은 모두 동일합니다. –

답변

1

해시 조인 후 높은 비용으로 인해 일반적으로 무시할 수있는 비용이 추가되므로 해시 조인이 디스크로 유출되었음을 알 수 있습니다. DBMS_Xplan을 사용하여 필요한 임시 공간을 추정하십시오.

메모리가 해시 조인에 제약이있는 경우 창 함수 또한 메모리 부족으로 고통을 겪습니다. Monitor v $ sql_workarea를 사용하여 다중 패스 정렬이 있는지 확인하고이 쿼리 중에 메모리 할당을 늘리는 것을 고려하십시오.

색인 생성에 대해서는 내가 할 수있는 일이 많다는 것을 의심 스럽습니다.