Need help in tuning Group by cube with 6 columns - sql

I want to aggregate data from table1 in all possible combinations of the 6 columns. Table1 has 60Million rows in it. The query is running for more than an hour and still not fetching any data. Need some help in tuning this
select /*+ parallel(a,8)*/
event_date,
a.COL1,
COL2,
COL3,
COL4,
COL5,
COL6,
count (distinct id) base_count,
count (distinct case when active_flg = 'Y' then id end) unique_active_cnt,
count (case when active_flg = 'Y' then id end) active_cnt,
GROUPING_ID (a.COL1,
COL2,
COL3,
COL4,
COL5,
COL6)
AS grp_id
from table1 partition (P2017_01) a
group by event_date,
cube (a.COL1,
COL2,
COL3,
COL4,
COL5,
COL6);
Explain plan for the above sql:-
Explain complete.
PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Plan hash value: 3317440810
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | Pstart| Pstop | TQ |IN-OUT| PQ Distrib |
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 392K| 81M| | 96682 (4)| 00:00:08 | | | | | |
| 1 | TEMP TABLE TRANSFORMATION | | | | | | | | | | | |
| 2 | PX COORDINATOR | | | | | | | | | | | |
| 3 | PX SEND QC (RANDOM) | :TQ10001 | 392K| 20M| | 1157 (5)| 00:00:01 | | | Q1,01 | P->S | QC (RAND) |
| 4 | LOAD AS SELECT (TEMP SEGMENT MERGE)| SYS_TEMP_0FDA4B738_9AA210CA | | | | | | | | Q1,01 | PCWP | |
| 5 | SORT GROUP BY ROLLUP | | 392K| 20M| 293M| 1157 (5)| 00:00:01 | | | Q1,01 | PCWP | |
| 6 | PX RECEIVE | | 4040K| 208M| | 1121 (2)| 00:00:01 | | | Q1,01 | PCWP | |
| 7 | PX SEND HASH | :TQ10000 | 4040K| 208M| | 1121 (2)| 00:00:01 | | | Q1,00 | P->P | HASH |
| 8 | PX BLOCK ITERATOR | | 4040K| 208M| | 1121 (2)| 00:00:01 | 25 | 25 | Q1,00 | PCWC | |
| 9 | TABLE ACCESS FULL | TABLE1 | 4040K| 208M| | 1121 (2)| 00:00:01 | 25 | 25 | Q1,00 | PCWP | |
| 10 | LOAD AS SELECT | SYS_TEMP_0FDA4B738_9AA210CA | | | | | | | | | | |
| 11 | PARTITION RANGE SINGLE | | 185K| 9224K| | 27366 (2)| 00:00:03 | 25 | 25 | | | |
| 12 | SORT GROUP BY ROLLUP | | 185K| 9224K| 278M| 27366 (2)| 00:00:03 | | | | | |
| 13 | TABLE ACCESS FULL | TABLE1 | 4040K| 196M| | 8081 (2)| 00:00:01 | 25 | 25 | | | |
| 14 | LOAD AS SELECT | SYS_TEMP_0FDA4B738_9AA210CA | | | | | | | | | | |
| 15 | PARTITION RANGE SINGLE | | 32686 | 1595K| | 26191 (2)| 00:00:03 | 25 | 25 | | | |
| 16 | SORT GROUP BY ROLLUP | | 32686 | 1595K| 278M| 26191 (2)| 00:00:03 | | | | | |
| 17 | TABLE ACCESS FULL | TABLE1 | 4040K| 192M| | 8081 (2)| 00:00:01 | 25 | 25 | | | |
| 18 | LOAD AS SELECT | SYS_TEMP_0FDA4B738_9AA210CA | | | | | | | | | | |
| 19 | PARTITION RANGE SINGLE | | 73 | 2336 | | 8374 (5)| 00:00:01 | 25 | 25 | | | |
| 20 | SORT GROUP BY ROLLUP | | 73 | 2336 | | 8374 (5)| 00:00:01 | | | | | |
| 21 | TABLE ACCESS FULL | TABLE1 | 4040K| 123M| | 8081 (2)| 00:00:01 | 25 | 25 | | | |
| 22 | LOAD AS SELECT | SYS_TEMP_0FDA4B738_9AA210CA | | | | | | | | | | |
| 23 | PARTITION RANGE SINGLE | | 15408 | 707K| | 8374 (5)| 00:00:01 | 25 | 25 | | | |
| 24 | SORT GROUP BY ROLLUP | | 15408 | 707K| | 8374 (5)| 00:00:01 | | | | | |
| 25 | TABLE ACCESS FULL | TABLE1 | 4040K| 181M| | 8081 (2)| 00:00:01 | 25 | 25 | | | |
| 26 | LOAD AS SELECT | SYS_TEMP_0FDA4B738_9AA210CA | | | | | | | | | | |
| 27 | PARTITION RANGE SINGLE | | 34 | 986 | | 8374 (5)| 00:00:01 | 25 | 25 | | | |
| 28 | SORT GROUP BY ROLLUP | | 34 | 986 | | 8374 (5)| 00:00:01 | | | | | |
| 29 | TABLE ACCESS FULL | TABLE1 | 4040K| 111M| | 8081 (2)| 00:00:01 | 25 | 25 | | | |
| 30 | LOAD AS SELECT | SYS_TEMP_0FDA4B738_9AA210CA | | | | | | | | | | |
| 31 | PARTITION RANGE SINGLE | | 6 | 168 | | 8374 (5)| 00:00:01 | 25 | 25 | | | |
| 32 | SORT GROUP BY ROLLUP | | 6 | 168 | | 8374 (5)| 00:00:01 | | | | | |
| 33 | TABLE ACCESS FULL | TABLE1 | 4040K| 107M| | 8081 (2)| 00:00:01 | 25 | 25 | | | |
| 34 | LOAD AS SELECT | SYS_TEMP_0FDA4B738_9AA210CA | | | | | | | | | | |
| 35 | PARTITION RANGE SINGLE | | 3 | 75 | | 8374 (5)| 00:00:01 | 25 | 25 | | | |
| 36 | SORT GROUP BY ROLLUP | | 3 | 75 | | 8374 (5)| 00:00:01 | | | | | |
| 37 | TABLE ACCESS FULL | TABLE1 | 4040K| 96M| | 8081 (2)| 00:00:01 | 25 | 25 | | | |
| 38 | PX COORDINATOR | | | | | | | | | | | |
| 39 | PX SEND QC (RANDOM) | :TQ20000 | 392K| 81M| | 97 (3)| 00:00:01 | | | Q2,00 | P->S | QC (RAND) |
| 40 | VIEW | | 392K| 81M| | 97 (3)| 00:00:01 | | | Q2,00 | PCWP | |
| 41 | PX BLOCK ITERATOR | | 392K| 20M| | 97 (3)| 00:00:01 | | | Q2,00 | PCWC | |
| 42 | TABLE ACCESS FULL | SYS_TEMP_0FDA4B738_9AA210CA | 392K| 20M| | 97 (3)| 00:00:01 | | | Q2,00 | PCWP | |
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Note
-----
- Degree of Parallelism is 8 because of table property
53 rows selected.

Related

Oracle SQL - VIEW PUSHED PREDICATE not happening when using dblink

