Hash join ending up in huge wait events

Question

Hi,
We are experiencing huge wait events ( direct path read temp , direct path write temp) on our Materialized View refresh in 10.2.0.4 version of oracle 10g in linux rhel5 environment while monitoring the refresh session from db console. While checking the explain plan of the mv query there is a huge hash_join (due to self join nature of the query) is shown. As advised in some dba forums, i have increased my pga_aggregate_target to a value of 4 gb from 1800 mb. The PGA_HIT % is raised to 60% from 58% ( just 2% improvement). But still my direct path read temp and direct path write temp wait event have not reduced and a huge temp space is taken for hash join.
Since we have some usage limit set by some hidden parameters for a each session on pga_aggregate_target, increase the size did not helped me much. The mv refresh is taking more than 5 hours ( sometimes it exceeds 5 hrs) to completes it refresh where as the same query in window (production) is completed less than two hours. Before a month, the refresh time in both environment was nearly close. But now it has changed and not able to figure it out.
STATISTICS have been collected regularly using dbms_gather_stats in both environment. Both mv refresh are scheduled to run using dbms_scheduler (Manual refresh). SGA_TARGET and other memory parameters are almost same.
Environment : Dataware house
O/s : RHEL 5
Oracle version : 10.2.0.4
Work_policy=auto
Is there any possibility to reduce this wait event and there by reducing the elapsed time? I am also interested to know changing the plan to use other sort will help? I don't know whether the details are sufficient to analyze this issue. If you need more details on this just let me know.
I really appreciate your help and thanks in advance to all.

Answer 1

