테이블 구조나 sql 문을 보지 못해서 뭐라 답변드리긴 뭐하지만..

실행계획에서 cost 가 제일 높은게 nested loop 와 group by부분이네요

row 데이터 건수가 많고 조건절에 걸려서 나오는 데이터도 많다면

hash join 을 써보시기 바라며

group 을 subset 별로 나눠서 할수 있다면 그런방법도 효율적일거같네요..

hash join을 제가 잘 몰라서;;

그리고 hint를 써보라는데

위에꺼 두개좀 알려주심 안될까요

저두 찾아보긴 할거지만 설명을 더 쉽게 해주실거 같아서;;

 http://blog.daum.net/idrlee/16100928

hash join 에 대한 알기쉬운 설명이 있어서 링크 올립니다.

hint 야 뭐 아시다시피 /*hash*/ 하시면되구요 링크 설명에도 있다시피

hash join 은 sort 과정이 필요치 않으므로 조건절에 걸러져서 나오는 결과수가 많다면 sort merge 나 nested loop join 보다 속도가 훨씬 빠릅니다.

subset 으로 나눠서 할수 있다면 그렇게 해보시란 예기는  group 되는 건수와 join 되는 건수의 양이

최소작업이 되는 부분을 찾으셔야 할거같네요..

속도증가는 parallel 를 사용하면 확실하게 효과는 나올텐데요..

헛.. 글이 날아가서 간략하게 다시 씁니다.

실행정보만 가지고, 쿼리 튜닝을 하는 것은 불가능에 가깝습니다(실제 테이블 정보가 있어야 가능).

그래도 추측을 해보자면, 옵티마이저는 쿼리 실행의 코스트를 상당히 작게(전체 다해도 25밖에 안될정도로) 예측했습니다. 그럼에도 실제 실행시간이 길게 나왔다면, 통계정보가 오래되었거나, 잘못되어 있을 가능성이 큽니다(최근의 대량의 데이터 변경이 있진 않았는지요?).

통계정보에서 데이터 건수가 적다고 예측되어 있을 경우, 옵티마이저는 적절치 않음에도 가능한한 유니크 인덱스를 사용하려는 경향이 있기에, 통계정보쪽에 좀 더 심증이 가네요.

좀더 정확한 튜닝을 위해선, 테이블 정보, 전체 쿼리등의 정보가 필요할 것으로 생각됩니다.