I'm having performance issues executing the following query (Q1):
select
z_out.*,
a_out.id
from orders a_out, test z_out
where a_out.id=z_out.id and a_out.created>trunc(sysdate) and rownum<10
Table orders contains millions of rows; orders.id is the primary key and orders.craeted is indexed.
The view is:
create or replace view test as
select/*+qb_name(q_outer)*/
id,
min(value) keep (dense_rank first order by id) as value
from (
select/*+qb_name(q_inner)*/
id,
case
when substr(id, -1)<'5'
--and exists(select 1 from dual#db2)
then 'YYY'
end as attr_1
from orders a1
) a2, small_table b2
where b2.attr_1 in (nvl(a2.attr_1, '#'), '*')
group by id
where small_table b2 contains about 200 records (all the columns are varchar2).
Executing Q1 has great performances and the following execution plan:
Plan hash value: 2906430222
-----------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
-----------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 274 | 64 (0)| 00:00:01 | | |
|* 1 | COUNT STOPKEY | | | | | | | |
| 2 | NESTED LOOPS | | 1 | 274 | 64 (0)| 00:00:01 | | |
| 3 | PARTITION LIST ALL | | 1 | 22 | 59 (0)| 00:00:01 | 1 | 2 |
| 4 | PARTITION RANGE ALL | | 1 | 22 | 59 (0)| 00:00:01 | 1 | LAST |
| 5 | TABLE ACCESS BY LOCAL INDEX ROWID| ORDERS | 1 | 22 | 59 (0)| 00:00:01 | 1 | 29 |
|* 6 | INDEX RANGE SCAN | IDX_ORDERS_CREATED | 1 | | 57 (0)| 00:00:01 | 1 | 29 |
| 7 | VIEW PUSHED PREDICATE | TEST | 1 | 252 | 5 (0)| 00:00:01 | | |
|* 8 | FILTER | | | | | | | |
| 9 | SORT AGGREGATE | | 1 | 55 | | | | |
| 10 | NESTED LOOPS | | 259 | 14245 | 5 (0)| 00:00:01 | | |
|* 11 | INDEX UNIQUE SCAN | PK_ID | 1 | 14 | 2 (0)| 00:00:01 | | |
|* 12 | INDEX STORAGE FAST FULL SCAN | IDX_MN_AN_AD_ALL | 259 | 10619 | 3 (0)| 00:00:01 | | |
-----------------------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter(ROWNUM<10)
6 - access("A_OUT"."CREATED">TRUNC(SYSDATE#!))
8 - filter(COUNT(*)>0)
11 - access("ID"="A_OUT"."ID")
12 - storage("B2"."ATTR_1"=NVL(CASE WHEN SUBSTR("ID",(-1))<'5' THEN 'YYY' END ,'#') OR "B2"."ATTR_1"='*')
filter("B2"."ATTR_1"=NVL(CASE WHEN SUBSTR("ID",(-1))<'5' THEN 'YYY' END ,'#') OR "B2"."ATTR_1"='*')
Q1 performance issues happen when the line --and exists(select 1 from dual#db2) in the view is uncommented.
The new execution plan is:
Plan hash value: 3271081243
----------------------------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop | Inst |IN-OUT|
----------------------------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 288 | 5273K (1)| 00:03:27 | | | | |
|* 1 | COUNT STOPKEY | | | | | | | | | |
|* 2 | HASH JOIN | | 1 | 288 | 5273K (1)| 00:03:27 | | | | |
| 3 | JOIN FILTER CREATE | :BF0000 | 1 | 22 | 59 (0)| 00:00:01 | | | | |
| 4 | PARTITION LIST ALL | | 1 | 22 | 59 (0)| 00:00:01 | 1 | 2 | | |
| 5 | PARTITION RANGE ALL | | 1 | 22 | 59 (0)| 00:00:01 | 1 | LAST | | |
| 6 | TABLE ACCESS BY LOCAL INDEX ROWID| ORDERS | 1 | 22 | 59 (0)| 00:00:01 | 1 | 29 | | |
|* 7 | INDEX RANGE SCAN | IDX_ORDERS_CREATED | 1 | | 57 (0)| 00:00:01 | 1 | 29 | | |
| 8 | VIEW | TEST | 3840K| 974M| 5273K (1)| 00:03:27 | | | | |
| 9 | SORT GROUP BY | | 3840K| 201M| 5273K (1)| 00:03:27 | | | | |
| 10 | JOIN FILTER USE | :BF0000 | 994M| 50G| 5273K (1)| 00:03:27 | | | | |
| 11 | NESTED LOOPS | | 994M| 50G| 5273K (1)| 00:03:27 | | | | |
| 12 | INDEX FULL SCAN | PK_ID | 3840K| 51M| 66212 (1)| 00:00:03 | | | | |
|* 13 | INDEX STORAGE FAST FULL SCAN | IDX_MN_AN_AD_ALL | 259 | 10619 | 1 (0)| 00:00:01 | | | | |
| 14 | REMOTE | | | | | | | | DB2 | R->S |
----------------------------------------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter(ROWNUM<10)
2 - access("A_OUT"."ID"="Z_OUT"."ID")
7 - access("A_OUT"."CREATED">TRUNC(SYSDATE#!))
13 - filter("B2"."ATTR_1"=NVL(CASE WHEN (SUBSTR("ID",(-1))<'5' AND EXISTS (SELECT 0 FROM "A1")) THEN 'YYY' END ,'#') OR
"B2"."ATTR_1"='*')
Remote SQL Information (identified by operation id):
----------------------------------------------------
14 - EXPLAIN PLAN INTO PLAN_TABLE#! FOR SELECT 0 FROM "DUAL" "A1" (accessing 'DB2' )
I would like the view to be accessed n times, like in the first scenario.
I tried using hints but didn't succeed.
May be useful to say that even with the line and exists(select 1 from dual#db2) uncommented in the view, the following query has great performances (I know that is different from Q1).
select
(select value from test z_out where a_out.id=z_out.id) as value,
a_out.id
from orders a_out
where a_out.created>trunc(sysdate) and rownum<10
So, I guess the view works fine when it's accessed n times even if the line and exists(select 1 from dual#db2) is uncommented. But I'm not being able to force the execution plan in that direction.
If hints are necessary, I'd like to add them inside the view DDL only (if possible) so that who uses the view won't have to worry about it.
================================================================
Edit: the following were executed:
alter session set statistics_level = 'ALL';
-- Q1 (the query I'm having problems with)
select * from table (dbms_xplan.display_cursor (format=>'ALLSTATS LAST'));
Plan hash value: 3271081243
------------------------------------------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers | Reads | OMem | 1Mem | Used-Mem |
------------------------------------------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | | 0 |00:00:00.01 | 0 | 0 | | | |
|* 1 | COUNT STOPKEY | | 1 | | 0 |00:00:00.01 | 0 | 0 | | | |
|* 2 | HASH JOIN | | 1 | 1 | 0 |00:00:00.01 | 0 | 0 | 3789K| 3789K| 1078K (0)|
| 3 | JOIN FILTER CREATE | :BF0000 | 1 | 1 | 25602 |00:00:00.22 | 23345 | 161 | | | |
| 4 | PARTITION LIST ALL | | 1 | 1 | 25602 |00:00:00.21 | 23345 | 161 | | | |
| 5 | PARTITION RANGE ALL | | 2 | 1 | 25602 |00:00:00.21 | 23345 | 161 | | | |
| 6 | TABLE ACCESS BY LOCAL INDEX ROWID| ORDERS | 29 | 1 | 25602 |00:00:00.20 | 23345 | 161 | | | |
|* 7 | INDEX RANGE SCAN | IDX_CREATED | 13 | 1 | 25602 |00:00:00.12 | 474 | 161 | 1025K| 1025K| |
| 8 | VIEW | TEST | 1 | 3820K| 0 |00:00:00.01 | 0 | 0 | | | |
| 9 | SORT GROUP BY | | 1 | 3820K| 0 |00:00:00.01 | 0 | 0 | 73728 | 73728 | |
| 10 | JOIN FILTER USE | :BF0000 | 1 | 989M| 106M|00:03:38.87 | 60M| 52960 | | | |
| 11 | NESTED LOOPS | | 1 | 989M| 328M|00:03:04.11 | 60M| 52960 | | | |
| 12 | INDEX FULL SCAN | PK_ID | 1 | 3820K| 1245K|00:00:21.04 | 200K| 52959 | 1025K| 1025K| |
|* 13 | INDEX STORAGE FAST FULL SCAN | IDX_MN_AN_AD_ALL | 1245K| 259 | 328M|00:02:12.09 | 60M| 1 | 1025K| 1025K| |
| 14 | REMOTE | | 1 | | 1 |00:00:00.01 | 0 | 0 | | | |
------------------------------------------------------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter(ROWNUM<10)
2 - access("A_OUT"."ID"="Z_OUT"."ID")
7 - access("A_OUT"."CREATED">TRUNC(SYSDATE#!))
13 - filter(("B2"."ATTR_1"=NVL(CASE WHEN (SUBSTR("ID",(-1))<'5' AND IS NOT NULL) THEN 'YYY' END ,'#') OR "B2"."ATTR_1"='*'))
Note: Q1 performances prevent the query to complete if and exists(select 1 from dual#db2) in the view is uncommented. To get the previous execution plan I had to alter the session, run Q1, stop Q1 (after about 4 minutes) and then calculate the plan.
The following execution plan was generated the same way, but the view had the line --and exists(select 1 from dual#db2) commented (performances were good).
Plan hash value: 2906430222
-----------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers |
-----------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | | 9 |00:00:00.01 | 223 |
|* 1 | COUNT STOPKEY | | 1 | | 9 |00:00:00.01 | 223 |
| 2 | NESTED LOOPS | | 1 | 1 | 9 |00:00:00.01 | 223 |
| 3 | PARTITION LIST ALL | | 1 | 1 | 9 |00:00:00.01 | 41 |
| 4 | PARTITION RANGE ALL | | 1 | 1 | 9 |00:00:00.01 | 41 |
| 5 | TABLE ACCESS BY LOCAL INDEX ROWID| ORDERS | 14 | 1 | 9 |00:00:00.01 | 41 |
|* 6 | INDEX RANGE SCAN | IDX_CREATED | 12 | 1 | 9 |00:00:00.01 | 33 |
| 7 | VIEW PUSHED PREDICATE | TEST | 9 | 1 | 9 |00:00:00.01 | 182 |
|* 8 | FILTER | | 9 | | 9 |00:00:00.01 | 182 |
| 9 | SORT AGGREGATE | | 9 | 1 | 9 |00:00:00.01 | 182 |
| 10 | NESTED LOOPS | | 9 | 259 | 2376 |00:00:00.01 | 182 |
|* 11 | INDEX UNIQUE SCAN | PK_ID | 9 | 1 | 9 |00:00:00.01 | 20 |
|* 12 | INDEX STORAGE FAST FULL SCAN | IDX_MN_AN_AD_ALL | 9 | 259 | 2376 |00:00:00.01 | 162 |
-----------------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter(ROWNUM<10)
6 - access("A_OUT"."CREATED">TRUNC(SYSDATE#!))
8 - filter(COUNT(*)>0)
11 - access("ID"="A_OUT"."ID")
12 - storage(("B2"."ATTR_1"=NVL(CASE WHEN SUBSTR("ID",(-1))<'5' THEN 'YYY' END ,'#') OR
"B2"."ATTR_1"='*'))
filter(("B2"."ATTR_1"=NVL(CASE WHEN SUBSTR("ID",(-1))<'5' THEN 'YYY' END ,'#') OR
"B2"."ATTR_1"='*'))

How to debug an Oracle query given an explain plan?

IMAGE OF TOAD: query waits
WITH
NJ AS (SELECT CNATJUR FROM RE_CD.CDTD005_NATUR_JURIDICA WHERE DESCRICAO = 'Particulares' AND DTEND_VER = '9999-12-31 00:00' ),
PAISES AS (SELECT PAIS_BST FROM RE_CD.CDTD006_PAISES WHERE GRUPO_PAIS = 'RESTO UNIAO EUROPEIA' AND DTEND_VER = '9999-12-31 00:00' ),
GAR AS (SELECT /*+PARALLEL(4)*/ CCONTA, CREFERENCIA_IMP FROM RE_DM.DMTD002_GAR_CONTRATO WHERE TIPO_GAR = 'GAR REAL' AND TIPO_GAR2 = 'GAR DINERARIA' AND FLAG_PRIORIDADE = 1 AND IDVERSAO = (SELECT MAX(IDVERSAO) FROM RE_DM.DMTD001_VERSOES WHERE TABELA = 'RE_DM.DMTD002_GAR_CONTRATO' AND DTEND_VER = '9999-12-31 00:00' ) )
SELECT /*+PARALLEL(4)*/ MOROS.COD_PERIMETRO, MOROS.SOCIEDADE
FROM RE_DM.DMTF020_MOROS MOROS
INNER JOIN GAR ON MOROS.CCONTA = GAR.CCONTA AND MOROS.CREFERENCIA = GAR.CREFERENCIA_IMP
INNER JOIN NJ ON MOROS.COD_NATJUR = NJ.CNATJUR
INNER JOIN PAISES ON MOROS.COD_PAIS = PAISES.PAIS_BST
WHERE MOROS.IDVERSAO = 167
AND MOROS.SEGMENTO <> 'PC' AND MOROS.SEGMENTO <> 'LO' AND MOROS.SEGMENTO <> 'GA'
AND MOROS.SEGMENTO <> 'G1' AND MOROS.SEGMENTO <> 'G2' AND MOROS.SEGMENTO <> 'G3'
AND MOROS.INPUT = 'IMP'
AND MOROS.FLAG_MOROSIDADE = 0;
Plan hash value: 441958758
----------------------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | TQ |IN-OUT| PQ Distrib |
----------------------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 76752 | 16M| 22115 (1)| 00:01:07 | | | |
| 1 | PX COORDINATOR | | | | | | | | |
| 2 | PX SEND QC (RANDOM) | :TQ20002 | 76752 | 16M| 22113 (1)| 00:01:07 | Q2,02 | P->S | QC (RAND) |
|* 3 | HASH JOIN | | 76752 | 16M| 22113 (1)| 00:01:07 | Q2,02 | PCWP | |
| 4 | PX RECEIVE | | 42 | 1512 | 2 (0)| 00:00:01 | Q2,02 | PCWP | |
| 5 | PX SEND BROADCAST | :TQ20000 | 42 | 1512 | 2 (0)| 00:00:01 | Q2,00 | P->P | BROADCAST |
| 6 | PX BLOCK ITERATOR | | 42 | 1512 | 2 (0)| 00:00:01 | Q2,00 | PCWC | |
|* 7 | TABLE ACCESS FULL | CDTD006_PAISES | 42 | 1512 | 2 (0)| 00:00:01 | Q2,00 | PCWP | |
|* 8 | HASH JOIN | | 237K| 41M| 22110 (1)| 00:01:07 | Q2,02 | PCWP | |
| 9 | PX RECEIVE | | 23 | 1150 | 2 (0)| 00:00:01 | Q2,02 | PCWP | |
| 10 | PX SEND BROADCAST | :TQ20001 | 23 | 1150 | 2 (0)| 00:00:01 | Q2,01 | P->P | BROADCAST |
| 11 | PX BLOCK ITERATOR | | 23 | 1150 | 2 (0)| 00:00:01 | Q2,01 | PCWC | |
|* 12 | TABLE ACCESS FULL | CDTD005_NATUR_JURIDICA | 23 | 1150 | 2 (0)| 00:00:01 | Q2,01 | PCWP | |
| 13 | NESTED LOOPS | | | | | | Q2,02 | PCWP | |
| 14 | NESTED LOOPS | | 795K| 100M| 22105 (1)| 00:01:07 | Q2,02 | PCWP | |
| 15 | PX BLOCK ITERATOR | | | | | | Q2,02 | PCWC | |
|* 16 | TABLE ACCESS FULL | DMTD002_GAR_CONTRATO | 6357 | 341K| 4423 (1)| 00:00:14 | Q2,02 | PCWP | |
| 17 | SORT AGGREGATE | | 1 | 42 | | | Q2,02 | PCWP | |
| 18 | PX COORDINATOR | | | | | | | | |
| 19 | PX SEND QC (RANDOM) | :TQ10000 | 1 | 42 | | | Q1,00 | P->S | QC (RAND) |
| 20 | SORT AGGREGATE | | 1 | 42 | | | Q1,00 | PCWP | |
| 21 | PX BLOCK ITERATOR | | 1 | 42 | 2 (0)| 00:00:01 | Q1,00 | PCWC | |
|* 22 | TABLE ACCESS FULL | DMTD001_VERSOES | 1 | 42 | 2 (0)| 00:00:01 | Q1,00 | PCWP | |
|* 23 | INDEX RANGE SCAN | DMTF020_MOROS_INDEX2 | 21 | | 1 (0)| 00:00:01 | Q2,02 | PCWP | |
|* 24 | TABLE ACCESS BY INDEX ROWID| DMTF020_MOROS | 125 | 9750 | 3 (0)| 00:00:01 | Q2,02 | PCWP | |
----------------------------------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
3 - access("MOROS"."COD_PAIS"="PAIS_BST")
7 - filter("GRUPO_PAIS"='RESTO UNIAO EUROPEIA' AND "DTEND_VER"='9999-12-31 00:00')
8 - access("MOROS"."COD_NATJUR"="CNATJUR")
12 - filter("DESCRICAO"='Particulares' AND "DTEND_VER"='9999-12-31 00:00')
16 - filter("TIPO_GAR2"='GAR DINERARIA' AND "TIPO_GAR"='GAR REAL' AND "FLAG_PRIORIDADE"=1 AND "IDVERSAO"= (SELECT
MAX(SYS_OP_CSR(SYS_OP_MSR(MAX("IDVERSAO")),0)) FROM "RE_DM"."DMTD001_VERSOES" "DMTD001_VERSOES" WHERE
"TABELA"='RE_DM.DMTD002_GAR_CONTRATO' AND "DTEND_VER"='9999-12-31 00:00'))
22 - filter("TABELA"='RE_DM.DMTD002_GAR_CONTRATO' AND "DTEND_VER"='9999-12-31 00:00')
23 - access("MOROS"."CREFERENCIA"="CREFERENCIA_IMP")
filter("MOROS"."CREFERENCIA" IS NOT NULL)
24 - filter("MOROS"."IDVERSAO"=167 AND "MOROS"."CCONTA" IS NOT NULL AND TO_NUMBER("MOROS"."FLAG_MOROSIDADE")=0 AND
"MOROS"."INPUT"='IMP' AND "MOROS"."SEGMENTO"<>'GA' AND "MOROS"."SEGMENTO"<>'G1' AND "MOROS"."SEGMENTO"<>'PC' AND
"MOROS"."SEGMENTO"<>'G2' AND "MOROS"."SEGMENTO"<>'G3' AND "MOROS"."SEGMENTO"<>'LO' AND "MOROS"."CCONTA"="CCONTA")
Note
-----
- dynamic sampling used for this statement (level=5)
- Degree of Parallelism is 4 because of hint
Does anyone see something fishy with this "explain plan"? I've added indexes, I ran statistics, rebuild indexes... the server is a laptop with 8gb ram, SSD hard drive and i7 cpu.
Any ideas?

Obviously, look for your full table scans, but they aren't always the culprit. The problem appears to be in the nested loops.
I would focus on DMTD002_GAR_CONTRATO, and perhaps place an index to eliminate the
full table scan; however, I suspect that the main problem may be in the subquery in the where clause that creates table alias "GAR".
It would be worth experimenting with a hardcoded value rather than a subquery to see if it improves performance.

(Posted on behalf of OP).
Our temp tablespace was super tiny. After increasing the size all things start to go faster and smoother. Thanks to all that helped.

PerformanceTune#Huge Table Size

Looking for a help in PT.
Attaching the psuedo query..
There are 3 tables used below all are having huge chunk of records
t2 ~ 10 million,
t1 ~ 15 million ,
t3 ~ 8 million
Used Parallel Hints . But not much help in cost.. Cost is shooting to more than 200k
(SELECT /*+ parallel (a,8) parallel (b,8)*/
DISTINCT B.ACCNT_NUM
FROM s1.t1 a, s2.t2 b
WHERE a.accnt_num = b.accnt_num
AND product_key IN (SELECT product_key FROM s3.t3 WHERE prod_type_cd = 'S')
AND a.active_flg = 'Y'
AND a.deleted_flg = 'N'
GROUP BY B.ACCNT_NUM, a.product_key
HAVING COUNT (*) > 1)
Plan:
| 0 | SELECT STATEMENT
| 1 | 54 | 204K (1)| 00:47:39 | | | | | | | 1 | PX COORDINATOR | | | | | | | | | | |
| 2 | PX SEND QC (RANDOM) | :TQ10004 | 1 | 54 | 204K (1)| 00:47:39 | | | Q1,04 | P->S | QC (RAND) |
| 3 | HASH UNIQUE | | 1 | 54 | 204K (1)| 00:47:39 | | | Q1,04 | PCWP | |
| 4 | PX RECEIVE | | 1 | 54 | 204K (1)| 00:47:39 | | | Q1,04 | PCWP | |
| 5 | PX SEND HASH | :TQ10003 | 1 | 54 | 204K (1)| 00:47:39 | | | Q1,03 | P->P | HASH |
|* 6 | FILTER | | | | | | | | Q1,03 | PCWC | |
| 7 | HASH GROUP BY | | 1 | 54 | 204K (1)| 00:47:39 | | | Q1,03 | PCWP | |
| 8 | PX RECEIVE | | 1 | 54 | 204K (1)| 00:47:39 | | | Q1,03 | PCWP | |
| 9 | PX SEND HASH | :TQ10002 | 1 | 54 | 204K (1)| 00:47:39 | | | Q1,02 | P->P | HASH |
| 10 | HASH GROUP BY | | 1 | 54 | 204K (1)| 00:47:39 | | | Q1,02 | PCWP | |
|* 11 | HASH JOIN | | 90476 | 4771K| 204K (1)| 00:47:39 | | | Q1,02 | PCWP | |
| 12 | PX RECEIVE | | 22572 | 462K| 66147 (1)| 00:15:27 | | | Q1,02 | PCWP | |
| 13 | PX SEND BROADCAST | :TQ10001 | 22572 | 462K| 66147 (1)| 00:15:27 | | | Q1,01 | P->P | BROADCAST |
|* 14 | TABLE ACCESS BY LOCAL INDEX ROWID| table 1 | 22572 | 462K| 66147 (1)| 00:15:27 | | | Q1,01 | PCWP | |
| 15 | NESTED LOOPS | | 135K| 4893K| 198K (1)| 00:46:19 | | | Q1,01 | PCWP | |
| 16 | BUFFER SORT | | | | | | | | Q1,01 | PCWC | |
| 17 | PX RECEIVE | | | | | | | | Q1,01 | PCWP | |
| 18 | PX SEND BROADCAST | :TQ10000 | | | | | | | | S->P | BROADCAST |
| 19 | SORT UNIQUE | | 6 | 96 | 3 (0)| 00:00:01 | | | | | |
|* 20 | TABLE ACCESS FULL | table 3 | 6 | 96 | 3 (0)| 00:00:01 | | | | | |
| 21 | PX PARTITION HASH ALL | | 65923 | | 207 (1)| 00:00:03 | 1 | 32 | Q1,01 | PCWC | |
|* 22 | INDEX RANGE SCAN | I_table1 | 65923 | | 207 (1)| 00:00:03 | 33 | 64 | Q1,01 | PCWP | |
| 23 | PX BLOCK ITERATOR | | 12M| 201M| 5738 (2)| 00:01:21 | | | Q1,02 | PCWC | |
| 24 | INDEX FAST FULL SCAN | I_table 2 | 12M| 201M| 5738 (2)| 00:01:21 | | | Q1,02 | PCWP | |
Regards

So the eye is drawn to this line of the Explain Plan:
|* 20 | TABLE ACCESS FULL | table 3 | 6 | 96 | 3 (0)| 00:00:01 | | | | | |
The optimizer on the other hand thinks it has six rows, and so regards it as a very cheap operation. The OP says that t3 has ~ 8 million rows. A Full Table Scan of that will be pretty expensive.
The optimizer is clever but relies on accurate table and index statistics. It seems a good place to start would be a review of the pertinent statistics, and refreshing the ones which are inaccurate. Find out more.

Query statement consume quite long time on execution on oracle

I got task to improve existing code / query from my company,
Database version
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi
PL/SQL Release 10.2.0.4.0 - Production
"CORE 10.2.0.4.0 Production"
TNS for IBM/AIX RISC System/6000: Version 10.2.0.4.0 - Productio
NLSRTL Version 10.2.0.4.0 - Production
Here's the problem- when below code is executed, the time taken to finish the job is more than 4 hours, something around 7 to 8 hours.
395 row data within 3 hours 37 minutes
SELECT DISTINCT GROUP_DIST_NUMBER, BEGIN_DATE, PRICE_DROP_DATE
FROM (SELECT DISTINCT
G.GROUP_DIST_NUMBER,
TO_DATE (:B2, 'DD-MON-YYYY') BEGIN_DATE,
TO_DATE (:B2, 'DD-MON-YYYY') PRICE_DROP_DATE
FROM POS_DISTI_GROUP G,
POS_CUST_XREF M,
S_CPT_SEQ_NO C,
PP_STD_PRICE P,
S_CPT_AUDIT A,
RPT_PRODUCT_VALUE_LEVEL L
WHERE G.END_DATE > TO_DATE (:B2, 'DD-MON-YYYY')
AND G.GROUP_DIST_NUMBER = M.DIST_NUMBER
AND M.SG_BILL_TO_CUST_NO = A.BILL_TO_CUST_NO
AND A.START_DATE <= TO_DATE (:B2, 'DD-MON-YYYY')
AND A.END_DATE >= TO_DATE (:B2, 'DD-MON-YYYY')
AND L.PROD_VALUE = P.PROD_VALUE
AND L.PROD_LEVEL = P.PROD_LEVEL
AND C.CPT_PRICE_CODE IN
(SELECT /*+ PRECOMPUTE_SUBQUERY */
DISTINCT C1.CPT_PRICE_CODE
FROM PP_STD_PRICE P1,
S_CPT_PRICE_CODE C1,
S_CPT_SEQ_NO S1
WHERE P1.STDP_ID = :B1
AND C1.CPT_PRICE_CAT LIKE 'NB%'
AND C1.CPT_PRICE_CODE = S1.CPT_PRICE_CODE
AND S1.PRICE_PROTECTABLE = 'Y')
AND C.CPT_PRICE_CODE = P.CUST_PRICE_TYPE
AND P.STDP_ID = :B1
AND A.CUST_PRICE_TYPE = C.CPT_BILL_CODE
AND M.ACTIVE_IND != 'N'
AND (M.CATEGORY_TYPE LIKE 'DIRECT%' OR M.INDIRECT_DISTI = 'Y')
AND TRUNC (M.ARCHIVE_DATE) > TRUNC (SYSDATE)
UNION
SELECT G.GROUP_DIST_NUMBER,
P.BEGIN_DATE,
MIN (INVT.PRICE_DROP_DATE) PRICE_DROP_DATE
FROM POS_DISTI_GROUP G,
POS_CUST_XREF M,
PP_DEBIT_AUTHORIZATION P,
RPT_PRODUCT_VALUE_LEVEL L,
POS_PP_INVENTORY INVT
WHERE G.END_DATE > TO_DATE (:B2, 'DD-MON-YYYY')
AND G.GROUP_DIST_NUMBER = M.DIST_NUMBER
AND M.ACTIVE_IND != 'N'
AND (M.CATEGORY_TYPE LIKE 'DIRECT%' OR M.INDIRECT_DISTI = 'Y')
AND G.DIST_NUMBER = P.DIST_NUMBER
AND L.PROD_VALUE = P.PROD_VALUE
AND L.PROD_LEVEL = P.PROD_LEVEL
AND P.BEGIN_DATE >= TO_DATE (:B2, 'DD-MON-YYYY') - 6
AND P.BEGIN_DATE <= TO_DATE (:B2, 'DD-MON-YYYY')
AND INVT.DIST_NUMBER = G.GROUP_DIST_NUMBER
AND INVT.STMODEL = L.MOD_DESC
AND INVT.PPCF_SHOW_DATE = P.BEGIN_DATE
AND P.PRICE_TYPE = 'I'
AND ( P.POS_PROCESSED_FLAG IS NULL
OR P.POS_PROCESSED_FLAG != 'C')
AND P.POS_PP_FLAG = 'Y'
AND TRUNC (M.ARCHIVE_DATE) > TRUNC (SYSDATE)
GROUP BY G.GROUP_DIST_NUMBER, P.BEGIN_DATE)
ORDER BY GROUP_DIST_NUMBER;
I have no idea how to tune this query statement to improve the performance and make it execute faster
here the EXPLAIN PLAN
--------------------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Pstart| Pstop |
--------------------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 101 | 2525 | | 24156 (10)| | |
| 1 | SORT ORDER BY | | 101 | 2525 | | 24156 (10)| | |
| 2 | VIEW | | 101 | 2525 | | 24155 (10)| | |
| 3 | SORT UNIQUE | | 101 | 17691 | | 24155 (75)| | |
| 4 | UNION-ALL | | | | | | | |
|* 5 | HASH JOIN | | 10M| 1680M| | 6446 (5)| | |
|* 6 | TABLE ACCESS FULL | S_CPT_SEQ_NO | 651 | 5208 | | 5 (0)| | |
|* 7 | HASH JOIN | | 2383K| 379M| | 6318 (3)| | |
|* 8 | TABLE ACCESS FULL | POS_DISTI_GROUP | 100 | 1800 | | 5 (0)| | |
|* 9 | HASH JOIN | | 2396K| 340M| 4320K| 6283 (3)| | |
| 10 | VIEW | RPT_PRODUCT_VALUE_LEVEL | 138K| 2697K| | 1905 (3)| | |
| 11 | UNION-ALL | | | | | | | |
|* 12 | HASH JOIN RIGHT OUTER | | 13965 | 627K| | 91 (5)| | |
| 13 | INDEX FULL SCAN | PK_SEAEGO_PRODUCT_HIERARCHY | 298 | 4172 | | 1 (0)| | |
|* 14 | HASH JOIN RIGHT OUTER | | 13965 | 436K| | 89 (4)| | |
| 15 | INDEX FULL SCAN | PK_S_CAP_GROUP | 2 | 8 | | 1 (0)| | |
| 16 | TABLE ACCESS FULL | SMA_STMODEL | 13965 | 381K| | 87 (3)| | |
|* 17 | HASH JOIN RIGHT OUTER | | 14175 | 1065K| | 158 (5)| | |
| 18 | INDEX FAST FULL SCAN | PK_S_FAMILY | 1366 | 5464 | | 2 (0)| | |
|* 19 | HASH JOIN RIGHT OUTER | | 14175 | 1010K| | 156 (5)| | |
| 20 | INDEX FULL SCAN | PK_F_MODPRODMGR | 22 | 88 | | 1 (0)| | |
|* 21 | HASH JOIN | | 14175 | 955K| | 154 (4)| | |
| 22 | TABLE ACCESS FULL | SMA_PRODUCTMODEL | 14132 | 317K| | 62 (2)| | |
|* 23 | HASH JOIN RIGHT OUTER | | 13965 | 627K| | 91 (5)| | |
| 24 | INDEX FULL SCAN | PK_SEAEGO_PRODUCT_HIERARCHY | 298 | 4172 | | 1 (0)| | |
|* 25 | HASH JOIN RIGHT OUTER | | 13965 | 436K| | 89 (4)| | |
| 26 | INDEX FULL SCAN | PK_S_CAP_GROUP | 2 | 8 | | 1 (0)| | |
| 27 | TABLE ACCESS FULL | SMA_STMODEL | 13965 | 381K| | 87 (3)| | |
| 28 | MAT_VIEW ACCESS FULL | RPT_PROD_MV | 109K| 1288K| | 1656 (3)| | |
|* 29 | HASH JOIN | | 141K| 17M| | 3191 (3)| | |
|* 30 | INDEX RANGE SCAN | UK_PP_STD_PRICE_STDP_ID | 4128 | 108K| | 23 (0)| | |
|* 31 | HASH JOIN | | 5341 | 532K| | 3165 (3)| | |
|* 32 | TABLE ACCESS FULL | POS_CUST_XREF | 54 | 2268 | | 25 (4)| | |
|* 33 | HASH JOIN | | 193K| 11M| | 3137 (3)| | |
|* 34 | TABLE ACCESS FULL | S_CPT_AUDIT | 68 | 2108 | | 76 (4)| | |
|* 35 | HASH JOIN | | 745K| 20M| | 3052 (2)| | |
| 36 | TABLE ACCESS FULL | S_CPT_SEQ_NO | 1301 | 16913 | | 5 (0)| | |
| 37 | MERGE JOIN CARTESIAN | | 88205 | 1378K| | 3037 (2)| | |
|* 38 | INDEX RANGE SCAN | UK_PP_STD_PRICE_STDP_ID | 4128 | 20640 | | 23 (0)| | |
| 39 | BUFFER SORT | | 21 | 231 | | 3014 (2)| | |
|* 40 | TABLE ACCESS FULL | S_CPT_PRICE_CODE | 21 | 231 | | 1 (0)| | |
| 41 | HASH GROUP BY | | 1 | 191 | | 16421 (5)| | |
|* 42 | FILTER | | | | | | | |
| 43 | NESTED LOOPS | | 1 | 191 | | 16419 (5)| | |
|* 44 | HASH JOIN | | 7 | 1176 | | 16370 (5)| | |
|* 45 | HASH JOIN | | 74 | 8584 | | 4790 (3)| | |
|* 46 | HASH JOIN | | 60 | 3780 | | 31 (7)| | |
|* 47 | TABLE ACCESS FULL | POS_CUST_XREF | 60 | 2100 | | 25 (4)| | |
|* 48 | TABLE ACCESS FULL | POS_DISTI_GROUP | 100 | 2800 | | 5 (0)| | |
|* 49 | TABLE ACCESS FULL | PP_DEBIT_AUTHORIZATION | 345 | 18285 | | 4759 (3)| | |
| 50 | PARTITION RANGE ALL | | 18192 | 923K| | 11579 (6)| 1 | 33 |
|* 51 | INDEX FAST FULL SCAN | POS_PP_INVENTORY_PK | 18192 | 923K| | 11579 (6)| 1 | 33 |
|* 52 | VIEW | RPT_PRODUCT_VALUE_LEVEL | 1 | 23 | | 7 (0)| | |
| 53 | UNION ALL PUSHED PREDICATE | | | | | | | |
|* 54 | FILTER | | | | | | | |
| 55 | NESTED LOOPS OUTER | | 1 | 46 | | 2 (0)| | |
| 56 | NESTED LOOPS OUTER | | 1 | 42 | | 2 (0)| | |
| 57 | TABLE ACCESS BY INDEX ROWID | SMA_STMODEL | 1 | 28 | | 2 (0)| | |
|* 58 | INDEX UNIQUE SCAN | PK_SMA_STMODEL | 1 | | | 1 (0)| | |
|* 59 | INDEX UNIQUE SCAN | PK_SEAEGO_PRODUCT_HIERARCHY | 298 | 4172 | | 0 (0)| | |
|* 60 | INDEX UNIQUE SCAN | PK_S_CAP_GROUP | 2 | 8 | | 0 (0)| | |
| 61 | NESTED LOOPS OUTER | | 1 | 77 | | 3 (0)| | |
| 62 | NESTED LOOPS OUTER | | 1 | 73 | | 3 (0)| | |
| 63 | NESTED LOOPS OUTER | | 1 | 69 | | 3 (0)| | |
| 64 | NESTED LOOPS OUTER | | 1 | 65 | | 3 (0)| | |
| 65 | NESTED LOOPS | | 1 | 51 | | 3 (0)| | |
|* 66 | TABLE ACCESS BY INDEX ROWID| SMA_PRODUCTMODEL | 1 | 23 | | 2 (0)| | |
|* 67 | INDEX UNIQUE SCAN | PK_SMA_PRODUCTMODEL | 1 | | | 1 (0)| | |
| 68 | TABLE ACCESS BY INDEX ROWID| SMA_STMODEL | 1 | 28 | | 1 (0)| | |
|* 69 | INDEX UNIQUE SCAN | PK_SMA_STMODEL | 1 | | | 0 (0)| | |
|* 70 | INDEX UNIQUE SCAN | PK_SEAEGO_PRODUCT_HIERARCHY | 298 | 4172 | | 0 (0)| | |
|* 71 | INDEX UNIQUE SCAN | PK_S_FAMILY | 1366 | 5464 | | 0 (0)| | |
|* 72 | INDEX UNIQUE SCAN | PK_S_CAP_GROUP | 2 | 8 | | 0 (0)| | |
|* 73 | INDEX UNIQUE SCAN | PK_F_MODPRODMGR | 22 | 88 | | 0 (0)| | |
|* 74 | MAT_VIEW ACCESS BY INDEX ROWID | RPT_PROD_MV | 1 | 24 | | 2 (0)| | |
|* 75 | INDEX UNIQUE SCAN | IDX_RPT_PROD_MV_PROD_NO | 1 | | | 1 (0)| | |
--------------------------------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
5 - access("C1"."CPT_PRICE_CODE"="S1"."CPT_PRICE_CODE")
6 - filter("S1"."PRICE_PROTECTABLE"='Y')
7 - access("G"."GROUP_DIST_NUMBER"="M"."DIST_NUMBER")
8 - filter("G"."END_DATE">TO_DATE(:B2,'DD-MON-YYYY'))
9 - access("L"."PROD_VALUE"="P"."PROD_VALUE" AND "L"."PROD_LEVEL"="P"."PROD_LEVEL")
12 - access("ST"."MARKETING_NAME"="PH"."MARKETING_NAME"(+))
14 - access("ST"."MOD_CAPACITY_FORMATTED"="SCG"."MOD_CAPACITY_FORMATTED"(+))
17 - access("SF"."FAMILY"(+)=SUBSTRB("PM"."MODEL",1,3))
19 - access("PM"."DESIGN_APPLICATION"="DA"."DESIGN_APPLICATION"(+))
21 - access("PM"."MOD_DESC"="ST"."MOD_DESC")
23 - access("ST"."MARKETING_NAME"="PH"."MARKETING_NAME"(+))
25 - access("ST"."MOD_CAPACITY_FORMATTED"="SCG"."MOD_CAPACITY_FORMATTED"(+))
29 - access("C"."CPT_PRICE_CODE"="P"."CUST_PRICE_TYPE")
30 - access("P"."STDP_ID"=TO_NUMBER(:B1))
31 - access("M"."SG_BILL_TO_CUST_NO"="A"."BILL_TO_CUST_NO")
32 - filter("M"."SG_BILL_TO_CUST_NO" IS NOT NULL AND ("M"."INDIRECT_DISTI"='Y' OR "M"."CATEGORY_TYPE" LIKE 'DIRECT%') AND
"M"."ACTIVE_IND"<>'N' AND TRUNC(INTERNAL_FUNCTION("M"."ARCHIVE_DATE"))>TRUNC(SYSDATE#!))
33 - access("A"."CUST_PRICE_TYPE"="C"."CPT_BILL_CODE")
34 - filter("A"."START_DATE"<=TO_DATE(:B2,'DD-MON-YYYY') AND "A"."END_DATE">=TO_DATE(:B2,'DD-MON-YYYY'))
35 - access("C"."CPT_PRICE_CODE"="C1"."CPT_PRICE_CODE")
38 - access("P1"."STDP_ID"=TO_NUMBER(:B1))
40 - filter("C1"."CPT_PRICE_CAT" LIKE 'NB%')
42 - filter(TO_DATE(:B2,'DD-MON-YYYY')-6<=TO_DATE(:B2,'DD-MON-YYYY'))
44 - access("INVT"."DIST_NUMBER"="G"."GROUP_DIST_NUMBER" AND "INVT"."PPCF_SHOW_DATE"="P"."BEGIN_DATE")
45 - access("G"."DIST_NUMBER"="P"."DIST_NUMBER")
46 - access("G"."GROUP_DIST_NUMBER"="M"."DIST_NUMBER")
47 - filter(("M"."INDIRECT_DISTI"='Y' OR "M"."CATEGORY_TYPE" LIKE 'DIRECT%') AND "M"."ACTIVE_IND"<>'N' AND
TRUNC(INTERNAL_FUNCTION("M"."ARCHIVE_DATE"))>TRUNC(SYSDATE#!))
48 - filter("G"."END_DATE">TO_DATE(:B2,'DD-MON-YYYY'))
49 - filter("P"."PRICE_TYPE"='I' AND "P"."POS_PP_FLAG"='Y' AND ("P"."POS_PROCESSED_FLAG"<>'C' OR "P"."POS_PROCESSED_FLAG"
IS NULL) AND "P"."BEGIN_DATE"<=TO_DATE(:B2,'DD-MON-YYYY') AND "P"."BEGIN_DATE">=TO_DATE(:B2,'DD-MON-YYYY')-6)
51 - filter("INVT"."PPCF_SHOW_DATE"<=TO_DATE(:B2,'DD-MON-YYYY') AND "INVT"."PPCF_SHOW_DATE">=TO_DATE(:B2,'DD-MON-YYYY')-6)
52 - filter("L"."PROD_LEVEL"="P"."PROD_LEVEL")
54 - filter("P"."PROD_VALUE"="INVT"."STMODEL")
58 - access("ST"."MOD_DESC"="P"."PROD_VALUE")
59 - access("ST"."MARKETING_NAME"="PH"."MARKETING_NAME"(+))
60 - access("ST"."MOD_CAPACITY_FORMATTED"="SCG"."MOD_CAPACITY_FORMATTED"(+))
66 - filter("PM"."MOD_DESC"="INVT"."STMODEL")
67 - access("PM"."MODEL"="P"."PROD_VALUE")
69 - access("ST"."MOD_DESC"="INVT"."STMODEL")
70 - access("ST"."MARKETING_NAME"="PH"."MARKETING_NAME"(+))
71 - access("SF"."FAMILY"(+)=SUBSTRB("PM"."MODEL",1,3))
72 - access("ST"."MOD_CAPACITY_FORMATTED"="SCG"."MOD_CAPACITY_FORMATTED"(+))
73 - access("PM"."DESIGN_APPLICATION"="DA"."DESIGN_APPLICATION"(+))
74 - filter("MOD_DESC"="INVT"."STMODEL")
75 - access("PROD_NO"="P"."PROD_VALUE")
Note
-----
- 'PLAN_TABLE' is old version
and the statistic of rows count for table
TABLE_Name NUM_ROWS
----------- ---------
POS_DISTI_GROUP 2009
POS_CUST_XREF 2801
S_CPT_SEQ_NO 1301
PP_STD_PRICE 2658450
S_CPT_AUDIT 27200
PP_DEBIT_AUTHORIZATION 1199420
POS_PP_INVENTORY 7276850
PP_STD_PRICE 2658450
S_CPT_PRICE_CODE 192
S_CPT_SEQ_NO 1301
SMA_STMODEL 13965
RPT_PROD_MV 109980
create table statement. CLICK HERE
Table Description. CLICK HERE
Retrieve EXPLAIN PLAN with rerun gather_plan_statistics as #jonearles suggest. CLICK HERE
*link from google doc

The problem
Aggregation is happening too late in the execution plan. Plan IDs 4 and 5 generate 13 billion rows and account for 95% of the execution time. Oracle incorrectly believes the number of rows will be smaller, and that earlier aggregations should be merged together.
Plan IDs 6 through 40 represent the first half of the inline view, before the UNION. That part of the query has two DISTINCTs, yet there are no types of aggregation operations for that part of the execution plan. Oracle incorrectly thinks it's better to join everything first and perform one SORT UNIQUE, instead of performing multiple SORT UNIQUE or HASH GROUP BY and combining the results.
Reproduce the problem
Fully reproducing this problem without a full export is almost impossible. Even though it's only a moderately complicated SQL statement there are thousands of variables involved. The code below only demonstrates how Oracle can incorrectly merge aggregation operations.
First, create two simple tables. Each has 100K rows. TEST1 has numbers from 1 to 100000. TEST2 contains 100000 rows, but only one distinct number. To artificially make a bad plan, statistics are gathered too soon on TEST2. The optimizer thinks that TEST2 only has one row but it really has 100000.
drop table test1 purge;
drop table test2 purge;
create table test1(a number);
create table test2(a number);
insert into test1 select level from dual connect by level <= 100000;
insert into test2 values (1);
commit;
begin
dbms_stats.gather_table_stats(user, 'test1');
dbms_stats.gather_table_stats(user, 'test2');
end;
/
insert into test2 select 1 from dual connect by level <= 100000;
commit;
The sample query below retrieves all distinct TEST1.A where A is also in distinct TEST2.A.
By default, using the artificially bad statistics, Oracle joins the tables first and then performs the HASH GROUP BY and HASH UNIQUE. This is a bad plan, it joins all
100K values from TEST2. It would be better to perform the HASH GROUP BY first and then only join 1 row from that table.
explain plan for
select distinct a from test1 where a in (select a from test2 group by a);
select * from table(dbms_xplan.display(format => 'outline'));
------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 8 | 79 (2)| 00:00:01 |
| 1 | HASH UNIQUE | | 1 | 8 | 79 (2)| 00:00:01 |
| 2 | HASH GROUP BY | | 1 | 8 | 79 (2)| 00:00:01 |
|* 3 | HASH JOIN | | 1 | 8 | 79 (2)| 00:00:01 |
| 4 | TABLE ACCESS FULL| TEST2 | 1 | 3 | 3 (0)| 00:00:01 |
| 5 | TABLE ACCESS FULL| TEST1 | 100K| 488K| 76 (2)| 00:00:01 |
------------------------------------------------------------------------------
Potential Solution #1: Hints
Unfortunately there are no official hints to control when and where sorting and grouping happen. By playing around with the outline format option I was able to find a few potentially helpful hints: USE_HASH_AGGREGATION, OUTLINE_LEAF, and PLACE_DISTINCT. (These hints are really tricky - the reason I used a group by instead of another distinct in my sample is because I had so much trouble with the PLACE_DISTINCT hint!)
Using these undocumented hints can build a better plan. The results from TEST2 go through a HASH GROUP BY right away, as they should. This is similar to the plan that would be produced if the statistics were accurate.
explain plan for
select /*+ USE_HASH_AGGREGATION(#"SEL$5DA710D3") OUTLINE_LEAF(#"SEL$683B0107") */
distinct a from test1 where a in (select a from test2 group by a);
select * from table(dbms_xplan.display(format => 'outline alias'));
----------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
----------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 8 | 79 (2)| 00:00:01 |
| 1 | HASH UNIQUE | | 1 | 8 | 79 (2)| 00:00:01 |
|* 2 | HASH JOIN SEMI | | 1 | 8 | 79 (2)| 00:00:01 |
| 3 | VIEW | VW_NSO_1 | 1 | 3 | 3 (0)| 00:00:01 |
| 4 | HASH GROUP BY | | 1 | 3 | 3 (0)| 00:00:01 |
| 5 | TABLE ACCESS FULL| TEST2 | 1 | 3 | 3 (0)| 00:00:01 |
| 6 | TABLE ACCESS FULL | TEST1 | 100K| 488K| 76 (2)| 00:00:01 |
----------------------------------------------------------------------------------
Potential Solution #2: Force a plan with ROWNUM.
A much simpler and safer version of the above is to use ROWNUM. ROWNUM is a pseudocolumn that represents the order of the rows returned. When there is a ROWNUM Oracle cannot move the distinct and group by because it would affect that order.
Unfortunately, this trick requires extra code and generates extra steps in the plan. Those extra steps are mostly just passing data through and shouldn't slow things done much.
explain plan for
select distinct a from test1 where a in
(
--Extra level only because we only want to project one column.
--It's syntactically required, but the optimizer throws out this inline view.
select a
from
(
--The ROWNUM forces everything in this inline view to happen separately.
select a, rownum
from
(
select a from test2 group by a
)
)
);
select * from table(dbms_xplan.display(format => 'outline alias'));
---------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
---------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 8 | 79 (2)| 00:00:01 |
| 1 | HASH UNIQUE | | 1 | 8 | 79 (2)| 00:00:01 |
|* 2 | HASH JOIN SEMI | | 1 | 8 | 79 (2)| 00:00:01 |
| 3 | VIEW | | 1 | 3 | 3 (0)| 00:00:01 |
| 4 | COUNT | | | | | |
| 5 | VIEW | | 1 | 3 | 3 (0)| 00:00:01 |
| 6 | HASH GROUP BY | | 1 | 3 | 3 (0)| 00:00:01 |
| 7 | TABLE ACCESS FULL| TEST2 | 1 | 3 | 3 (0)| 00:00:01 |
| 8 | TABLE ACCESS FULL | TEST1 | 100K| 488K| 76 (2)| 00:00:01 |
---------------------------------------------------------------------------------
Potential Solution #3: Fix cardinality estimates and hope for the best.
If the estimated number of rows is accurate the plan is almost always good. When the row estimates are far off, find the first part of the execution plan where the cardinality is wrong. For this plan, it appears to be plan ID 36. E-Rows and A-Rows are off by an order of magnitude:
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers | Reads | OMem | 1Mem | O/1/M |
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------
...
|* 36 | TABLE ACCESS FULL | POS_CUST_XREF | 1 | 54 | 579 |00:00:00.01 | 131 | 0 | | | |
Step 36 has a complex predicate that involves SYSDATE.
36 - filter(("M"."SG_BILL_TO_CUST_NO" IS NOT NULL AND ("M"."INDIRECT_DISTI"='Y' OR "M"."CATEGORY_TYPE" LIKE 'DIRECT%') AND "M"."ACTIVE_IND"<>'N' AND
TRUNC(INTERNAL_FUNCTION("M"."ARCHIVE_DATE"))>TRUNC(SYSDATE#!)))
Even with up-to-date statistics that condition is going to be difficult to predict. Dynamic sampling may help. Try re-running the query with a top-level hint like this:
SELECT /*+ dynamic_sampling(6) */ ...
Fixing those early discrepancies will usually fix other problems later in the plan. This example is only one possible source of cardinality mismatches. Other tricks may be necessary to improve other cardinality estimates. This can be a very difficult method but it can pay off in multiple ways.
Red Herrings
There are many potential improvements to any moderately complicated SQL statement. There are several good ideas in the comments and answers. But when tuning it is always imperative to focus on what is slowest, not what is easiest to fix. It sounds obvious, but it's a very easy trap to fall into. That's why I asked you to use /*+ gather_plan_statistics*/, and that's why my answer only focuses on the parts of the plan with a large actual time.
For example, in my earlier comment I suggested looking at the NESTED LOOPS where ROWS=1. Now that we have the actual time we know that suggestion is not helpful. (Although in general you should still be skeptical of a plan with large tables but ROWS=1.)

Before rewriting the query, could you please reply with plan and run time for this query?
Follow Up:
Adding Parallel hint
Adding partition clause in select
The precompute_subquery hint will take subquery text out of the subquery section, fire it separately (before running main query) in a recursive call context, fetch the results and pass these to main query "filter" condition as a list of OR conditions. This is called subquery unfolding I think and it's different from the query block unparsing which is used for distributed queries. I've seen it used in OLAP queries.
As this is an undocumented hint, it should not be used by developers! The subquery is actually executed during soft parsing time, thus multiple executions of the same child cursor may potentially return wrong results if resultset of the subquery changes (unless Oracle always forces another full parse of these cursors somehow - in which case you can end up with library cache/shared pool latch contention if misusing this feature). So I removed it and used parallel for huge tables.
Also dont use Order by which overkills the query run time.
SELECT
DISTINCT GROUP_DIST_NUMBER,
BEGIN_DATE,
PRICE_DROP_DATE
FROM
(SELECT /*+ PARALLEL (P,4) PARALLEL (L,4)*/
DISTINCT
G.GROUP_DIST_NUMBER,
TO_DATE ( :B2,
'DD-MON-YYYY' )
BEGIN_DATE,
TO_DATE ( :B2,
'DD-MON-YYYY' )
PRICE_DROP_DATE
FROM
POS_DISTI_GROUP G,
POS_CUST_XREF M,
S_CPT_SEQ_NO C,
PP_STD_PRICE P,
S_CPT_AUDIT A,
RPT_PRODUCT_VALUE_LEVEL L
WHERE
G.END_DATE > TO_DATE ( :B2,
'DD-MON-YYYY' )
AND G.GROUP_DIST_NUMBER = M.DIST_NUMBER
AND M.SG_BILL_TO_CUST_NO = A.BILL_TO_CUST_NO
AND A.START_DATE <= TO_DATE ( :B2,
'DD-MON-YYYY' )
AND A.END_DATE >= TO_DATE ( :B2,
'DD-MON-YYYY' )
AND L.PROD_VALUE = P.PROD_VALUE
AND L.PROD_LEVEL = P.PROD_LEVEL
AND C.CPT_PRICE_CODE IN
(SELECT /*+ PARALLEL (P1,4)*/
DISTINCT C1.CPT_PRICE_CODE
FROM
PP_STD_PRICE P1,
S_CPT_PRICE_CODE C1,
S_CPT_SEQ_NO S1
WHERE
P1.STDP_ID = :B1
AND C1.CPT_PRICE_CAT LIKE 'NB%'
AND C1.CPT_PRICE_CODE = S1.CPT_PRICE_CODE
AND S1.PRICE_PROTECTABLE = 'Y')
AND C.CPT_PRICE_CODE = P.CUST_PRICE_TYPE
AND P.STDP_ID = :B1
AND A.CUST_PRICE_TYPE = C.CPT_BILL_CODE
AND M.ACTIVE_IND != 'N'
AND ( M.CATEGORY_TYPE LIKE 'DIRECT%'
OR M.INDIRECT_DISTI = 'Y' )
AND TRUNC ( M.ARCHIVE_DATE ) > TRUNC ( SYSDATE )
UNION
SELECT /*+ PARALLEL (P,4) PARALLEL (L,4) */
G.GROUP_DIST_NUMBER,
P.BEGIN_DATE,
MIN ( INVT.PRICE_DROP_DATE ) PRICE_DROP_DATE
FROM
POS_DISTI_GROUP G,
POS_CUST_XREF M,
PP_DEBIT_AUTHORIZATION P,
RPT_PRODUCT_VALUE_LEVEL L,
POS_PP_INVENTORY PARTITION ("F2011_Q2") INVT
WHERE
G.END_DATE > TO_DATE ( :B2,
'DD-MON-YYYY' )
AND G.GROUP_DIST_NUMBER = M.DIST_NUMBER
AND M.ACTIVE_IND != 'N'
AND ( M.CATEGORY_TYPE LIKE 'DIRECT%'
OR M.INDIRECT_DISTI = 'Y' )
AND G.DIST_NUMBER = P.DIST_NUMBER
AND L.PROD_VALUE = P.PROD_VALUE
AND L.PROD_LEVEL = P.PROD_LEVEL
AND P.BEGIN_DATE >= TO_DATE ( :B2,
'DD-MON-YYYY' )
- 6
AND P.BEGIN_DATE <= TO_DATE ( :B2,
'DD-MON-YYYY' )
AND INVT.DIST_NUMBER = G.GROUP_DIST_NUMBER
AND INVT.STMODEL = L.MOD_DESC
AND INVT.PPCF_SHOW_DATE = P.BEGIN_DATE
AND P.PRICE_TYPE = 'I'
AND ( P.POS_PROCESSED_FLAG IS NULL
OR P.POS_PROCESSED_FLAG != 'C' )
AND P.POS_PP_FLAG = 'Y'
AND TRUNC ( M.ARCHIVE_DATE ) > TRUNC ( SYSDATE )
GROUP BY
G.GROUP_DIST_NUMBER,
P.BEGIN_DATE);
EXPLAIN PLAN
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Pstart| Pstop | TQ |IN-OUT| PQ Distrib |
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 101 | 2525 | 8500 (17)| | | | | |
| 1 | PX COORDINATOR | | | | | | | | | |
| 2 | PX SEND QC (RANDOM) | :TQ10005 | 101 | 2525 | 8500 (17)| | | Q1,05 | P->S | QC (RAND) |
| 3 | VIEW | | 101 | 2525 | 8500 (17)| | | Q1,05 | PCWP | |
| 4 | SORT UNIQUE | | 101 | 18291 | 8500 (82)| | | Q1,05 | PCWP | |
| 5 | PX RECEIVE | | | | | | | Q1,05 | PCWP | |
| 6 | PX SEND HASH | :TQ10004 | | | | | | Q1,04 | P->P | HASH |
| 7 | BUFFER SORT | | 101 | 2525 | | | | Q1,04 | PCWP | |
| 8 | UNION-ALL | | | | | | | Q1,04 | PCWP | |
| 9 | BUFFER SORT | | | | | | | Q1,04 | PCWC | |
| 10 | PX RECEIVE | | | | | | | Q1,04 | PCWP | |
| 11 | PX SEND ROUND-ROBIN | :TQ10001 | | | | | | | S->P | RND-ROBIN |
| 12 | MERGE JOIN CARTESIAN | | 10M| 1737M| 1635 (5)| | | | | |
|* 13 | HASH JOIN | | 2439 | 419K| 322 (3)| | | | | |
|* 14 | TABLE ACCESS FULL | POS_DISTI_GROUP | 100 | 1800 | 5 (0)| | | | | |
|* 15 | HASH JOIN | | 2452 | 378K| 317 (3)| | | | | |
|* 16 | TABLE ACCESS FULL | S_CPT_SEQ_NO | 651 | 5208 | 5 (0)| | | | | |
| 17 | NESTED LOOPS | | 580 | 87000 | 311 (2)| | | | | |
| 18 | NESTED LOOPS | | 34 | 4658 | 131 (4)| | | | | |
|* 19 | HASH JOIN | | 1 | 97 | 109 (5)| | | | | |
|* 20 | HASH JOIN | | 9 | 774 | 107 (5)| | | | | |
|* 21 | HASH JOIN | | 2 | 146 | 101 (4)| | | | | |
|* 22 | TABLE ACCESS FULL | POS_CUST_XREF | 54 | 2268 | 25 (4)| | | | | |
|* 23 | TABLE ACCESS FULL | S_CPT_AUDIT | 68 | 2108 | 76 (4)| | | | | |
| 24 | TABLE ACCESS FULL | S_CPT_SEQ_NO | 1301 | 16913 | 5 (0)| | | | | |
|* 25 | TABLE ACCESS FULL | S_CPT_PRICE_CODE | 21 | 231 | 2 (0)| | | | | |
|* 26 | INDEX RANGE SCAN | UK_PP_STD_PRICE_STDP_ID | 26 | 1040 | 22 (0)| | | | | |
|* 27 | VIEW | RPT_PRODUCT_VALUE_LEVEL | 1 | 13 | 5 (0)| | | | | |
| 28 | UNION ALL PUSHED PREDICATE | | | | | | | | | |
| 29 | NESTED LOOPS OUTER | | 1 | 46 | 2 (0)| | | | | |
| 30 | NESTED LOOPS OUTER | | 1 | 42 | 2 (0)| | | | | |
| 31 | TABLE ACCESS BY INDEX ROWID | SMA_STMODEL | 1 | 28 | 2 (0)| | | | | |
|* 32 | INDEX UNIQUE SCAN | PK_SMA_STMODEL | 1 | | 1 (0)| | | | | |
|* 33 | INDEX UNIQUE SCAN | PK_SEAEGO_PRODUCT_HIERARCHY | 298 | 4172 | 0 (0)| | | | | |
|* 34 | INDEX UNIQUE SCAN | PK_S_CAP_GROUP | 2 | 8 | 0 (0)| | | | | |
| 35 | NESTED LOOPS OUTER | | 1 | 77 | 2 (0)| | | | | |
| 36 | NESTED LOOPS OUTER | | 1 | 73 | 2 (0)| | | | | |
| 37 | NESTED LOOPS | | 1 | 59 | 2 (0)| | | | | |
| 38 | NESTED LOOPS OUTER | | 1 | 31 | 2 (0)| | | | | |
| 39 | NESTED LOOPS OUTER | | 1 | 27 | 2 (0)| | | | | |
| 40 | TABLE ACCESS BY INDEX ROWID| SMA_PRODUCTMODEL | 1 | 23 | 2 (0)| | | | | |
|* 41 | INDEX UNIQUE SCAN | PK_SMA_PRODUCTMODEL | 1 | | 1 (0)| | | | | |
|* 42 | INDEX UNIQUE SCAN | PK_S_FAMILY | 1366 | 5464 | 0 (0)| | | | | |
|* 43 | INDEX UNIQUE SCAN | PK_F_MODPRODMGR | 22 | 88 | 0 (0)| | | | | |
| 44 | TABLE ACCESS BY INDEX ROWID | SMA_STMODEL | 13965 | 381K| 1 (0)| | | | | |
|* 45 | INDEX UNIQUE SCAN | PK_SMA_STMODEL | 1 | | 0 (0)| | | | | |
|* 46 | INDEX UNIQUE SCAN | PK_SEAEGO_PRODUCT_HIERARCHY | 298 | 4172 | 0 (0)| | | | | |
|* 47 | INDEX UNIQUE SCAN | PK_S_CAP_GROUP | 2 | 8 | 0 (0)| | | | | |
|* 48 | INDEX UNIQUE SCAN | IDX_RPT_PROD_MV_PROD_NO | 1 | 12 | 1 (0)| | | | | |
| 49 | BUFFER SORT | | 4128 | 20640 | 1629 (5)| | | | | |
|* 50 | INDEX RANGE SCAN | UK_PP_STD_PRICE_STDP_ID | 4128 | 20640 | 23 (0)| | | | | |
| 51 | HASH GROUP BY | | 1 | 191 | 5578 (2)| | | Q1,04 | PCWP | |
| 52 | PX RECEIVE | | 1 | 191 | 5578 (2)| | | Q1,04 | PCWP | |
| 53 | PX SEND HASH | :TQ10003 | 1 | 191 | 5578 (2)| | | Q1,03 | P->P | HASH |
| 54 | HASH GROUP BY | | 1 | 191 | 5578 (2)| | | Q1,03 | PCWP | |
|* 55 | FILTER | | | | | | | Q1,03 | PCWC | |
| 56 | NESTED LOOPS | | 1 | 191 | 5575 (2)| | | Q1,03 | PCWP | |
| 57 | NESTED LOOPS | | 7 | 1176 | 5562 (2)| | | Q1,03 | PCWP | |
|* 58 | HASH JOIN | | 74 | 8584 | 1347 (3)| | | Q1,03 | PCWP | |
| 59 | BUFFER SORT | | | | | | | Q1,03 | PCWC | |
| 60 | PX RECEIVE | | 60 | 3780 | 31 (7)| | | Q1,03 | PCWP | |
| 61 | PX SEND HASH | :TQ10000 | 60 | 3780 | 31 (7)| | | | S->P | HASH |
|* 62 | HASH JOIN | | 60 | 3780 | 31 (7)| | | | | |
|* 63 | TABLE ACCESS FULL | POS_CUST_XREF | 60 | 2100 | 25 (4)| | | | | |
|* 64 | TABLE ACCESS FULL | POS_DISTI_GROUP | 100 | 2800 | 5 (0)| | | | | |
| 65 | PX RECEIVE | | 345 | 18285 | 1316 (2)| | | Q1,03 | PCWP | |
| 66 | PX SEND HASH | :TQ10002 | 345 | 18285 | 1316 (2)| | | Q1,02 | P->P | HASH |
| 67 | PX BLOCK ITERATOR | | 345 | 18285 | 1316 (2)| | | Q1,02 | PCWC | |
|* 68 | TABLE ACCESS FULL | PP_DEBIT_AUTHORIZATION | 345 | 18285 | 1316 (2)| | | Q1,02 | PCWP | |
| 69 | PARTITION RANGE ALL | | 1 | 52 | 205 (1)| 1 | 33 | Q1,03 | PCWP | |
|* 70 | INDEX RANGE SCAN | POS_PP_INVENTORY_PK | 1 | 52 | 205 (1)| 1 | 33 | Q1,03 | PCWP | |
|* 71 | VIEW | RPT_PRODUCT_VALUE_LEVEL | 1 | 23 | 7 (0)| | | Q1,03 | PCWP | |
| 72 | UNION ALL PUSHED PREDICATE | | | | | | | Q1,03 | PCWP | |
|* 73 | FILTER | | | | | | | Q1,03 | PCWP | |
| 74 | NESTED LOOPS OUTER | | 1 | 46 | 2 (0)| | | Q1,03 | PCWP | |
| 75 | NESTED LOOPS OUTER | | 1 | 42 | 2 (0)| | | Q1,03 | PCWP | |
| 76 | TABLE ACCESS BY INDEX ROWID | SMA_STMODEL | 1 | 28 | 2 (0)| | | Q1,03 | PCWP | |
|* 77 | INDEX UNIQUE SCAN | PK_SMA_STMODEL | 1 | | 1 (0)| | | Q1,03 | PCWP | |
|* 78 | INDEX UNIQUE SCAN | PK_SEAEGO_PRODUCT_HIERARCHY | 298 | 4172 | 0 (0)| | | Q1,03 | PCWP | |
|* 79 | INDEX UNIQUE SCAN | PK_S_CAP_GROUP | 2 | 8 | 0 (0)| | | Q1,03 | PCWP | |
| 80 | NESTED LOOPS OUTER | | 1 | 77 | 3 (0)| | | Q1,03 | PCWP | |
| 81 | NESTED LOOPS OUTER | | 1 | 73 | 3 (0)| | | Q1,03 | PCWP | |
| 82 | NESTED LOOPS OUTER | | 1 | 69 | 3 (0)| | | Q1,03 | PCWP | |
| 83 | NESTED LOOPS OUTER | | 1 | 65 | 3 (0)| | | Q1,03 | PCWP | |
| 84 | NESTED LOOPS | | 1 | 51 | 3 (0)| | | Q1,03 | PCWP | |
|* 85 | TABLE ACCESS BY INDEX ROWID | SMA_PRODUCTMODEL | 1 | 23 | 2 (0)| | | Q1,03 | PCWP | |
|* 86 | INDEX UNIQUE SCAN | PK_SMA_PRODUCTMODEL | 1 | | 1 (0)| | | Q1,03 | PCWP | |
| 87 | TABLE ACCESS BY INDEX ROWID | SMA_STMODEL | 1 | 28 | 1 (0)| | | Q1,03 | PCWP | |
|* 88 | INDEX UNIQUE SCAN | PK_SMA_STMODEL | 1 | | 0 (0)| | | Q1,03 | PCWP | |
|* 89 | INDEX UNIQUE SCAN | PK_SEAEGO_PRODUCT_HIERARCHY | 298 | 4172 | 0 (0)| | | Q1,03 | PCWP | |
|* 90 | INDEX UNIQUE SCAN | PK_S_FAMILY | 1366 | 5464 | 0 (0)| | | Q1,03 | PCWP | |
|* 91 | INDEX UNIQUE SCAN | PK_S_CAP_GROUP | 2 | 8 | 0 (0)| | | Q1,03 | PCWP | |
|* 92 | INDEX UNIQUE SCAN | PK_F_MODPRODMGR | 22 | 88 | 0 (0)| | | Q1,03 | PCWP | |
|* 93 | MAT_VIEW ACCESS BY INDEX ROWID | RPT_PROD_MV | 1 | 24 | 2 (0)| | | Q1,03 | PCWP | |
|* 94 | INDEX UNIQUE SCAN | IDX_RPT_PROD_MV_PROD_NO | 1 | | 1 (0)| | | Q1,03 | PCWP | |
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
13 - access("G"."GROUP_DIST_NUMBER"="M"."DIST_NUMBER")
14 - filter("G"."END_DATE">TO_DATE(:B2,'DD-MON-YYYY'))
15 - access("C1"."CPT_PRICE_CODE"="S1"."CPT_PRICE_CODE")
16 - filter("S1"."PRICE_PROTECTABLE"='Y')
19 - access("C"."CPT_PRICE_CODE"="C1"."CPT_PRICE_CODE")
20 - access("A"."CUST_PRICE_TYPE"="C"."CPT_BILL_CODE")
21 - access("M"."SG_BILL_TO_CUST_NO"="A"."BILL_TO_CUST_NO")
22 - filter("M"."SG_BILL_TO_CUST_NO" IS NOT NULL AND ("M"."INDIRECT_DISTI"='Y' OR "M"."CATEGORY_TYPE" LIKE 'DIRECT%') AND "M"."ACTIVE_IND"<>'N' AND
TRUNC(INTERNAL_FUNCTION("M"."ARCHIVE_DATE"))>TRUNC(SYSDATE#!))
23 - filter("A"."START_DATE"<=TO_DATE(:B2,'DD-MON-YYYY') AND "A"."END_DATE">=TO_DATE(:B2,'DD-MON-YYYY'))
25 - filter("C1"."CPT_PRICE_CAT" LIKE 'NB%')
26 - access("P"."STDP_ID"=TO_NUMBER(:B1) AND "C"."CPT_PRICE_CODE"="P"."CUST_PRICE_TYPE")
filter("C"."CPT_PRICE_CODE"="P"."CUST_PRICE_TYPE")
27 - filter("L"."PROD_LEVEL"="P"."PROD_LEVEL")
32 - access("ST"."MOD_DESC"="P"."PROD_VALUE")
33 - access("ST"."MARKETING_NAME"="PH"."MARKETING_NAME"(+))
34 - access("ST"."MOD_CAPACITY_FORMATTED"="SCG"."MOD_CAPACITY_FORMATTED"(+))
41 - access("PM"."MODEL"="P"."PROD_VALUE")
42 - access("SF"."FAMILY"(+)=SUBSTRB("PM"."MODEL",1,3))
43 - access("PM"."DESIGN_APPLICATION"="DA"."DESIGN_APPLICATION"(+))
45 - access("PM"."MOD_DESC"="ST"."MOD_DESC")
46 - access("ST"."MARKETING_NAME"="PH"."MARKETING_NAME"(+))
47 - access("ST"."MOD_CAPACITY_FORMATTED"="SCG"."MOD_CAPACITY_FORMATTED"(+))
48 - access("PROD_NO"="P"."PROD_VALUE")
50 - access("P1"."STDP_ID"=TO_NUMBER(:B1))
55 - filter(TO_DATE(:B2,'DD-MON-YYYY')-6<=TO_DATE(:B2,'DD-MON-YYYY'))
58 - access("G"."DIST_NUMBER"="P"."DIST_NUMBER")
62 - access("G"."GROUP_DIST_NUMBER"="M"."DIST_NUMBER")
63 - filter(("M"."INDIRECT_DISTI"='Y' OR "M"."CATEGORY_TYPE" LIKE 'DIRECT%') AND "M"."ACTIVE_IND"<>'N' AND
TRUNC(INTERNAL_FUNCTION("M"."ARCHIVE_DATE"))>TRUNC(SYSDATE#!))
64 - filter("G"."END_DATE">TO_DATE(:B2,'DD-MON-YYYY'))
68 - filter("P"."PRICE_TYPE"='I' AND "P"."POS_PP_FLAG"='Y' AND ("P"."POS_PROCESSED_FLAG"<>'C' OR "P"."POS_PROCESSED_FLAG" IS NULL) AND
"P"."BEGIN_DATE"<=TO_DATE(:B2,'DD-MON-YYYY') AND "P"."BEGIN_DATE">=TO_DATE(:B2,'DD-MON-YYYY')-6)
70 - access("INVT"."DIST_NUMBER"="G"."GROUP_DIST_NUMBER" AND "INVT"."PPCF_SHOW_DATE"="P"."BEGIN_DATE")
filter("INVT"."PPCF_SHOW_DATE"<=TO_DATE(:B2,'DD-MON-YYYY') AND "INVT"."PPCF_SHOW_DATE">=TO_DATE(:B2,'DD-MON-YYYY')-6 AND
"INVT"."PPCF_SHOW_DATE"="P"."BEGIN_DATE")
71 - filter("L"."PROD_LEVEL"="P"."PROD_LEVEL")
73 - filter("P"."PROD_VALUE"="INVT"."STMODEL")
77 - access("ST"."MOD_DESC"="P"."PROD_VALUE")
78 - access("ST"."MARKETING_NAME"="PH"."MARKETING_NAME"(+))
79 - access("ST"."MOD_CAPACITY_FORMATTED"="SCG"."MOD_CAPACITY_FORMATTED"(+))
85 - filter("PM"."MOD_DESC"="INVT"."STMODEL")
86 - access("PM"."MODEL"="P"."PROD_VALUE")
88 - access("ST"."MOD_DESC"="INVT"."STMODEL")
89 - access("ST"."MARKETING_NAME"="PH"."MARKETING_NAME"(+))
90 - access("SF"."FAMILY"(+)=SUBSTRB("PM"."MODEL",1,3))
91 - access("ST"."MOD_CAPACITY_FORMATTED"="SCG"."MOD_CAPACITY_FORMATTED"(+))
92 - access("PM"."DESIGN_APPLICATION"="DA"."DESIGN_APPLICATION"(+))
93 - filter("MOD_DESC"="INVT"."STMODEL")
94 - access("PROD_NO"="P"."PROD_VALUE")
Note
-----
- 'PLAN_TABLE' is old version
PS:
Did you manage to get Run time? Also I change the query, please test this and let us know the result. Ideally the first query should be faster than yours and the second one (replaced the first) should be better than the first one.Remember to keep them separately with notes on performance.

just guess, but look like your statement not using index on archive_date column
try to use
AND M.ARCHIVE_DATE > TRUNC (SYSDATE) + 1 - 1/24/60/60
instead of
AND TRUNC (M.ARCHIVE_DATE) > TRUNC (SYSDATE)
also you should post all tables description into question
SELECT /*+ PARALLEL (P,4) PARALLEL (L,4)*/
DISTINCT
G.GROUP_DIST_NUMBER,
TO_DATE ( :B2,
'DD-MON-YYYY' )
BEGIN_DATE,
TO_DATE ( :B2,
'DD-MON-YYYY' )
PRICE_DROP_DATE
FROM
POS_DISTI_GROUP G,
POS_CUST_XREF M,
S_CPT_SEQ_NO C,
PP_STD_PRICE P,
S_CPT_AUDIT A,
RPT_PRODUCT_VALUE_LEVEL L
WHERE 1=0 -- switched off
G.END_DATE > TO_DATE ( :B2,
'DD-MON-YYYY' )
AND G.GROUP_DIST_NUMBER = M.DIST_NUMBER
AND M.SG_BILL_TO_CUST_NO = A.BILL_TO_CUST_NO
AND A.START_DATE <= TO_DATE ( :B2,
'DD-MON-YYYY' )
AND A.END_DATE >= TO_DATE ( :B2,
'DD-MON-YYYY' )
AND L.PROD_VALUE = P.PROD_VALUE
AND L.PROD_LEVEL = P.PROD_LEVEL
AND C.CPT_PRICE_CODE IN
(SELECT /*+ PARALLEL (P1,4)*/
DISTINCT C1.CPT_PRICE_CODE
FROM
PP_STD_PRICE P1,
S_CPT_PRICE_CODE C1,
S_CPT_SEQ_NO S1
WHERE
P1.STDP_ID = :B1
AND C1.CPT_PRICE_CAT LIKE 'NB%'
AND C1.CPT_PRICE_CODE = S1.CPT_PRICE_CODE
AND S1.PRICE_PROTECTABLE = 'Y')
AND C.CPT_PRICE_CODE = P.CUST_PRICE_TYPE
AND P.STDP_ID = :B1
AND A.CUST_PRICE_TYPE = C.CPT_BILL_CODE
AND M.ACTIVE_IND != 'N'
AND ( M.CATEGORY_TYPE LIKE 'DIRECT%'
OR M.INDIRECT_DISTI = 'Y' )
AND TRUNC ( M.ARCHIVE_DATE ) > TRUNC ( SYSDATE )
UNION
SELECT /*+ PARALLEL (P,4) PARALLEL (L,4) */
G.GROUP_DIST_NUMBER,
P.BEGIN_DATE,
MIN ( INVT.PRICE_DROP_DATE ) PRICE_DROP_DATE
FROM
POS_DISTI_GROUP G,
POS_CUST_XREF M,
PP_DEBIT_AUTHORIZATION P,
RPT_PRODUCT_VALUE_LEVEL L,
POS_PP_INVENTORY PARTITION ("F2011_Q2") INVT
WHERE 1=0 -- switched off
G.END_DATE > TO_DATE ( :B2,
'DD-MON-YYYY' )
AND G.GROUP_DIST_NUMBER = M.DIST_NUMBER
AND M.ACTIVE_IND != 'N'
AND ( M.CATEGORY_TYPE LIKE 'DIRECT%'
OR M.INDIRECT_DISTI = 'Y' )
AND G.DIST_NUMBER = P.DIST_NUMBER
AND L.PROD_VALUE = P.PROD_VALUE
AND L.PROD_LEVEL = P.PROD_LEVEL
AND P.BEGIN_DATE >= TO_DATE ( :B2,
'DD-MON-YYYY' )
- 6
AND P.BEGIN_DATE <= TO_DATE ( :B2,
'DD-MON-YYYY' )
AND INVT.DIST_NUMBER = G.GROUP_DIST_NUMBER
AND INVT.STMODEL = L.MOD_DESC
AND INVT.PPCF_SHOW_DATE = P.BEGIN_DATE
AND P.PRICE_TYPE = 'I'
AND ( P.POS_PROCESSED_FLAG IS NULL
OR P.POS_PROCESSED_FLAG != 'C' )
AND P.POS_PP_FLAG = 'Y'
AND TRUNC ( M.ARCHIVE_DATE ) > TRUNC ( SYSDATE )
GROUP BY
G.GROUP_DIST_NUMBER,
P.BEGIN_DATE
Result From OP:
After try to switch off and on here there result
1. Switch off 1st where condition
2.Switch off 2nd where condition
3.Switch off 3rd where condition , it started to long running, so i guess the select query at 2nd condition taken long time on execution

Connect By Level In Subquery Slow

I am using a connect_by_level subquery in an Oracle database to supply dates to join with another table. The connect by level appears to be causing the query to run very slowly. Here is my slow query:
select t.code, d.month_end, count(*)
from device t,
(select add_months(trunc(sysdate, 'MM'), - (level - 1)) - 1 MONTH_END
from dual
connect by level <= 1) d
where (d.month_end between t.date and t.exp_date)
group by t.code, d.month_end
The slow query above took about 2 hours to run the other day. The query below which should be equivalent runs in less than 30 seconds:
select t.code, trunc(sysdate, 'MM') - 1 month_end, count(*)
from device t
where ((trunc(sysdate, 'MM') - 1) between t.date and t.exp_date)
group by t.code
Ultimately, I want the 1st query to return data for the past 24 months, but I need to figure out why it is running so slowly with only 1 month as the criteria. Any suggestions on what is causing the slow completion time with the connect by level query?
Edit to add explain plan output for slow query:
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop | TQ |IN-OUT| PQ Distrib |
------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 520 | 65520 | 134K (1)| 00:00:03 | | | | | |
| 1 | PX COORDINATOR | | | | | | | | | | |
| 2 | PX SEND QC (RANDOM) | :TQ10006 | 520 | 65520 | 134K (1)| 00:00:03 | | | Q1,06 | P->S | QC (RAND) |
| 3 | HASH GROUP BY | | 520 | 65520 | 134K (1)| 00:00:03 | | | Q1,06 | PCWP | |
| 4 | PX RECEIVE | | 520 | 65520 | 134K (1)| 00:00:03 | | | Q1,06 | PCWP | |
| 5 | PX SEND HASH | :TQ10005 | 520 | 65520 | 134K (1)| 00:00:03 | | | Q1,05 | P->P | HASH |
| 6 | HASH GROUP BY | | 520 | 65520 | 134K (1)| 00:00:03 | | | Q1,05 | PCWP | |
|* 7 | HASH JOIN OUTER | | 520 | 65520 | 134K (1)| 00:00:03 | | | Q1,05 | PCWP | |
| 8 | PX RECEIVE | | 520 | 48880 | 134K (1)| 00:00:03 | | | Q1,05 | PCWP | |
| 9 | PX SEND HASH | :TQ10003 | 520 | 48880 | 134K (1)| 00:00:03 | | | Q1,03 | P->P | HASH |
|* 10 | HASH JOIN OUTER BUFFERED | | 520 | 48880 | 134K (1)| 00:00:03 | | | Q1,03 | PCWP | |
| 11 | PX RECEIVE | | | | | | | | Q1,03 | PCWP | |
| 12 | PX SEND HASH | :TQ10001 | | | | | | | Q1,01 | P->P | HASH |
| 13 | NESTED LOOPS | | | | | | | | Q1,01 | PCWP | |
| 14 | NESTED LOOPS | | 276 | 13800 | 50303 (0)| 00:00:01 | | | Q1,01 | PCWP | |
| 15 | BUFFER SORT | | | | | | | | Q1,01 | PCWC | |
| 16 | PX RECEIVE | | | | | | | | Q1,01 | PCWP | |
| 17 | PX SEND BROADCAST | :TQ10000 | | | | | | | | S->P | BROADCAST |
| 18 | VIEW | | 1 | 6 | 3 (0)| 00:00:01 | | | | | |
|* 19 | CONNECT BY WITHOUT FILTERING| | | | | | | | | | |
| 20 | FAST DUAL | | 1 | | 3 (0)| 00:00:01 | | | | | |
| 21 | PX PARTITION RANGE ALL | | 3898K| | 1656 (0)| 00:00:01 | 1 | 75 | Q1,01 | PCWC | |
|* 22 | INDEX RANGE SCAN | FTR_DT_IX1 | 3898K| | 1656 (0)| 00:00:01 | 1 | 75 | Q1,01 | PCWP | |
|* 23 | TABLE ACCESS BY LOCAL INDEX ROWID| FTR_DT | 276 | 12144 | 50300 (0)| 00:00:01 | 1 | 1 | Q1,01 | PCWP | |
| 24 | PX RECEIVE | | 7344K| 308M| 83875 (1)| 00:00:02 | | | Q1,03 | PCWP | |
| 25 | PX SEND HASH | :TQ10002 | 7344K| 308M| 83875 (1)| 00:00:02 | | | Q1,02 | P->P | HASH |
| 26 | PX BLOCK ITERATOR | | 7344K| 308M| 83875 (1)| 00:00:02 | | | Q1,02 | PCWC | |
|* 27 | TABLE ACCESS STORAGE FULL | DTL_HIST_DT | 7344K| 308M| 83875 (1)| 00:00:02 | | | Q1,02 | PCWP | |
| 28 | PX RECEIVE | | 108K| 3376K| 275 (0)| 00:00:01 | | | Q1,05 | PCWP | |
| 29 | PX SEND HASH | :TQ10004 | 108K| 3376K| 275 (0)| 00:00:01 | | | Q1,04 | P->P | HASH |
| 30 | PX BLOCK ITERATOR | | 108K| 3376K| 275 (0)| 00:00:01 | | | Q1,04 | PCWC | |
|* 31 | TABLE ACCESS STORAGE FULL | POINT_T | 108K| 3376K| 275 (0)| 00:00:01 | | | Q1,04 | PCWP | |
Predicate Information (identified by operation id):
---------------------------------------------------
7 - access("C"."CODE"="AP"."CODE"(+) AND "C"."POINT_ID"="AP"."POINT_ID"(+))
10 - access("CF"."P_ID"="C"."WTN"(+))
19 - filter(LEVEL<=1)
22 - access("CF"."DATE"<=INTERNAL_FUNCTION("D"."MONTH_END"))
23 - filter(UPPER("CF"."PLAN") LIKE '%DV%' AND ("CF"."FT_CODE"='7370' OR "CF"."FT_CODE"='7371' OR "CF"."FT_CODE"='7372' OR
"CF"."FT_CODE"='7373' OR "CF"."FT_CODE"='7374' OR "CF"."FT_CODE"='7380' OR "CF"."FT_CODE"='7380C' OR "CF"."FT_CODE"='7381' OR
"CF"."FT_CODE"='7381C' OR "CF"."FT_CODE"='7382' OR "CF"."FT_CODE"='7382C' OR "CF"."FT_CODE"='7383' OR "CF"."FT_CODE"='7384' OR
"CF"."FT_CODE"='7409' OR "CF"."FT_CODE"='7409C' OR "CF"."FT_CODE"='7410' OR "CF"."FT_CODE"='7410C' OR "CF"."FT_CODE"='TRKDV') AND
"CF"."EXP_DATE">=INTERNAL_FUNCTION("D"."MONTH_END"))
27 - storage("C"."EXP_DATE"(+)>=TRUNC(SYSDATE#!,'fmmm')-1 AND "C"."DATE"(+)<=TRUNC(SYSDATE#!,'fmmm')-1)
filter("C"."EXP_DATE"(+)>=TRUNC(SYSDATE#!,'fmmm')-1 AND "C"."DATE"(+)<=TRUNC(SYSDATE#!,'fmmm')-1)
31 - storage("AP"."EXP_DATE"(+)>=TRUNC(SYSDATE#!,'fmmm')-1 AND "AP"."DATE"(+)<=TRUNC(SYSDATE#!,'fmmm')-1)
filter("AP"."EXP_DATE"(+)>=TRUNC(SYSDATE#!,'fmmm')-1 AND "AP"."DATE"(+)<=TRUNC(SYSDATE#!,'fmmm')-1)
Note
-----
- dynamic sampling used for this statement (level=6)
- automatic DOP: Computed Degree of Parallelism is 8
Edit to add explain plan for faster query:
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop | TQ |IN-OUT| PQ Distrib |
---------------------------------------------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 278 | 33360 | 622K (1)| 00:00:11 | | | | | |
| 1 | PX COORDINATOR | | | | | | | | | | |
| 2 | PX SEND QC (RANDOM) | :TQ10005 | 278 | 33360 | 622K (1)| 00:00:11 | | | Q1,05 | P->S | QC (RAND) |
| 3 | HASH GROUP BY | | 278 | 33360 | 622K (1)| 00:00:11 | | | Q1,05 | PCWP | |
| 4 | PX RECEIVE | | 4034 | 472K| 622K (1)| 00:00:11 | | | Q1,05 | PCWP | |
| 5 | PX SEND HASH | :TQ10004 | 4034 | 472K| 622K (1)| 00:00:11 | | | Q1,04 | P->P | HASH |
|* 6 | HASH JOIN OUTER BUFFERED | | 4034 | 472K| 622K (1)| 00:00:11 | | | Q1,04 | PCWP | |
| 7 | PX RECEIVE | | 4034 | 346K| 621K (1)| 00:00:11 | | | Q1,04 | PCWP | |
| 8 | PX SEND HASH | :TQ10002 | 4034 | 346K| 621K (1)| 00:00:11 | | | Q1,02 | P->P | HASH |
|* 9 | HASH JOIN OUTER BUFFERED | | 4034 | 346K| 621K (1)| 00:00:11 | | | Q1,02 | PCWP | |
| 10 | PX RECEIVE | | 2140 | 94160 | 538K (1)| 00:00:09 | | | Q1,02 | PCWP | |
| 11 | PX SEND HASH | :TQ10000 | 2140 | 94160 | 538K (1)| 00:00:09 | | | Q1,00 | P->P | HASH |
| 12 | PX BLOCK ITERATOR | | 2140 | 94160 | 538K (1)| 00:00:09 | 1 | 75 | Q1,00 | PCWC | |
|* 13 | TABLE ACCESS STORAGE FULL| FTR_DT | 2140 | 94160 | 538K (1)| 00:00:09 | 1 | 75 | Q1,00 | PCWP | |
| 14 | PX RECEIVE | | 7344K| 308M| 83875 (1)| 00:00:02 | | | Q1,02 | PCWP | |
| 15 | PX SEND HASH | :TQ10001 | 7344K| 308M| 83875 (1)| 00:00:02 | | | Q1,01 | P->P | HASH |
| 16 | PX BLOCK ITERATOR | | 7344K| 308M| 83875 (1)| 00:00:02 | | | Q1,01 | PCWC | |
|* 17 | TABLE ACCESS STORAGE FULL| DTL_HIST_DT | 7344K| 308M| 83875 (1)| 00:00:02 | | | Q1,01 | PCWP | |
| 18 | PX RECEIVE | | 108K| 3376K| 275 (0)| 00:00:01 | | | Q1,04 | PCWP | |
| 19 | PX SEND HASH | :TQ10003 | 108K| 3376K| 275 (0)| 00:00:01 | | | Q1,03 | P->P | HASH |
| 20 | PX BLOCK ITERATOR | | 108K| 3376K| 275 (0)| 00:00:01 | | | Q1,03 | PCWC | |
|* 21 | TABLE ACCESS STORAGE FULL | POINT_T | 108K| 3376K| 275 (0)| 00:00:01 | | | Q1,03 | PCWP | |
Predicate Information (identified by operation id):
---------------------------------------------------
6 - access("C"."CODE"="AP"."CODE"(+) AND "C"."POINT_ID"="AP"."POINT_ID"(+))
9 - access("CF"."P_ID"="C"."WTN"(+))
13 - storage(UPPER("CF"."PLAN") LIKE '%DV%' AND ("CF"."FT_CODE"='7370' OR "CF"."FT_CODE"='7371' OR "CF"."FT_CODE"='7372' OR
"CF"."FT_CODE"='7373' OR "CF"."FT_CODE"='7374' OR "CF"."FT_CODE"='7380' OR "CF"."FT_CODE"='7380C' OR "CF"."FT_CODE"='7381' OR
"CF"."FT_CODE"='7381C' OR "CF"."FT_CODE"='7382' OR "CF"."FT_CODE"='7382C' OR "CF"."FT_CODE"='7383' OR "CF"."FT_CODE"='7384'
OR "CF"."FT_CODE"='7409' OR "CF"."FT_CODE"='7409C' OR "CF"."FT_CODE"='7410' OR "CF"."FT_CODE"='7410C' OR
"CF"."FT_CODE"='TRKDV') AND "CF"."EXP_DATE">=TRUNC(SYSDATE#!,'fmmm')-1 AND "CF"."DATE"<=TRUNC(SYSDATE#!,'fmmm')-1)
filter(UPPER("CF"."PLAN") LIKE '%DV%' AND ("CF"."FT_CODE"='7370' OR "CF"."FT_CODE"='7371' OR "CF"."FT_CODE"='7372' OR
"CF"."FT_CODE"='7373' OR "CF"."FT_CODE"='7374' OR "CF"."FT_CODE"='7380' OR "CF"."FT_CODE"='7380C' OR "CF"."FT_CODE"='7381' OR
"CF"."FT_CODE"='7381C' OR "CF"."FT_CODE"='7382' OR "CF"."FT_CODE"='7382C' OR "CF"."FT_CODE"='7383' OR "CF"."FT_CODE"='7384'
OR "CF"."FT_CODE"='7409' OR "CF"."FT_CODE"='7409C' OR "CF"."FT_CODE"='7410' OR "CF"."FT_CODE"='7410C' OR
"CF"."FT_CODE"='TRKDV') AND "CF"."EXP_DATE">=TRUNC(SYSDATE#!,'fmmm')-1 AND "CF"."DATE"<=TRUNC(SYSDATE#!,'fmmm')-1)
17 - storage("C"."EXP_DATE"(+)>=TRUNC(SYSDATE#!,'fmmm')-1 AND "C"."DATE"(+)<=TRUNC(SYSDATE#!,'fmmm')-1)
filter("C"."EXP_DATE"(+)>=TRUNC(SYSDATE#!,'fmmm')-1 AND "C"."DATE"(+)<=TRUNC(SYSDATE#!,'fmmm')-1)
21 - storage("AP"."EXP_DATE"(+)>=TRUNC(SYSDATE#!,'fmmm')-1 AND "AP"."DATE"(+)<=TRUNC(SYSDATE#!,'fmmm')-1)
filter("AP"."EXP_DATE"(+)>=TRUNC(SYSDATE#!,'fmmm')-1 AND "AP"."DATE"(+)<=TRUNC(SYSDATE#!,'fmmm')-1)
Note
-----
- dynamic sampling used for this statement (level=6)
- automatic DOP: Computed Degree of Parallelism is 8

In first query Oracle is doing an index range scan on a large table and retrieving huge amounts of data on the first pass with access("CF"."DATE"<=INTERNAL_FUNCTION("D"."MONTH_END")). You can work around it by rewriting your select to be more like your fast one. It would be something like this -
select t.code, trunc(t.exp_date, 'MM') - 1 month_end, count(*)
from device t
where t.date < :report_period_end
and t.exp_date > :report_period_start
group by t.code, trunc(t.exp_date,'MM') - 1;
Also note that there are several potential problems with your original slow query:
A row where t.date and t.exp_date is more than 2 months apart will be counted multiple times.
Rows where t.date and t.exp_date has the same month will not be counted at all
You are comparing your dates to e.g. 2013.10.30 00:00:00. Results may be incorrect if your dates contain time data.