Thans for your comments. Here is the code, explan plan and autotrace trace stat output.
SELECT lasg.employee_number "EMPLOYEE_NUM",
lasg.full_name "FULL_NAME",
lasg.person_id "PERSON_ID",
SUBSTR (lasg.organization, 1, 4) "DEPT",
casg.assign_start_date "EFFECTIVE_START_DATE",
casg.assign_end_date "EFFECTIVE_END_DATE",
hasg.organization "PRIOR_ORG",
casg.organization organization,
hasg.supervisor "PRIOR_SUPERVISOR",
casg.supervisor "SUPERVISOR_NAME",
hasg.location "PRIOR_LOCATION",
casg.location location,
hasg.job_title "PRIOR_TITLE",
casg.job_title job_name,
CASE
WHEN hasg.organization = casg.organization THEN 'No Change'
ELSE 'Change'
END
org_change,
CASE
WHEN hasg.location = casg.location THEN 'No Change'
ELSE 'Change'
END
loc_change,
CASE
WHEN hasg.supervisor = casg.supervisor THEN 'No Change'
ELSE 'Change'
END
sup_change,
CASE
WHEN hasg.job_title = casg.job_title THEN 'No Change'
ELSE 'Change'
END
job_change
FROM panad.data_employ_details lasg,
panad.data_employ_details casg,
panad.data_employ_details hasg
WHERE lasg.person_id = casg.person_id(+)
AND lasg.assign_end_date = (SELECT MAX (lasg2.assign_end_date)
FROM panad.data_employ_details lasg2
WHERE lasg.person_id = lasg2.person_id)
AND casg.person_id = hasg.person_id(+)
AND hasg.assign_start_date =
(SELECT MAX (hasg2.assign_start_date)
FROM panad.data_employ_details hasg2
WHERE hasg2.person_id = lasg.person_id
AND hasg2.assign_end_date < casg.assign_start_date)
| Id  | Operation                 | Name                       | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT          |                            |     1 |   303 |       | 10261  (91)| 00:02:04 |
|*  1 |  FILTER                   |                            |       |       |       |            |          |
|*  2 |   HASH JOIN               |                            |     1 |   303 |       | 10179  (91)| 00:02:03 |
|*  3 |    HASH JOIN              |                            |     5 |  1060 |       | 10095  (92)| 00:02:02 |
|*  4 |     HASH JOIN             |                            |  6786 |   960K|       | 10011  (93)| 00:02:01 |
|   5 |      VIEW                 | VW_SQ_1                    |  6786 |   225K|       |  9927  (94)| 00:02:00 |
|   6 |       HASH GROUP BY       |                            |  6786 |   384K|       |  9927  (94)| 00:02:00 |
|   7 |        MERGE JOIN         |                            |    50M|  2820M|       |  1427  (53)| 00:00:18 |
|   8 |         SORT JOIN         |                            | 31937 |   998K|  2776K|   367   (2)| 00:00:05 |
|   9 |          TABLE ACCESS FULL| DATA_EMPLOY_DETAILS            | 31937 |   998K|       |    82   (2)| 00:00:01 |
|* 10 |         SORT JOIN         |                            | 31937 |   810K|  2520K|   324   (2)| 00:00:04 |
|  11 |          TABLE ACCESS FULL| DATA_EMPLOY_DETAILS        | 31937 |   810K|       |    82   (2)| 00:00:01 |
|  12 |      TABLE ACCESS FULL    | DATA_EMPLOY_DETAILS        | 31937 |  3461K|       |    83   (3)| 00:00:01 |
|  13 |     TABLE ACCESS FULL     | DATA_EMPLOY_DETAILS        | 31937 |  2089K|       |    83   (3)| 00:00:01 |
|  14 |    TABLE ACCESS FULL      | DATA_EMPLOY_DETAILS        | 31937 |  2838K|       |    83   (3)| 00:00:01 |
|  15 |   SORT AGGREGATE          |                            |     1 |    13 |       |            |          |
|* 16 |    TABLE ACCESS FULL      | DATA_EMPLOY_DETAILS        |     5 |    65 |       |    82   (2)| 00:00:01 |
Predicate Information (identified by operation id):
   1 - filter("LASG"."ASSIGN_END_DATE"= (SELECT MAX("LASG2"."ASSIGN_END_DATE") FROM
              "PANAD"."DATA_EMPLOY_DETAILS" "LASG2" WHERE "LASG2"."PERSON_ID"=:B1))
   2 - access("CASG"."PERSON_ID"="HASG"."PERSON_ID" AND "HASG"."ASSIGN_START_DATE"="VW_COL_1")
   3 - access("LASG"."PERSON_ID"="CASG"."PERSON_ID" AND "PERSON_ID"="LASG"."PERSON_ID")
   4 - access("ROWID"=ROWID)
  10 - access(INTERNAL_FUNCTION("HASG2"."ASSIGN_END_DATE")<INTERNAL_FUNCTION("CASG"."ASSIGN_START_DATE")
       filter(INTERNAL_FUNCTION("HASG2"."ASSIGN_END_DATE")<INTERNAL_FUNCTION("CASG"."ASSIGN_START_DATE")
  16 - filter("LASG2"."PERSON_ID"=:B1)
37 rows selected.
- autot trace stat output -
5070 rows selected.
Statistics
      35203  recursive calls
          0  db block gets
    3675913  consistent gets
    4269882  physical reads
          0  redo size
    1046781  bytes sent via SQL*Net to client
       4107  bytes received via SQL*Net from client
        339  SQL*Net roundtrips to/from client
         69  sorts (memory)
          0  sorts (disk)
       5070  rows processed   I have tried running this query with paralell but not helped.
I have read the links provided by both of you. Dictionary and fixed table stats are collected as a routine.
From the link given byTaral, Greg Rahn has suggested that it is a bug as below.
Its bug 9041800 and there is a 10.2.0.4 backport available as of 01/29/10.How can i get this bug fixed since there is no explanation of what need to be done? Do i need to contact oracle support for the 10.2.0.4 backport for RHEL5?
Thanks in advance
Edited by: Karthikambalav on Mar 9, 2010 2:43 AM