Tuning SQL with heavy hash join
Hi all,
My database is 11.1. Rac 4 node.
The sql is so simple.
create table leon_12345
nologging
as
SELECT *
FROM OOOOOOOOOO a
FULL OUTER JOIN PPPPPPPPPPP b ON a.PRMTN_SKID =
b.PRMTN_SKID
AND a.PROD_SKID =
b.PROD_SKID
AND a.MTH_SKID =
b.MTH_SKID
AND a.PRMTD_CATEG_ID =
b.PRMTD_CATEG_ID
AND a.PRMTN_FACT_ID =
b.PRMTN_FACT_IDSince these two tables have DOP settings, the exection plan looks like:
| Id | Operation | Name | E-Rows | OMem | 1Mem | Used-Mem |
| 0 | CREATE TABLE STATEMENT | | | | | |
| 1 | LOAD AS SELECT | | | 256K| 256K| |
| 2 | PX COORDINATOR | | | | | |
| 3 | PX SEND QC (RANDOM) | :TQ10002 | 74M| | | |
| 4 | VIEW | VW_FOJ_0 | 74M| | | |
|* 5 | HASH JOIN FULL OUTER BUFFERED| | 74M| 1926M| 26M| |
| 6 | PX RECEIVE | | 12M| | | |
| 7 | PX SEND HASH | :TQ10000 | 12M| | | |
| 8 | PX BLOCK ITERATOR | | 12M| | | |
|* 9 | TABLE ACCESS FULL | PPPPPPPPPPP | 12M| | | |
| 10 | PX RECEIVE | | 74M| | | |
| 11 | PX SEND HASH | :TQ10001 | 74M| | | |
| 12 | PX BLOCK ITERATOR | | 74M| | | |
|* 13 | TABLE ACCESS FULL | OOOOOOOOOO | 74M| | | |
-----------------------------------------------------------------------------------------------------------I have noticed 8 slave sessions were up for this sql.(9 sessions totally of course)
With execution in parallel, the SQL still runs slowly. I want to know whether the parallel exectuion has some problem here.
Because after running several minutes, I saw four sessions became inactive and only 4 slave sessions were active.
Whether the workload was not distributed evenly or something else? Can I get some ideas on the direction of tuning this sql.
Best regards,
Leon
Leon,
There is not much to tune about this SQL. There might be something to tune in your database configuration, so I'd move this question over to the Database General forum.
And while doing that, please be sure to include trace information and wait event information.
Regards,
Rob.
Similar Messages
-
Seeking advice on a heavy hash join
We have to self-join a 190 million row table 160 times. On our production 9i database we give "RULE" hint and it finishes in about an hour using nested loop join, On our test 10g database, since "RULE" is not available any more. The optimiser chooses to use hash join (160 levels). And query never finishes in a reasonable time. We have gradually increase the hash_area_size from 8M to 512M, thinking that will help. But apparently it does not. Can anyone provide suggestions? Thanks.
There is an approach using Analytics Functions that may be useful here. The idea is to get all the data values required with 1 reference to Tab2 rather than 160, and let Analytics do the work of building the result set.
The goal here is to 'never do multiple references to the same table where 1 reference can suffice (usually with the aid of Analytics)'.
There are 2 variations depending on whether the ID values here (0,10,20,30,...) always follow an ascending pattern or if they don't. The second example is more generic and will also cover the ascending case.
name ID val ID val ID val ID val ID val
name1 0 1 10 1 20 1 30 1 40 1
-- Performance Summary - This demo used a max value of 1600 vs 15000
for a net number of rows of 2.5 million versus 225 million.
Any of the test views ( replacing 5,10, or 160 tab2 references) using the Analytics function used at most 4099 consistent gets. The original approach used 20553 consistent gets for 5 tab2 references, 41016 consistent gets for 10 tab2 references. This was in 10g, doing the hash join. I did try alter session set optimizer_mode = rule (just for test purposes) and that resulted in 46462 consistent gets for the 10 tab2 reference view while it did a merge join operation.
Autotrace for the Analytics version to replace the original 160 table sql.
JT(147)@JTDB10G>select * from analytics_2_joins;
1600 rows selected.
Statistics
0 recursive calls
0 db block gets
4099 consistent gets
3710 physical reads
0 redo size
1112904 bytes sent via SQL*Net to client
1250 bytes received via SQL*Net from client
81 SQL*Net roundtrips to/from client
2 sorts (memory)
0 sorts (disk)
1600 rows processed
-- Minimal examples:
--As always, test thoroughly before using in production.
select name,
id0, value value0,
id1, value value1,
id2, value value2,
id3, value value3,
id4, value value4
from ( select name, id, value,
lead(id,0 ) over(partition by name, value order by rn ) id0 ,
lead(id,1 ) over(partition by name, value order by rn ) id1 ,
lead(id,2 ) over(partition by name, value order by rn ) id2 ,
lead(id,3 ) over(partition by name, value order by rn ) id3 ,
lead(id,4 ) over(partition by name, value order by rn ) id4 ,
rn
from( select tab1.name, i0.id, i0.tab1value value,
(row_number() over (partition by tab1value order by i0.id )) -1 rn
from tab1, tab2 i0 where tab1.name='name1' and i0.tab1value=tab1.value
and i0.id in (0,10,20,30,40)
)) where rn = 0;
-- execute a verions of the smaller analytics approch with bind variables
-- referencing the binds within the numbered in-line view is needed only if
-- the id0, id1, id2 values do not follow the ascending pattern shown in the
-- example. This will handle case where id0 = 30, id2 =20, id4 = 40 , etc.
variable l_id0 number;
variable l_id1 number;
variable l_id2 number;
variable l_id3 number;
variable l_id4 number;
exec :l_id1 := 0;
exec :l_id3 := 10;
exec :l_id2 := 20;
exec :l_id0 := 30;
exec :l_id4 := 40;
select name, bind_rn,
id0, value value0,
id1, value value1,
id2, value value2,
id3, value value3,
id4, value value4
from ( select name, id, value,
lead(id,0 ) over(partition by name, value order by bind_rn ) id0 ,
lead(id,1 ) over(partition by name, value order by bind_rn ) id1 ,
lead(id,2 ) over(partition by name, value order by bind_rn ) id2 ,
lead(id,3 ) over(partition by name, value order by bind_rn ) id3 ,
lead(id,4 ) over(partition by name, value order by bind_rn ) id4 ,
bind_rn
from( select tab1.name, i0.id, i0.tab1value value, bind_rn
from tab1, tab2 i0,
(select 0 bind_rn, :l_id0 arg_value from dual union
select 1 , :l_id1 from dual union
select 2 , :l_id2 from dual union
select 3 , :l_id3 from dual union
select 4 , :l_id4 from dual ) table_of_args
where tab1.name='name1' and i0.tab1value=tab1.value
-- and i0.id in (0,10,20,30,40)
and i0.id = table_of_args.arg_value
)) where bind_rn = 0;
-- Full Test Case
-- table setup
drop table tab1;
drop table tab2;
create table tab1(name varchar2(100), value number) pctfree 0;
create table tab2(id number, tab1value number) pctfree 0;
begin
for x in 0 .. 1600 loop
for y in 1 .. 1600 loop
insert into tab1 values ('name' || x, y);
end loop;
end loop;
end;
-- 15000 results in 225,000,000
-- 1600 results in 2,560,000
begin
for x in 0 .. 1600 loop
for y in 1 .. 1600 loop
insert into tab2 values (x, y);
end loop;
end loop;
end;
commit;
CREATE BITMAP INDEX NAME_BITMAP ON TAB1(NAME);
EXEC DBMS_STATS.GATHER_TABLE_STATS(OWNNAME => 'JTOMMANEY',TABNAME => 'TAB1', -
estimate_percent => 20, CASCADE => TRUE);
EXEC DBMS_STATS.GATHER_TABLE_STATS(OWNNAME => 'JTOMMANEY',TABNAME => 'TAB2', -
estimate_percent => 20, CASCADE => TRUE);
alter session set optimizer_mode = 'RULE';
-- set up some views both the original approach, and the analytis approach
create view original_5_tab2_tables_join as
select tab1.name name,
i0.id id0, i0.tab1value value0,
i1.id id1, i1.tab1value value1,
i2.id id2, i2.tab1value value2,
i3.id id3, i3.tab1value value3,
i4.id id4, i4.tab1value value4
from tab1,
tab2 i0, tab2 i1, tab2 i2, tab2 i3, tab2 i4
where tab1.name='name1'
and (i0.id=0 and i0.tab1value=tab1.value)
and (i1.id=10 and i1.tab1value=tab1.value)
and (i2.id=20 and i2.tab1value=tab1.value)
and (i3.id=30 and i3.tab1value=tab1.value)
and (i4.id=40 and i4.tab1value=tab1.value);
create view replace_5_tab2_joins as
select name,
id0, value value0,
id1, value value1,
id2, value value2,
id3, value value3,
id4, value value4
from ( select name, id, value,
lead(id,0 ) over(partition by name, value order by rn ) id0 ,
lead(id,1 ) over(partition by name, value order by rn ) id1 ,
lead(id,2 ) over(partition by name, value order by rn ) id2 ,
lead(id,3 ) over(partition by name, value order by rn ) id3 ,
lead(id,4 ) over(partition by name, value order by rn ) id4 ,
rn from( select tab1.name, i0.id, i0.tab1value value,
(row_number() over (partition by tab1value order by i0.id )) -1 rn
from tab1, tab2 i0 where tab1.name='name1' and i0.tab1value=tab1.value
and i0.id in (0,10,20,30,40)
)) where rn = 0;
create view original_10_tab2_tables_join as
select tab1.name name,
i0.id id0, i0.tab1value value0,
i1.id id1, i1.tab1value value1,
i2.id id2, i2.tab1value value2,
i3.id id3, i3.tab1value value3,
i4.id id4, i4.tab1value value4,
i5.id id5, i5.tab1value value5,
i6.id id6, i6.tab1value value6,
i7.id id7, i7.tab1value value7,
i8.id id8, i8.tab1value value8,
i9.id id9, i9.tab1value value9
from tab1,
tab2 i0, tab2 i1, tab2 i2, tab2 i3, tab2 i4,
tab2 i5, tab2 i6, tab2 i7, tab2 i8, tab2 i9
where tab1.name='name1'
and (i0.id=0 and i0.tab1value=tab1.value)
and (i1.id=10 and i1.tab1value=tab1.value)
and (i2.id=20 and i2.tab1value=tab1.value)
and (i3.id=30 and i3.tab1value=tab1.value)
and (i4.id=40 and i4.tab1value=tab1.value)
and (i5.id=50 and i5.tab1value=tab1.value)
and (i6.id=60 and i6.tab1value=tab1.value)
and (i7.id=70 and i7.tab1value=tab1.value)
and (i8.id=80 and i8.tab1value=tab1.value)
and (i9.id=90 and i9.tab1value=tab1.value);
create view replace_10_tab2_joins as
select name,
id0, value value0,
id1, value value1,
id2, value value2,
id3, value value3,
id4, value value4,
id5, value value5,
id6, value value6,
id7, value value7,
id8, value value8,
id9, value value9
from ( select name, id, value,
lead(id,0 ) over(partition by name, value order by rn ) id0 ,
lead(id,1 ) over(partition by name, value order by rn ) id1 ,
lead(id,2 ) over(partition by name, value order by rn ) id2 ,
lead(id,3 ) over(partition by name, value order by rn ) id3 ,
lead(id,4 ) over(partition by name, value order by rn ) id4 ,
lead(id,5 ) over(partition by name, value order by rn ) id5 ,
lead(id,6 ) over(partition by name, value order by rn ) id6 ,
lead(id,7 ) over(partition by name, value order by rn ) id7 ,
lead(id,8 ) over(partition by name, value order by rn ) id8 ,
lead(id,9 ) over(partition by name, value order by rn ) id9 ,
rn from( select tab1.name, i0.id, i0.tab1value value,
(row_number() over (partition by tab1value order by i0.id )) -1 rn
from tab1, tab2 i0 where tab1.name='name1' and i0.tab1value=tab1.value
and i0.id in (0,10,20,30,40,50,60,70,80,90)
)) where rn = 0;
-- set up some views both the original approach, and the analytics approach
spool cr_v1.sql may need to clean up heading, linefeed from created file
begin
dbms_output.put_line('create or replace view original_160_joins as select /*+ rule */ tab1.name ');
for x in 0 .. 160 loop
dbms_output.put_line( ',i' || x || '.id id' || x || ' ,i' || x || '.tab1value value' || x ) ;
end loop;
dbms_output.put_line('from tab1' );
for x in 0 .. 160 loop
dbms_output.put_line( ',tab2 i' || x ) ;
end loop;
dbms_output.put_line(' where tab1.name = ''name1''' );
for x in 0 .. 160 loop
dbms_output.put_line( ' and i' || x || '.id=' || (x * 10) || ' and i' || x || '.tab1value=tab1.value ' ) ;
end loop;
dbms_output.put_line( ' ;');
end;
--spool off
--@cr_v1.sql
spool cr_v2.sql may need to clean up heading, linefeed from created file
begin
dbms_output.put_line('create or replace view analytics_2_joins as select name ');
for x in 0 .. 160 loop
dbms_output.put_line( ',id' || x || ', value value' || x ) ;
end loop;
dbms_output.put_line('from ( select name, id, value ' );
for x in 0 .. 160 loop
dbms_output.put_line( ',lead(id,' || x || ') over(partition by name, value order by rn ) id' || x ) ;
end loop;
dbms_output.put_line(' , rn from( select tab1.name, i0.id, i0.tab1value value, ');
dbms_output.put_line(' (row_number() over (partition by tab1value order by i0.id )) -1 rn ');
dbms_output.put_line(' from tab1, tab2 i0 where tab1.name=''name1'' and i0.tab1value=tab1.value and i0.id in ( ');
for x in 0 .. 159 loop
dbms_output.put_line( (x * 10) || ',' ) ;
end loop;
dbms_output.put_line( ' 1600))) where rn = 0;');
end;
--spool off
--@cr_v2.sql
-- We now have 6 views established
-- Original Approach Analytics Approach w/ 1 tab2 reference
-- 5 tab2s original_5_tab2_tables_join replace_5_tab2_joins
-- 10 tab2s original_10_tab2_tables_join replace_10_tab2_joins
--160 tab2s original_160_joins analytics_2_joins
-- plus we will use call the version with bind variables, but not from a view.
-- Data validation:
select 'orig_minus_new: ' || count(*) from
( select * from original_5_tab2_tables_join minus select * from replace_5_tab2_joins ) union
select 'new_minus_orig: ' || count(*) from
( select * from replace_5_tab2_joins minus select * from original_5_tab2_tables_join );
select 'orig_minus_new: ' || count(*) from
( select * from original_10_tab2_tables_join minus select * from replace_10_tab2_joins ) union
select 'new_minus_orig: ' || count(*) from
( select * from replace_10_tab2_joins minus select * from original_10_tab2_tables_join );
select 'orig_minus_new: ' || count(*) from
( select * from original_160_joins minus select * from analytics_2_joins );
select 'new_minus_orig: ' || count(*) from
( select * from analytics_2_joins minus select * from original_160_joins );
-- Performance test
alter session set workarea_size_policy=manual ;
alter session set sort_area_size = 64000000;
alter session set hash_area_size = 64000000;
set autotrace traceonly stat
select * from original_5_tab2_tables_join;
select * from replace_5_tab2_joins;
select * from original_10_tab2_tables_join;
select * from replace_10_tab2_joins;
select * from analytics_2_joins;
--select * from original_160_joins;
-- execute a verions of the smaller analytics approch with bind variables
-- referencing the binds within the numbered in-line view is needed only if
-- the id0, id1, id2 values do not follow the ascending pattern shown in the
-- example. This will handle case where id0 = 30, id2 =20, id4 = 40 , etc.
variable l_id0 number;
variable l_id1 number;
variable l_id2 number;
variable l_id3 number;
variable l_id4 number;
exec :l_id1 := 0;
exec :l_id3 := 10;
exec :l_id2 := 20;
exec :l_id0 := 30;
exec :l_id4 := 40;
select name, bind_rn,
id0, value value0,
id1, value value1,
id2, value value2,
id3, value value3,
id4, value value4
from ( select name, id, value,
lead(id,0 ) over(partition by name, value order by bind_rn ) id0 ,
lead(id,1 ) over(partition by name, value order by bind_rn ) id1 ,
lead(id,2 ) over(partition by name, value order by bind_rn ) id2 ,
lead(id,3 ) over(partition by name, value order by bind_rn ) id3 ,
lead(id,4 ) over(partition by name, value order by bind_rn ) id4 ,
bind_rn
from( select tab1.name, i0.id, i0.tab1value value, bind_rn
from tab1, tab2 i0,
(select 0 bind_rn, :l_id0 arg_value from dual union
select 1 , :l_id1 from dual union
select 2 , :l_id2 from dual union
select 3 , :l_id3 from dual union
select 4 , :l_id4 from dual ) table_of_args
where tab1.name='name1' and i0.tab1value=tab1.value
-- and i0.id in (0,10,20,30,40)
and i0.id = table_of_args.arg_value
)) where bind_rn = 0;
JT(147)@JTDB10G>select * from original_5_tab2_tables_join;
1600 rows selected.
Statistics
8 recursive calls
2 db block gets
20553 consistent gets
18555 physical reads
0 redo size
52052 bytes sent via SQL*Net to client
1250 bytes received via SQL*Net from client
81 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1600 rows processed
JT(147)@JTDB10G>select * from replace_5_tab2_joins;
1600 rows selected.
Statistics
8 recursive calls
2 db block gets
4101 consistent gets
3710 physical reads
0 redo size
52052 bytes sent via SQL*Net to client
1250 bytes received via SQL*Net from client
81 SQL*Net roundtrips to/from client
2 sorts (memory)
0 sorts (disk)
1600 rows processed
JT(147)@JTDB10G>select * from original_10_tab2_tables_join;
1600 rows selected.
Statistics
0 recursive calls
0 db block gets
41016 consistent gets
37115 physical reads
0 redo size
85636 bytes sent via SQL*Net to client
1250 bytes received via SQL*Net from client
81 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1600 rows processed
JT(147)@JTDB10G>select * from replace_10_tab2_joins;
1600 rows selected.
Statistics
0 recursive calls
0 db block gets
4099 consistent gets
3710 physical reads
0 redo size
85636 bytes sent via SQL*Net to client
1250 bytes received via SQL*Net from client
81 SQL*Net roundtrips to/from client
2 sorts (memory)
0 sorts (disk)
1600 rows processed
JT(147)@JTDB10G>select * from analytics_2_joins;
1600 rows selected.
Statistics
0 recursive calls
0 db block gets
4099 consistent gets
3710 physical reads
0 redo size
1112904 bytes sent via SQL*Net to client
1250 bytes received via SQL*Net from client
81 SQL*Net roundtrips to/from client
2 sorts (memory)
0 sorts (disk)
1600 rows processed
JT(147)@JTDB10G>--select * from original_160_joins;
JT(147)@JTDB10G>
JT(147)@JTDB10G>----------------------------------------------------------------------------------------
JT(147)@JTDB10G>-- execute a verions of the smaller analytics approch with bind variables
JT(147)@JTDB10G>-- referencing the binds within the numbered in-line view is needed only if
JT(147)@JTDB10G>-- the id0, id1, id2 values do not follow the ascending pattern shown in the
JT(147)@JTDB10G>-- example. This will handle case where id0 = 30, id2 =20, id4 = 40 , etc.
JT(147)@JTDB10G>----------------------------------------------------------------------------------------
JT(147)@JTDB10G>
JT(147)@JTDB10G>variable l_id0 number;
JT(147)@JTDB10G>variable l_id1 number;
JT(147)@JTDB10G>variable l_id2 number;
JT(147)@JTDB10G>variable l_id3 number;
JT(147)@JTDB10G>variable l_id4 number;
JT(147)@JTDB10G>
JT(147)@JTDB10G>exec :l_id1 := 0;
PL/SQL procedure successfully completed.
JT(147)@JTDB10G>exec :l_id3 := 10;
PL/SQL procedure successfully completed.
JT(147)@JTDB10G>exec :l_id2 := 20;
PL/SQL procedure successfully completed.
JT(147)@JTDB10G>exec :l_id0 := 30;
PL/SQL procedure successfully completed.
JT(147)@JTDB10G>exec :l_id4 := 40;
PL/SQL procedure successfully completed.
JT(147)@JTDB10G>
JT(147)@JTDB10G>select name, bind_rn,
2 id0, value value0,
3 id1, value value1,
4 id2, value value2,
5 id3, value value3,
6 id4, value value4
7 from ( select name, id, value,
8 lead(id,0 ) over(partition by name, value order by bind_rn ) id0 ,
9 lead(id,1 ) over(partition by name, value order by bind_rn ) id1 ,
10 lead(id,2 ) over(partition by name, value order by bind_rn ) id2 ,
11 lead(id,3 ) over(partition by name, value order by bind_rn ) id3 ,
12 lead(id,4 ) over(partition by name, value order by bind_rn ) id4 ,
13 bind_rn
14 from( select tab1.name, i0.id, i0.tab1value value, bind_rn
15 from tab1, tab2 i0,
16 (select 0 bind_rn, :l_id0 arg_value from dual union
17 select 1 , :l_id1 from dual union
18 select 2 , :l_id2 from dual union
19 select 3 , :l_id3 from dual union
20 select 4 , :l_id4 from dual ) table_of_args
21 where tab1.name='name1' and i0.tab1value=tab1.value
22 -- and i0.id in (0,10,20,30,40)
23 and i0.id = table_of_args.arg_value
24 )) where bind_rn = 0;
1600 rows selected.
Statistics
1 recursive calls
0 db block gets
4099 consistent gets
3707 physical reads
0 redo size
52111 bytes sent via SQL*Net to client
1250 bytes received via SQL*Net from client
81 SQL*Net roundtrips to/from client
2 sorts (memory)
0 sorts (disk)
1600 rows processed -
Tuning sql with analytic function
Dear friends I've developed one sql :
with REP as
(select /*+ MATERIALIZE */ branch_code,
row_number() over(partition by branch_code, account order by bkg_date desc ) R,
account,
bkg_date,
lcy_closing_bal
from history t
select REP1.branch_code,
REP1.account,
REP1.bkg_date,
REP1.lcy_closing_bal,
NULL AS second,
REP2.bkg_date bkg_date2,
REP2.lcy_closing_bal lcy_closing_bal2,
NULL AS third,
REP3.bkg_date bkg_date3,
REP3.lcy_closing_bal lcy_closing_bal3
from (SELECT * FROM REP WHERE R=1) REP1, (SELECT * FROM REP WHERE R=2) REP2, (SELECT * FROM REP WHERE R=3) REP3
where
(REP1.BRANCH_CODE = REP2.BRANCH_CODE(+) AND REP1.ACCOUNT = REP2.ACCOUNT(+)) AND
(REP1.BRANCH_CODE = REP3.BRANCH_CODE(+) AND REP1.ACCOUNT = REP3.ACCOUNT(+))The point is I want to restrict (tune) REP before it used ,because , as you can see I need maximum three value from REP (where R=1,R=2,R=3) . Which analytic function and with wich options I have to use to receive only 3 values in each branch_code,account groups at the materializing time ?Radrigez wrote:
Dear friends I've developed one sql :
with REP as
from (SELECT * FROM REP WHERE R=1) REP1,
(SELECT * FROM REP WHERE R=2) REP2,
(SELECT * FROM REP WHERE R=3) REP3
where
(REP1.BRANCH_CODE = REP2.BRANCH_CODE(+) AND REP1.ACCOUNT = REP2.ACCOUNT(+)) AND
(REP1.BRANCH_CODE = REP3.BRANCH_CODE(+) AND REP1.ACCOUNT = REP3.ACCOUNT(+))
The first step is to put your subquery (which doesn't need to be materialized) into an inline view and restrict the result set on r in (1,2,3) as suggested by thtsang - you don't need to query the same result set three times.
Then you're looking at a simple pivot operation (assuming the number of rows you want per branch and account is fixed). If you're on 11g search the manuals for PIVOT, on earlier versions you can do this with a decode() or case() operator.
Step 1 (which could go into another factored subquery) would be something like:
select
branch_code, account,
case r = 1 then bkg_date end bkg_date,
case r = 1 then lcy_closing_bal end lcy_closing_bal,
case r = 2 then bkg_date end bkg_date2,
case r = 2 then lcy_closing_bal end lcy_closing_bal2,
case r = 3 then bkg_date end bkg_date3,
case r = 3 then lcy_closing_bal end lcy_closing_bal3
from
repThis gives you the eight necessary columns, but still (up to) three rows per branch/account.
Then you aggregate this (call it rep1) on branch and account.
select
branch_code, account,
max(bkg_date),
max(lcy_closing_bal),
max(bkg_date2),
max(lcy_closing_bal2),
max(bkg_date3),
max(lcy_closing_bal3)
from
rep1
group by
branch_code, account
order by
branch_code, accountRegards
Jonathan Lewis
http://jonathanlewis.wordpress.com
Author: <b><em>Oracle Core</em></b> -
SQL was generated by Peoplesoft application:
SELECT DISTINCT COMPANY, PAYGROUP, PAY_END_DT, TO_CHAR(PAY_END_DT, 'YYYY-MM-DD'),
OFF_CYCLE, PAGE_NUM, LINE_NUM, SEPCHK, FORM_ID, PAYCHECK_NBR, EMPLID,
NAME FROM PS_ZZ_PAY_CHK_VW
WHERE COMPANY LIKE 'DCG%'
AND PAYGROUP LIKE 'G9E%'
AND PAY_END_DT=TO_DATE(:1, 'YYYY-MM-DD')
AND OFF_CYCLE=:2 AND PAGE_NUM=:3
AND LINE_NUM=:4 AND SEPCHK=:5
AND ROWSECCLASS=:6
ORDER BY COMPANY, PAYGROUP, PAY_END_DT, OFF_CYCLE, PAGE_NUM, LINE_NUM, SEPCHK;
Bind variables are :1, :2, etc.
Tried to assign some values to :1 and got the follwowing error:
SQL> variable 1 varchar2(20)
exec :1 := '2007-05-01'
'SP2-0553: Illegal variable name "1".
My question is: why the bind variables don't have a name? How to tune it if I can not touch the original code? Thanks.
MichaelI think it should work. But again, I can not test it because I can not get the sql to run.
I thought changing the bind variable name may work for a moment but it turned out it doesn't work. Here is the test I did:
create outline for the bad sql:
INSERT INTO PS_WRK_GRP3_TAO4 (PROCESS_INSTANCE,OPRID , RUN_CNTL_ID , GROUP_ID ,EMPLID , EMPL_RCD , TEMP_FLD)
SELECT 232596 ,'jennifer.landis' ,'jen' , 'DCALL',JOB.EMPLID ,JOB.EMPL_RCD , 'A'
FROM PS_JOB JOB, PS_PERSONAL_DT_FST PERSONAL_DT_FST, PS_EMPLOYMENT EMPLOYMENT, PS_TL_EMPL_DATA TL_EMPL_DATA
WHERE JOB.EMPLID =PERSONAL_DT_FST.EMPLID
AND JOB.EMPLID = EMPLOYMENT.EMPLID
AND JOB.EMPL_RCD = EMPLOYMENT.EMPL_RCD
AND JOB.EFFDT= ( SELECT MAX(JOB1.EFFDT)
FROM PS_JOB JOB1
WHERE JOB1.EMPLID=JOB.EMPLID
AND JOB1.EMPL_RCD=JOB.EMPL_RCD
AND JOB1.EFFDT <= TO_DATE(:x1,'YYYY-MM-DD'))
AND JOB.EFFSEQ= ( SELECT MAX(JOB2.EFFSEQ)
FROM PS_JOB JOB2
WHERE JOB2.EMPLID=JOB.EMPLID
AND JOB2.EMPL_RCD=JOB.EMPL_RCD
AND JOB2.EFFDT=JOB.EFFDT)
AND JOB.EMPLID = TL_EMPL_DATA.EMPLID
AND JOB.EMPL_RCD = TL_EMPL_DATA.EMPL_RCD
AND TL_EMPL_DATA.EFFDT = ( SELECT MAX(TL_EMPL_DATA1.EFFDT)
FROM PS_TL_EMPL_DATA TL_EMPL_DATA1
WHERE TL_EMPL_DATA1.EMPLID = TL_EMPL_DATA.EMPLID
AND TL_EMPL_DATA1.EMPL_RCD = TL_EMPL_DATA.EMPL_RCD
AND TL_EMPL_DATA1.EFFDT <= TO_DATE(:x2,'YYYY-MM-DD'))
AND ( TL_EMPL_DATA.TIME_RPTG_STATUS <> 'I');
create outline for tuned sql with hint and changed variable:
INSERT INTO PS_WRK_GRP3_TAO4 (PROCESS_INSTANCE,OPRID , RUN_CNTL_ID , GROUP_ID ,EMPLID , EMPL_RCD , TEMP_FLD)
SELECT /*+ rule */ 232596 ,'jennifer.landis' ,'jen' , 'DCALL',JOB.EMPLID ,JOB.EMPL_RCD , 'A'
FROM PS_JOB JOB, PS_PERSONAL_DT_FST PERSONAL_DT_FST, PS_EMPLOYMENT EMPLOYMENT, PS_TL_EMPL_DATA TL_EMPL_DATA
WHERE JOB.EMPLID =PERSONAL_DT_FST.EMPLID
AND JOB.EMPLID = EMPLOYMENT.EMPLID
AND JOB.EMPL_RCD = EMPLOYMENT.EMPL_RCD
AND JOB.EFFDT= ( SELECT MAX(JOB1.EFFDT)
FROM PS_JOB JOB1
WHERE JOB1.EMPLID=JOB.EMPLID
AND JOB1.EMPL_RCD=JOB.EMPL_RCD
AND JOB1.EFFDT <= TO_DATE(:y1,'YYYY-MM-DD'))
AND JOB.EFFSEQ= ( SELECT MAX(JOB2.EFFSEQ)
FROM PS_JOB JOB2
WHERE JOB2.EMPLID=JOB.EMPLID
AND JOB2.EMPL_RCD=JOB.EMPL_RCD
AND JOB2.EFFDT=JOB.EFFDT)
AND JOB.EMPLID = TL_EMPL_DATA.EMPLID
AND JOB.EMPL_RCD = TL_EMPL_DATA.EMPL_RCD
AND TL_EMPL_DATA.EFFDT = ( SELECT MAX(TL_EMPL_DATA1.EFFDT)
FROM PS_TL_EMPL_DATA TL_EMPL_DATA1
WHERE TL_EMPL_DATA1.EMPLID = TL_EMPL_DATA.EMPLID
AND TL_EMPL_DATA1.EMPL_RCD = TL_EMPL_DATA.EMPL_RCD
AND TL_EMPL_DATA1.EFFDT <= TO_DATE(:y2,'YYYY-MM-DD'))
AND ( TL_EMPL_DATA.TIME_RPTG_STATUS <> 'I');
swap outlines
run the bad sql but it doesn't work.
SQL> select name, category, used from dba_outlines;
NAME CATEGORY USED
TIME_ADM SYSADM UNUSED
TIME_ADM1 SYSADM UNUSED -
Performance Tuning - remove hash join
Hi Every one,
Can some one help in tuning below query, i have hash join taking around 84%,
SELECT
PlanId
,ReplacementPlanId
FROM
( SELECT
pl.PlanId
,xpl.PlanId ReplacementPlanId
,ROW_NUMBER() OVER(PARTITION BY pl.PlanId ORDER BY xpl.PlanId) RN
FROM [dbo].[Plan] pl
JOIN [dbo].[Plan] xpl
ON pl.PPlanId = xpl.PPlanId
AND pl.Name = xpl.Name
WHERE
pl.SDate > (CONVERT(CHAR(10),DATEADD(M,-12,GETDATE()),120)) AND
xpl.Live = 1
AND pl.TypeId = 7
AND xpl.TypeId = 7
) p
WHERE RN = 1
Thanks in advanceCan you show an execution plan of the query? Is that possible to rewrite the query as
Sorry cannot test it right now
SELECT
PlanId
,ReplacementPlanId
FROM
(SELECT PlanId,Name,SDate,TypeId FROM [dbo].[Plan]) pl
CROSS APPLY
SELECT TOP (1) TypeId ,Live FROM [Plan] xpl
WHERE pl.PPlanId = xpl.PPlanId
AND pl.Name = xpl.Name
) AS Der
WHERE pl.SDate > (CONVERT(CHAR(10),DATEADD(M,-12,GETDATE()),120)) AND
Der.Live = 1
AND pl.TypeId = 7
AND Der.TypeId = 7
Best Regards,Uri Dimant SQL Server MVP,
http://sqlblog.com/blogs/uri_dimant/
MS SQL optimization: MS SQL Development and Optimization
MS SQL Consulting:
Large scale of database and data cleansing
Remote DBA Services:
Improves MS SQL Database Performance
SQL Server Integration Services:
Business Intelligence -
Simultaneous hash joins of the same large table with many small ones?
Hello
I've got a typical data warehousing scenario where a HUGE_FACT table is to be joined with numerous very small lookup/dimension tables for data enrichment. Joins with these small lookup tables are mutually independent, which means that the result of any of these joins is not needed to perform another join.
So this is a typical scenario for a hash join: the lookup table is converted into a hashed map in RAM memory, fits there without drama cause it's small and a single pass over the HUGE_FACT suffices to get the results.
Problem is, so far as I can see it in the query plan, these hash joins are not executed simultaneously but one after another, which renders Oracle to do the full scan of the HUGE_FACT (or any intermediary enriched form of it) as many times as there are joins.
Questions:
- is my interpretation correct that the mentioned joins are sequential, not simultaneous?
- if this is the case, is there any possibility to force Oracle to perform these joins simultaneously (building more than one hashed map in memory and doing the single pass over the HUGE_FACT while looking up in all of these hashed maps for matches)? If so, how to do it?
Please note that the parallel execution of a single join at a time is not the matter of the question.
Database version is 10.2.
Thank you very much in advance for any response.user13176880 wrote:
Questions:
- is my interpretation correct that the mentioned joins are sequential, not simultaneous?Correct. But why do you think this is an issue? Because of this:
which renders Oracle to do the full scan of the HUGE_FACT (or any intermediary enriched form of it) as many times as there are joins.That is (should not be) true. Oracle does one pass of the big table, and then sequentually joins to each of the hashmaps (of each of the smaller tables).
If you show us the execution plan, we can be sure of this.
- if this is the case, is there any possibility to force Oracle to perform these joins simultaneously (building more than one hashed map in memory and doing the single pass over the HUGE_FACT while looking up in all of these hashed maps for matches)? If so, how to do it?Yes there is. But again you should not need to resort to such a solution. What you can do is use subquery factoring (WITH clause) in conjunction with the MATERIALIZE hint to first construct the cartesian join of all of the smaller (dimension) tables. And then join the big table to that. -
SQL with connect by prior running for a long time
Hi,
We are using Oracle 10g. Below is a cursor sql which is having performance issues. The pAccountid is being passed from the output of a different cursor. But this cursor sql is running for a long time. Could you please help me in tuning this sql. I believe the subquery with connect by prior is causing the trouble.
The TRXNS is a huge table which is not partitioned. The query is forced to use the index on the accountid of the TRXNS table.
The accountlink table has 20,000 records and the TRXNStrack table has 10,000 records in total.
This sql executes for 200,000 pAccountids and runs for more than 8 hours.
SELECT /*+ INDEX(T TRXNS_ACCOUNTID_NIDX) */ AL.FROMACCOUNTID oldaccountid ,
A.ACCOUNTNUM oldaccountnum,
T.TRXNSID,
T.TRXNSTYPEID,
T.DESCRIPTION ,
T.postdt,
T.TRXNSAMT
FROM
ACCOUNTLINK AL,
TRXNS T,
ACCOUNT A
WHERE AL.TOACCOUNTID IN
(SELECT TOACCOUNTID FROM ACCOUNTLINK START WITH TOACCOUNTID = pAccountid
CONNECT BY PRIOR FROMACCOUNTID = TOACCOUNTID)
AND AL.FROMACCOUNTID = T.ACCOUNTID
AND A.ACCOUNTID = AL.FROMACCOUNTID
AND NOT EXISTS (select 1 from TRXNStrack trck where trck.TRXNSid = t.TRXNSid AND TRXNSTrackReasonid = 1)
AND T.postdt > A.CLOSEDATE
AND T.postdt >= sysdate-2
AND T.postdt <= sysdate;
Create script for trxn table:
CREATE TABLE SP.TRXNS
TRXNSID NUMBER(15) CONSTRAINT "BIN$rpIQEeyLDfbgRAAUT4DEnQ==$0" NOT NULL,
ACCOUNTID NUMBER(15) CONSTRAINT "BIN$rpIQEeyMDfbgRAAUT4DEnQ==$0" NOT NULL,
STATEMENTID NUMBER(15),
TRXNSTYPEID NUMBER(15),
DESCRIPTION VARCHAR2(80 BYTE),
postdt DATE,
TRXNSAMT NUMBER(12,2),
TRXNSREQID NUMBER(15),
LASTUPDATE DATE,
SOURCEID NUMBER(15),
HIDE VARCHAR2(1 BYTE)
TABLESPACE SO_TRXN_DATA
RESULT_CACHE (MODE DEFAULT)
PCTUSED 40
PCTFREE 10
INITRXNS 2
MAXTRXNS 255
STORAGE (
INITIAL 50M
NEXT 1M
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
FREELISTS 8
FREELIST GROUPS 1
BUFFER_POOL DEFAULT
FLASH_CACHE DEFAULT
CELL_FLASH_CACHE DEFAULT
LOGGING
NOCOMPRESS
NOCACHE
NOPARALLEL
MONITORING;
CREATE INDEX SP.TRXNS_ACCOUNTID_NIDX ON SP.TRXNS
(ACCOUNTID, postdt)
LOGGING
TABLESPACE SO_TRXN_INDEX
PCTFREE 10
INITRXNS 2
MAXTRXNS 255
STORAGE (
INITIAL 64K
NEXT 1M
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
FREELISTS 1
FREELIST GROUPS 1
BUFFER_POOL DEFAULT
FLASH_CACHE DEFAULT
CELL_FLASH_CACHE DEFAULT
NOPARALLEL;
below is the executing plan for this sql taken from toad :
PLAN_ID
TIMESTAMP
OPERATION
OPTIONS
OBJECT_OWNER
OBJECT_NAME
OBJECT_ALIAS
OBJECT_INSTANCE
OBJECT_TYPE
OPTIMIZER
SEARCH_COLUMNS
ID
PARENT_ID
DEPTH
POSITION
COST
CARDINALITY
BYTES
CPU_COST
IO_COST
TEMP_SPACE
ACCESS_PREDICATES
FILTER_PREDICATES
PROJECTION
TIME
QBLOCK_NAME
1121
9/10/2013 3:30
FILTER
1
0
1
1
NOT EXISTS (SELECT 0 FROM "TRXNSTRACK" "TRCK" WHERE "TRXNSTRACKREASONID"=1 AND "TRCK"."TRXNSID"=:B1)
AL."FROMACCOUNTID"[NUMBER,22], "T"."TRXNSID"[NUMBER,22], "T"."TRXNSTYPEID"[NUMBER,22], "T"."DESCRIPTION"[VARCHAR2,80], "T"."POSTDT"[DATE,7], "T"."TRXNSAMT"[NUMBER,22], "A"."ACCOUNTNUM"[VARCHAR2,19]
SEL$5DA710D3
1121
9/10/2013 3:30
FILTER
2
1
2
1
SYSDATE@!-2<=SYSDATE@!
AL."FROMACCOUNTID"[NUMBER,22], "T"."TRXNSID"[NUMBER,22], "T"."TRXNSTYPEID"[NUMBER,22], "T"."DESCRIPTION"[VARCHAR2,80], "T"."POSTDT"[DATE,7], "T"."TRXNSAMT"[NUMBER,22], "A"."ACCOUNTNUM"[VARCHAR2,19]
1121
9/10/2013 3:30
NESTED LOOPS
3
2
3
1
(#keys=0) "AL"."FROMACCOUNTID"[NUMBER,22], "T"."TRXNSID"[NUMBER,22], "T"."TRXNSTYPEID"[NUMBER,22], "T"."DESCRIPTION"[VARCHAR2,80], "T"."POSTDT"[DATE,7], "T"."TRXNSAMT"[NUMBER,22], "A"."ACCOUNTNUM"[VARCHAR2,19]
1121
9/10/2013 3:30
NESTED LOOPS
4
3
4
1
5
1
119
3989858
4
(#keys=0) "AL"."FROMACCOUNTID"[NUMBER,22], "T"."TRXNSID"[NUMBER,22], "T"."TRXNSTYPEID"[NUMBER,22], "T"."DESCRIPTION"[VARCHAR2,80], "T"."POSTDT"[DATE,7], "T"."TRXNSAMT"[NUMBER,22], "A".ROWID[ROWID,10]
1
1121
9/10/2013 3:30
NESTED LOOPS
5
4
5
1
4
1
90
3989690
3
(#keys=0) "AL"."FROMACCOUNTID"[NUMBER,22], "T"."TRXNSID"[NUMBER,22], "T"."TRXNSTYPEID"[NUMBER,22], "T"."DESCRIPTION"[VARCHAR2,80], "T"."POSTDT"[DATE,7], "T"."TRXNSAMT"[NUMBER,22]
1
1121
9/10/2013 3:30
HASH JOIN
SEMI
6
5
6
1
3
2
54
3989094
2
AL."TOACCOUNTID"="TOACCOUNTID"
(#keys=1) "AL"."FROMACCOUNTID"[NUMBER,22]
1
1121
9/10/2013 3:30
INDEX
FULL SCAN
SP
ACCOUNTLINK_AK1
AL@SEL$1
INDEX (UNIQUE)
ANALYZED
7
6
7
1
1
18
252
107
1
AL."FROMACCOUNTID"[NUMBER,22], "AL"."TOACCOUNTID"[NUMBER,22]
1
SEL$5DA710D3
1121
9/10/2013 3:30
VIEW
SYS
VW_NSO_1
VW_NSO_1@SEL$5DA710D3
11
VIEW
8
6
7
2
2
18
234
107
1
TOACCOUNTID[NUMBER,22]
1
SEL$683B0107
1121
9/10/2013 3:30
CONNECT BY
NO FILTERING WITH START-WITH
9
8
8
1
TOACCOUNTID=PRIOR "FROMACCOUNTID"
TOACCOUNTID=56354162
TOACCOUNTID[NUMBER,22], "FROMACCOUNTID"[NUMBER,22], PRIOR NULL[22], LEVEL[4]
SEL$683B0107
1121
9/10/2013 3:30
INDEX
FULL SCAN
SP
ACCOUNTLINK_AK1
ACCOUNTLINK@SEL$3
INDEX (UNIQUE)
ANALYZED
10
9
9
1
1
18
252
107
1
ACCOUNTLINK.ROWID[ROWID,10], "FROMACCOUNTID"[NUMBER,22], "TOACCOUNTID"[NUMBER,22]
1
SEL$3
1121
9/10/2013 3:30
TABLE ACCESS
BY INDEX ROWID
SP
TRXNS
T@SEL$1
2
TABLE
ANALYZED
11
5
6
2
1
1
63
298
1
T."TRXNSID"[NUMBER,22], "T"."TRXNSTYPEID"[NUMBER,22], "T"."DESCRIPTION"[VARCHAR2,80], "T"."POSTDT"[DATE,7], "T"."TRXNSAMT"[NUMBER,22]
1
SEL$5DA710D3
1121
9/10/2013 3:30
INDEX
RANGE SCAN
SP
TRXNS_ACCOUNTID_NIDX
T@SEL$1
INDEX
ANALYZED
2
12
11
7
1
1
1
224
1
AL."FROMACCOUNTID"="T"."ACCOUNTID" AND "T"."POSTDT">=SYSDATE@!-2 AND "T"."POSTDT"<=SYSDATE@!
T.ROWID[ROWID,10], "T"."POSTDT"[DATE,7]
1
SEL$5DA710D3
1121
9/10/2013 3:30
INDEX
UNIQUE SCAN
SP
ACCOUNT_PK
A@SEL$1
INDEX (UNIQUE)
ANALYZED
1
13
4
5
2
1
1
90
1
A."ACCOUNTID"="AL"."FROMACCOUNTID"
A.ROWID[ROWID,10]
1
SEL$5DA710D3
1121
9/10/2013 3:30
TABLE ACCESS
BY INDEX ROWID
SP
ACCOUNT
A@SEL$1
3
TABLE
ANALYZED
14
3
4
2
1
1
29
168
1
A."CLOSEDATE"<SYSDATE@! AND "T"."POSTDT">"A"."CLOSEDATE"
A."ACCOUNTNUM"[VARCHAR2,19]
1
SEL$5DA710D3
1121
9/10/2013 3:30
INDEX
RANGE SCAN
SP
TRXNSTRACK_TRXNSID_NIDX
TRCK@SEL$6
INDEX
ANALYZED
2
15
1
2
2
1
1
10
73
1
TRCK."TRXNSID"=:B1 AND "TRXNSTRACKREASONID"=1
TRCK."TRXNSID"[NUMBER,22], "TRXNSTRACKREASONID"[NUMBER,22]
1
SEL$6
Please help me in debugging this thanks!Hi,
Thanks for your thought on this subject. Below is the trace info that I got from the DBA
SQL ID: d0x879qx2zgtz Plan Hash: 4036333519
SELECT /*+ INDEX(T TRXNS_ACCOUNTID_NIDX) */ AL.FROMACCOUNTID OLDACCOUNTID ,
A.ACCOUNTNUM OLDACCOUNTNUM, T.TRXNSID, T.TRXNSTYPEID, T.DESCRIPTION ,
T.POSTDT, T.TRXNSAMT
FROM
ACCOUNTLINK AL, TRXNS T, ACCOUNT A WHERE AL.TOACCOUNTID IN (SELECT
TOACCOUNTID FROM ACCOUNTLINK START WITH TOACCOUNTID = :B3 CONNECT BY PRIOR
FROMACCOUNTID = TOACCOUNTID) AND AL.FROMACCOUNTID = T.ACCOUNTID AND
A.ACCOUNTID = AL.FROMACCOUNTID AND NOT EXISTS (SELECT 1 FROM TRXNSTRACK
TRCK WHERE TRCK.TRXNSID = T.TRXNSID AND TRXNSTRACKREASONID = :B4 ) AND
T.POSTDT > A.CLOSEDATE AND T.POSTDT >= :B2 AND T.POSTDT <= :B1
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 17160 2.10 1.87 0 0 0 0
Fetch 17160 7354.61 7390.86 169408 5569856 883366791 0
total 34320 7356.71 7392.74 169408 5569856 883366791 0
Misses in library cache during parse: 0
Optimizer mode: CHOOSE
Parsing user id: 38 (recursive depth: 1)
SQL ID: gs89hpavb4cts Plan Hash: 3415795327
SELECT A.ACCOUNTID, C.MEMBERID, A.PROGRAMID, A.ACCOUNTNUM
FROM
CUSTOMER C, CUSTOMERACCOUNT CA, ACCOUNT A, PROGRAMPARAMVALUE PPV,
BATCHPROCESSPROGRAM BP WHERE A.PROGRAMID = BP.PROGRAMID AND A.PROGRAMID =
PPV.PROGRAMID AND A.ACCOUNTID = CA.ACCOUNTID AND CA.PERSONID = C.PERSONID
AND PPV.PARAMID = :B2 AND PPV.VALUE = 'Y' AND BP.PROCESSID = :B1 AND BP.RUN
= 'Y' AND A.ACCOUNTTYPEID = 4 AND A.ACCOUNTSTATUSID = 1 AND C.MEMBERID IS
NOT NULL
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 0 0.00 0.00 0 0 0 0
Fetch 172 13.14 115.34 80826 278650 0 17200
total 172 13.14 115.34 80826 278650 0 17200
Misses in library cache during parse: 0
Parsing user id: 38 (recursive depth: 1)
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 0 0.00 0.00 0 0 0 0
Fetch 0 0.00 0.00 0 0 0 0
total 0 0.00 0.00 0 0 0 0
Misses in library cache during parse: 0
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 17160 2.10 1.87 0 0 0 0
Fetch 17332 7367.75 7506.21 250234 5848506 883366791 17200
total 34492 7369.85 7508.09 250234 5848506 883366791 17200
Misses in library cache during parse: 0
2 user SQL statements in session.
0 internal SQL statements in session.
2 SQL statements in session.
Trace file: svoprod_ora_12346.trc
Trace file compatibility: 11.1.0.7
Sort options: default
1 session in tracefile.
2 user SQL statements in trace file.
0 internal SQL statements in trace file.
2 SQL statements in trace file.
2 unique SQL statements in trace file.
66499 lines in trace file.
7516 elapsed seconds in trace file. -
Need help further tuning view source for outer join
I have been working on tuning views for use in Discoverer for some time, and I have greatly improved upon what was there, but it is still not where I need it to be. There are 2 views the users join together in Discoverer - one for contract lines, and one for contract flexfields. Run as a 1 to 1 join on contract number, performance is great. However, as soon as I have an outer join on flexfields, the performance is awful. We are talking a difference of under a minute to hours and hours. I have to be able to perform an outer join because there can be contracts without flexfields. Can anyone suggest an alternative method to get the data or further tuning? I will paste both the contract lines and contract flexfields source - I have tuned the flexfields but have done nothing to date with the lines.
CREATE OR REPLACE VIEW XXDBD_CONTRACT_FLEXFIELDS AS
SELECT core.contract_id, core.service_id, core.contract_number, core.service_line, core.service, core.product_line, core.equipment, core.UL_Certificate_And_End_Date, core.MAF, core.Termination_Penalty_Percentage, core.multi_year, core.multi_year_effective_dates, core.terms_multi_year, core.SerLineRenPricingMethod, core.ren_line_change, core.zone, core.add_invoice_display, core.add_subgrouping, re.diebold_price, attr.coverage_hours, attr.reaction_times, attr.resolution_times, attr.repair_times, tr.performance_requirement, attr.penalty, attr.penalty_amount, attr.penalty_bonus, attr.mon_break_start, attr.mon_break_end, attr.tues_break_start, attr.tues_break_end, attr.wed_break_start, attr.wed_break_end, attr.thu_break_start, attr.thu_break_end, attr.fri_break_start, attr.fri_break_end, attr.sat_break_start, attr.sat_break_end, attr.sun_break_start, attr.sun_break_end, attr.split_covering, attr.cash_handling
FROM (SELECT aa.ID Contract_id,
aa.contract_number,
dd.id Service_ID ,
dd.cle_id dd_cle_id,
dd.line_number service_line,
xxdbd_Disco_Service_Contract.GetServNameInv
(dd.id) Service,
dd.line_number ||'.'||ee.line_number Product_Line,
xxdbd_Disco_Service_Contract.GetEqpNoInvoice(ee.id)
Equipment,
DECODE(dd.attribute_category,'Service Contracts',
NVL(xxdbd_Disco_Service_Contract.GetContractMasterProperty('DBD_OKS_50_CHARS', dd.attribute1),dd.attribute1),'') UL_Certificate_And_End_Date,
dd.attribute2 MAF,
DECODE(dd.attribute_category,'Service Contracts',NVL(xxdbd_Disco_Service_Contract.GetContractMasterProperty('DBD_OKS_NUMERIC', dd.attribute3),dd.attribute3),'') Termination_Penalty_Percentage,
DECODE(dd.attribute_category,'Service Contracts', DECODE(NVL(xxdbd_Disco_Service_Contract.GetContractMasterProperty('DBD_OKS_MULTIYEAR', dd.attribute5),dd.attribute5),
'N','No Multi-Year',
'Y','Multi-Year, Years not Known',
'Y1','Multi-Year for 1 Year',
'Y2','Multi-Year for 2 Year',
'Y3','Multi-Year for 3 Year',
'Y4','Multi-Year for 4 Year',
'Y5','Multi-Year for 4 Year',dd.attribute5),'')Multi_Year,
dd.attribute4 Multi_Year_Effective_Dates,
DECODE(dd.attribute_category,'Service Contracts', NVL(xxdbd_Disco_Service_Contract.GetContractMasterProperty('DBD_OKS_450_CHARS', dd.attribute9),dd.attribute9),'') Terms_Multi_Year,
DECODE(dd.attribute_category,'Service Contracts', DECODE(NVL(xxdbd_Disco_Service_Contract.GetContractMasterProperty('DBD_OKS_RENEWAL_PRICING', dd.attribute6),dd.attribute6),
'MP', 'DBD Markup Percent',
'CP', 'DBD Contract Price',
'AI', 'DBD Amount Increase',
'AD', 'DBD Amount Decrease',
'TA', 'DBD Target Amount',
'FR', 'DBD Flat Rate',dd.attribute6),'') SerLineRenPricingMethod,
DECODE(dd.attribute_category,'Service Contracts', NVL(xxdbd_Disco_Service_Contract.GetContractMasterProperty('DBD_OKS_NUMERIC', dd.attribute7),dd.attribute7),'') Ren_Line_Change,
DECODE(dd.attribute_category,'Service Contracts', DECODE(NVL(xxdbd_Disco_Service_Contract.GetContractMasterProperty('DBD_OKS_ZONE', dd.attribute8),dd.attribute8),
'DNA1','DNA Zone 1',
'DNA2','DNA Zone 2',
'DNA3','DNA Zone 3',
'BRAZIL1','Brazil Zone 1 (50 KM)',
'BRAZIL2','Brazil Zone 2 (80 KM)',
'BRAZIL3','Brazil Zone 3 (200 KM)',dd.attribute8),'')Zone,
DECODE(dd.attribute11, 'N','None','SC','Sub Component', 'SN', 'Serial Number', 'SNSC', 'Serial Number and Sub-Component') Add_Invoice_Display,
DECODE(dd.attribute10, 'SI','Service Item', 'CP','Covered Product', 'PC','Product Category') Add_SubGrouping,
dd.attribute12 Diebold_Price,
ee.id ee_id,
ee.cle_id ee_cle_id
FROM okc_k_headers_b aa,
okc_k_lines_b dd,
okc_k_lines_b ee
-- xxdbd_temp_flex_contract tfc
WHERE aa.id = dd.DNZ_CHR_ID
AND dd.CLE_ID IS NULL
AND dd.id = ee.cle_id
AND ee.DNZ_CHR_ID = aa.id
AND ee.LSE_ID =9
AND dd.LSE_ID =1
-- and aa.contract_number = 'NL0000014'
-- and aa.contract_number in (select contract_number from xxdbd_flex_contract)
-- AND tfc.contract_number = aa.contract_number
) core,
(SELECT h.contract_number,
DECODE(l.attribute_category,
'Coverage Break', xxdbd_get_sib_cont_id(xxdbd_get_parent_cle_id(l.cle_id,2)),
'Business Process',xxdbd_get_sib_cont_id(xxdbd_get_parent_cle_id(l.cle_id,1)),
'Coverage Template Header',xxdbd_get_sib_cont_id(l.cle_id),
'Transaction Type', xxdbd_get_sib_cont_id(xxdbd_get_parent_cle_id(l.cle_id,2)),null) ee_id,
DECODE(l.attribute_category, 'Business Process', l.attribute1) Coverage_Hours,
DECODE(l.attribute_category, 'Business Process', l.attribute2) Reaction_Times,
DECODE(l.attribute_category, 'Business Process', l.attribute3) Resolution_Times,
DECODE(l.attribute_category, 'Business Process', l.attribute4) Repair_Times,
DECODE(l.attribute_category, 'Business Process', DECODE(l.attribute5,
'RA', 'REACTION'
, 'RS', 'RESOLUTION'
, 'RR', 'REACTION & RESOLUTION'
, 'NR', 'NO REQUIREMENT',
l.attribute5)) Performance_Requirement,
DECODE(l.attribute_category, 'Coverage Template Header', l.attribute1) Penalty,
DECODE(l.attribute_category, 'Coverage Template Header', l.attribute2) Penalty_Amount,
DECODE(l.attribute_category, 'Coverage Template Header', l.attribute3) Penalty_Bonus,
DECODE(l.attribute_category, 'Coverage Break', l.attribute1) Mon_Break_Start,
DECODE(l.attribute_category, 'Coverage Break', l.attribute2) Mon_Break_End,
DECODE(l.attribute_category, 'Coverage Break', l.attribute3) Tues_Break_Start,
DECODE(l.attribute_category, 'Coverage Break', l.attribute4) Tues_Break_End,
DECODE(l.attribute_category, 'Coverage Break', l.attribute5) Wed_Break_Start,
DECODE(l.attribute_category, 'Coverage Break', l.attribute6) Wed_Break_End,
DECODE(l.attribute_category, 'Coverage Break', l.attribute7) Thu_Break_Start,
DECODE(l.attribute_category, 'Coverage Break', l.attribute8) Thu_Break_End,
DECODE(l.attribute_category, 'Coverage Break', l.attribute9) Fri_Break_Start,
DECODE(l.attribute_category, 'Coverage Break', l.attribute10) Fri_Break_End,
DECODE(l.attribute_category, 'Coverage Break', l.attribute11) Sat_Break_Start,
DECODE(l.attribute_category, 'Coverage Break', l.attribute12) Sat_Break_End,
DECODE(l.attribute_category, 'Coverage Break', l.attribute13) Sun_Break_Start,
DECODE(l.attribute_category, 'Coverage Break', l.attribute14) Sun_Break_End,
DECODE(l.attribute_category, 'Transaction Type', l.attribute1) Split_Covering,
DECODE(l.attribute_category, 'Transaction Type', l.attribute2) Cash_Handling
from okc_k_lines_b l , okc_k_headers_b h--, xxdbd_temp_flex_contract tfc
where l.attribute_category in ('Coverage Break', 'Business Process', 'Coverage Template Header','Transaction Type')
and h.id = l.dnz_chr_id
-- and h.contract_number in (select contract_number from xxdbd_flex_contract)
-- and tfc.contract_number = h.contract_number
) attr
where core.ee_id = attr.ee_id (+)
and core.contract_number = attr.contract_number (+);
create or replace view xxdbd_contract_lines as
select aa.id Contract_id,
bb.id Service_id,
aa.CONTRACT_NUMBER,
F1.USER_NAME Created_By,
F2.USER_NAME LastUpdated_By,
bb.LINE_NUMBER Service_Line_No,
bb.LINE_NUMBER ||'.'|| cc.LINE_NUMBER Product_Line_No,
xxdbd_Disco_Service_Contract.GetServNameInv(bb.id) Service,
xxdbd_Disco_Service_Contract.GetServDescInv(bb.id) Service_Desc,
xxdbd_Disco_Service_Contract.GetServicePrice(bb.id) Service_Price,
bb.PRICE_UNIT Service_List_Price,
bb.CURRENCY_CODE,
aa.SCS_CODE Contract_Type,
bb.STS_CODE Service_Status,
bb.TRN_CODE Term_Code,
bb.START_DATE Service_start,
bb.END_DATE Service_end,
TO_NUMBER(OKS_ENT_UTIL_PVT.get_billtoshipto(Null, bb.id, 'OKX_BILLTO' )) SERVICE_BillToSite,
xxdbd_Disco_Service_Contract.GetLocAccount(TO_NUMBER(OKS_ENT_UTIL_PVT.get_billtoshipto(Null, bb.id, 'OKX_BILLTO' ))) Bill_Account,
xxdbd_Disco_Service_Contract.GetLocation(TO_NUMBER(OKS_ENT_UTIL_PVT.get_billtoshipto(NULL, bb.id, 'OKX_BILLTO' ))) Service_BillTo,
TO_NUMBER(OKS_ENT_UTIL_PVT.get_billtoshipto(NULL, bb.id, 'OKX_SHIPTO' )) SERVICE_ShipToSite ,
xxdbd_Disco_Service_Contract.GetLocation(TO_NUMBER(OKS_ENT_UTIL_PVT.get_billtoshipto(NULL, bb.id, 'OKX_SHIPTO' ))) Service_Ship_To,
xxdbd_Disco_Service_Contract.GetLocAccount(TO_NUMBER(OKS_ENT_UTIL_PVT.get_billtoshipto(NULL, bb.id, 'OKX_SHIPTO' ))) Ship_Account,
bb.DATE_RENEWED,
bb.DATE_TERMINATED,
cc.START_DATE Eqp_Start,
cc.END_DATE Eqp_End,
xxdbd_Disco_Service_Contract.GetEqpNoInvoice(cc.id) Eqp_No,
xxdbd_Disco_Service_Contract.GetEqpDescInvoice(cc.ID) Eqp_Desc,
xxdbd_Disco_Service_Contract.GetEqpQuantityInvoice(cc.id) Eqp_Quan,
xxdbd_Disco_Service_Contract.GetEqpSerialNoInvoice(cc.id) Eqp_Serial,
xxdbd_Disco_Service_Contract.GetCustomerCt(aa.id, bb.id) Cust_Contact,
DD.ORGANIZATION_ID,
dd.INSTALL_ADDRESS,
dd.INSTALL_DATE,
dd.INSTALL_SITE_ID INSTALL_SITE_USE_ID,
dd.PARTY_SITE_NAME INSTALL_SITE_NAME,
dd.PARTY_SITE_NUMBER INSTALL_SITE_NUMBER
,cii.inventory_item_id
,cii.inv_master_organization_id
,aa.authoring_org_id
,cc.id equipment_id
,TO_NUMBER(replace(bb.attribute12,',','')) annual_contract_amt
,ou.name operating_unit
,ou.organization_id operating_unit_id
,substr(xxdbd_ra_utility.Get_BusinessProcess(cc.cle_id),1,100) business_process
,cii.instance_id
,cii.instance_number
from okc_k_headers_b aa
,okc_k_lines_b bb
,okc_k_lines_b cc
,fnd_user f1
,fnd_user f2
,csi_item_instances cii
,okc_k_items items
,hr_all_organization_units ou
,xxdbd_oks_install_info_v dd
where aa.id = bb.dnz_chr_id
and bb.cle_id is null
and cc.cle_id = bb.id
and cc.dnz_chr_id = aa.id
and f1.user_id = bb.created_by
and f2.user_id = bb.last_updated_by
and cc.lse_id in (9,25,18,40)
and dd.line_id (+) = cc.id
and items.cle_id = cc.id
and cii.instance_id = items.object1_id1
and aa.authoring_org_id = ou.organization_id (+);
Here are the explain plans from TOAD:
Operation Object Name Rows Bytes Cost Object Node In/Out PStart PStop
SELECT STATEMENT Optimizer Mode=CHOOSE 6 49124
NESTED LOOPS OUTER 6 80 K 49124
VIEW 6 80 K 49112
HASH JOIN 6 1 K 49112
HASH JOIN 17 K 2 M 20214
TABLE ACCESS FULL OKC.OKC_K_HEADERS_B 5 K 175 K 37
TABLE ACCESS BY INDEX ROWID OKC.OKC_K_LINES_B 17 K 1 M 20162
INDEX SKIP SCAN XXDBD.XXDBD_OKC_K_LINES_B_N10 39 17085
TABLE ACCESS FULL OKC.OKC_K_LINES_B 502 K 34 M 27803
VIEW PUSHED PREDICATE 1 107 2
TABLE ACCESS BY INDEX ROWID OKC.OKC_K_LINES_B 42 3 K 216
NESTED LOOPS 50 5 K 219
TABLE ACCESS BY INDEX ROWID OKC.OKC_K_HEADERS_B 1 33 3
INDEX RANGE SCAN OKC.OKC_K_HEADERS_B_U2 1 2
INDEX RANGE SCAN OKC.OKC_K_LINES_B_N2 1 K 32
Operation Object Name Rows Bytes Cost Object Node In/Out PStart PStop
SELECT STATEMENT Optimizer Mode=CHOOSE 245 63309
NESTED LOOPS 245 291 K 63309
NESTED LOOPS OUTER 245 286 K 63064
NESTED LOOPS 245 80 K 62574
HASH JOIN 245 74 K 61839
HASH JOIN 245 71 K 61756
HASH JOIN OUTER 245 68 K 61673
HASH JOIN 245 60 K 61664
HASH JOIN 205 K 32 M 28046
TABLE ACCESS FULL OKC.OKC_K_HEADERS_B 5 K 244 K 37
TABLE ACCESS FULL OKC.OKC_K_LINES_B 205 K 23 M 27803
TABLE ACCESS FULL OKC.OKC_K_LINES_B 2 M 168 M 27803
TABLE ACCESS FULL HR.HR_ALL_ORGANIZATION_UNITS 2 K 64 K 8
TABLE ACCESS FULL APPLSYS.FND_USER 13 K 172 K 81
TABLE ACCESS FULL APPLSYS.FND_USER 13 K 172 K 81
TABLE ACCESS BY INDEX ROWID OKC.OKC_K_ITEMS 1 26 3
INDEX RANGE SCAN OKC.OKC_K_ITEMS_N1 1 2
VIEW APPS.XXDBD_OKS_INSTALL_INFO_V 1 861 2
UNION-ALL PARTITION
NESTED LOOPS 1 167 9
NESTED LOOPS 1 108 8
NESTED LOOPS 1 85 7
NESTED LOOPS 1 51 6
TABLE ACCESS BY INDEX ROWID OKC.OKC_K_LINES_B 1 25 3
INDEX UNIQUE SCAN OKC.OKC_K_LINES_B_U1 1 2
TABLE ACCESS BY INDEX ROWID OKC.OKC_K_ITEMS 1 26 3
INDEX RANGE SCAN OKC.OKC_K_ITEMS_N1 1 2
TABLE ACCESS BY INDEX ROWID CSI.CSI_ITEM_INSTANCES 1 34 1
INDEX UNIQUE SCAN CSI.CSI_ITEM_INSTANCES_U01 1
TABLE ACCESS BY INDEX ROWID AR.HZ_PARTY_SITES 1 23 1
INDEX UNIQUE SCAN AR.HZ_PARTY_SITES_U1 1
TABLE ACCESS BY INDEX ROWID AR.HZ_LOCATIONS 1 59 1
INDEX UNIQUE SCAN AR.HZ_LOCATIONS_U1 1
NESTED LOOPS 1 144 8
NESTED LOOPS 1 85 7
NESTED LOOPS 1 51 6
TABLE ACCESS BY INDEX ROWID OKC.OKC_K_LINES_B 1 25 3
INDEX UNIQUE SCAN OKC.OKC_K_LINES_B_U1 1 2
TABLE ACCESS BY INDEX ROWID OKC.OKC_K_ITEMS 1 26 3
INDEX RANGE SCAN OKC.OKC_K_ITEMS_N1 1 2
TABLE ACCESS BY INDEX ROWID CSI.CSI_ITEM_INSTANCES 1 34 1
INDEX UNIQUE SCAN CSI.CSI_ITEM_INSTANCES_U01 1
TABLE ACCESS BY INDEX ROWID AR.HZ_LOCATIONS 1 59 1
INDEX UNIQUE SCAN AR.HZ_LOCATIONS_U1 1
NESTED LOOPS 1 161 8
NESTED LOOPS 1 85 7
NESTED LOOPS 1 51 6
TABLE ACCESS BY INDEX ROWID OKC.OKC_K_LINES_B 1 25 3
INDEX UNIQUE SCAN OKC.OKC_K_LINES_B_U1 1 2
TABLE ACCESS BY INDEX ROWID OKC.OKC_K_ITEMS 1 26 3
INDEX RANGE SCAN OKC.OKC_K_ITEMS_N1 1 2
TABLE ACCESS BY INDEX ROWID CSI.CSI_ITEM_INSTANCES 1 34 1
INDEX UNIQUE SCAN CSI.CSI_ITEM_INSTANCES_U01 1
TABLE ACCESS BY INDEX ROWID AR.HZ_PARTIES 1 76 1
INDEX UNIQUE SCAN AR.HZ_PARTIES_U1 1
TABLE ACCESS BY INDEX ROWID CSI.CSI_ITEM_INSTANCES 1 21 1
INDEX UNIQUE SCAN CSI.CSI_ITEM_INSTANCES_U01 1
And here is the SQL to join:
select * from xxdbd_contract_lines l, xxdbd_contract_flexfields f
where f.service_id (+) = l.service_id
and f.contract_number (+) = l.contract_number
and l.contract_number = 'NL0000014'
Operation Object Name Rows Bytes Cost Object Node In/Out PStart PStop
SELECT STATEMENT Optimizer Mode=CHOOSE 1 49221
HASH JOIN OUTER 1 38 K 49221
VIEW APPS.XXDBD_CONTRACT_LINES 1 19 K 96
NESTED LOOPS OUTER 1 1 K 96
NESTED LOOPS 1 358 94
NESTED LOOPS 1 345 93
NESTED LOOPS 1 332 92
NESTED LOOPS 1 311 91
NESTED LOOPS 1 285 88
NESTED LOOPS 448 72 K 88
NESTED LOOPS OUTER 1 78 4
TABLE ACCESS BY INDEX ROWID OKC.OKC_K_HEADERS_B 1 46 3
INDEX RANGE SCAN OKC.OKC_K_HEADERS_B_U2 1 2
TABLE ACCESS BY INDEX ROWID HR.HR_ALL_ORGANIZATION_UNITS 1 32 1
INDEX UNIQUE SCAN HR.HR_ORGANIZATION_UNITS_PK 1
TABLE ACCESS BY INDEX ROWID OKC.OKC_K_LINES_B 378 32 K 84
INDEX RANGE SCAN XXDBD.XXDBD_OKC_K_LINES_B_N10 378 16
TABLE ACCESS BY INDEX ROWID OKC.OKC_K_LINES_B 1 119
INDEX RANGE SCAN OKC.OKC_K_LINES_B_N2 1 K 32
TABLE ACCESS BY INDEX ROWID OKC.OKC_K_ITEMS 1 26 3
INDEX RANGE SCAN OKC.OKC_K_ITEMS_N1 1 2
TABLE ACCESS BY INDEX ROWID CSI.CSI_ITEM_INSTANCES 1 21 1
INDEX UNIQUE SCAN CSI.CSI_ITEM_INSTANCES_U01 1
TABLE ACCESS BY INDEX ROWID APPLSYS.FND_USER 1 13 1
INDEX UNIQUE SCAN APPLSYS.FND_USER_U1 1
TABLE ACCESS BY INDEX ROWID APPLSYS.FND_USER 1 13 1
INDEX UNIQUE SCAN APPLSYS.FND_USER_U1 1
VIEW APPS.XXDBD_OKS_INSTALL_INFO_V 1 861 2
UNION-ALL PARTITION
NESTED LOOPS 1 167 9
NESTED LOOPS 1 108 8
NESTED LOOPS 1 85 7
NESTED LOOPS 1 51 6
TABLE ACCESS BY INDEX ROWID OKC.OKC_K_LINES_B 1 25 3
INDEX UNIQUE SCAN OKC.OKC_K_LINES_B_U1 1 2
TABLE ACCESS BY INDEX ROWID OKC.OKC_K_ITEMS 1 26 3
INDEX RANGE SCAN OKC.OKC_K_ITEMS_N1 1 2
TABLE ACCESS BY INDEX ROWID CSI.CSI_ITEM_INSTANCES 1 34 1
INDEX UNIQUE SCAN CSI.CSI_ITEM_INSTANCES_U01 1
TABLE ACCESS BY INDEX ROWID AR.HZ_PARTY_SITES 1 23 1
INDEX UNIQUE SCAN AR.HZ_PARTY_SITES_U1 1
TABLE ACCESS BY INDEX ROWID AR.HZ_LOCATIONS 1 59 1
INDEX UNIQUE SCAN AR.HZ_LOCATIONS_U1 1
NESTED LOOPS 1 144 8
NESTED LOOPS 1 85 7
NESTED LOOPS 1 51 6
TABLE ACCESS BY INDEX ROWID OKC.OKC_K_LINES_B 1 25 3
INDEX UNIQUE SCAN OKC.OKC_K_LINES_B_U1 1 2
TABLE ACCESS BY INDEX ROWID OKC.OKC_K_ITEMS 1 26 3
INDEX RANGE SCAN OKC.OKC_K_ITEMS_N1 1 2
TABLE ACCESS BY INDEX ROWID CSI.CSI_ITEM_INSTANCES 1 34 1
INDEX UNIQUE SCAN CSI.CSI_ITEM_INSTANCES_U01 1
TABLE ACCESS BY INDEX ROWID AR.HZ_LOCATIONS 1 59 1
INDEX UNIQUE SCAN AR.HZ_LOCATIONS_U1 1
NESTED LOOPS 1 161 8
NESTED LOOPS 1 85 7
NESTED LOOPS 1 51 6
TABLE ACCESS BY INDEX ROWID OKC.OKC_K_LINES_B 1 25 3
INDEX UNIQUE SCAN OKC.OKC_K_LINES_B_U1 1 2
TABLE ACCESS BY INDEX ROWID OKC.OKC_K_ITEMS 1 26 3
INDEX RANGE SCAN OKC.OKC_K_ITEMS_N1 1 2
TABLE ACCESS BY INDEX ROWID CSI.CSI_ITEM_INSTANCES 1 34 1
INDEX UNIQUE SCAN CSI.CSI_ITEM_INSTANCES_U01 1
TABLE ACCESS BY INDEX ROWID AR.HZ_PARTIES 1 76 1
INDEX UNIQUE SCAN AR.HZ_PARTIES_U1 1
VIEW APPS.XXDBD_CONTRACT_FLEXFIELDS 6 112 K 49124
NESTED LOOPS OUTER 6 80 K 49124
VIEW 6 80 K 49112
HASH JOIN 6 1 K 49112
HASH JOIN 17 K 2 M 20214
TABLE ACCESS FULL OKC.OKC_K_HEADERS_B 5 K 175 K 37
TABLE ACCESS BY INDEX ROWID OKC.OKC_K_LINES_B 17 K 1 M 20162
INDEX SKIP SCAN XXDBD.XXDBD_OKC_K_LINES_B_N10 39 17085
TABLE ACCESS FULL OKC.OKC_K_LINES_B 502 K 34 M 27803
VIEW PUSHED PREDICATE 1 107 2
TABLE ACCESS BY INDEX ROWID OKC.OKC_K_LINES_B 42 3 K 216
NESTED LOOPS 50 5 K 219
TABLE ACCESS BY INDEX ROWID OKC.OKC_K_HEADERS_B 1 33 3
INDEX RANGE SCAN OKC.OKC_K_HEADERS_B_U2 1 2
INDEX RANGE SCAN OKC.OKC_K_LINES_B_N2 1 K 32DECODE(l.attribute_category, 'Coverage Template Header', l.attribute3) Penalty_Bonus,
DECODE(l.attribute_category, 'Coverage Break', l.attribute1) Mon_Break_Start,
DECODE(l.attribute_category, 'Transaction Type', l.attribute1) Split_Covering,Uh oh, the dreaded entity attibute value, or generic, data model.
http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:10678084117056
I am afraid slow performance is a built in feature of this database design, not much you can do in queries.
You could possibly create the views as materialized views and query those instead.
Quote from the linked article
But, how does it perform? Miserably, terribly, horribly. A simple "select
first_name, last_name from person" query is transformed into a 3-table join with
aggregates and all. Further, if the attributes are "NULLABLE" - that is, there
might not be a row in OBJECT_ATTRIBUTES for some attributes, you may have to
outer join instead of just joining which in some cases can remove more optimal
query plans from consideration.
Writing queries might look pretty straightforward, but it's impossible to do in
a performant fashion. -
Hi list ,
I need your help in tuning this sql.
Oracle 10g,Windows 2008 64 bit running on virtual machine.
SELECT t0.RecID, t0.PrtID, t0.RecOrdDt, t0.RecOrdID, t0.RecExtOrdID, t0.RecPocID, t0.PriID, t0.CasID, t0.CasNo, t0.CasClass, t0.CasPocID, t0.CasAdmit, t0.CasNotValid, t0.PatName, t0.PatFName, t0.PatBName, t0.PatBDate, t0.PatSex, t0.PatNotValid, t0.RstID, t0.RstState, t0.RstMeaningI18N, t0.PrtType, t0.PrtSubType, t0.RpxType, t0.RpxPrio, t0.PerID, t0.PerName, t0.PerFName, t0.PerTitle, t0.PerType, t0.AgnExtID
FROM
IXSERV.XsvRecPerInfoV t0
WHERE
((((t0.AgnExtID = '1728454694') AND (t0.PrtID IN (72, 165)))
AND (t0.RpxType IN (1, 2, 6, 3, 5)))
AND (t0.RstState IN (202, 208, 210, 203, 206)))
call count cpu elapsed disk query current rows
Parse 1 0.04 0.03 0 1999 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 4 5.39 57.42 45408 53080 0 45
total 6 5.43 57.46 45408 55079 0 45
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: SYS
Rows Row Source Operation
45 NESTED LOOPS (cr=53080 pr=45408 pw=0 time=2611987 us)
45 NESTED LOOPS (cr=52941 pr=45355 pw=0 time=46145568 us)
45 HASH JOIN (cr=52802 pr=45314 pw=0 time=45407144 us)
1 TABLE ACCESS BY INDEX ROWID PERPERSON (cr=3 pr=6 pw=0 time=40510 us)
1 INDEX RANGE SCAN PERIDXAGNEXTID (cr=2 pr=5 pw=0 time=22311 us)(object id 56817)
23623 TABLE ACCESS BY INDEX ROWID XSVRECPERXREF (cr=52799 pr=45308 pw=0 time=50046345 us)
33893 NESTED LOOPS (cr=47543 pr=42261 pw=0 time=73003406 us)
5139 HASH JOIN (cr=37184 pr=40103 pw=0 time=56090695 us)
5 TABLE ACCESS FULL XMFREPORTSTATE (cr=7 pr=6 pw=0 time=22565 us)
66900 TABLE ACCESS BY INDEX ROWID XSVPATIENTRECORD (cr=37177 pr=40097 pw=0 time=39887547 us)
66903 NESTED LOOPS (cr=146 pr=141 pw=0 time=8095232 us)
2 INLIST ITERATOR (cr=4 pr=3 pw=0 time=37200 us)
2 TABLE ACCESS BY INDEX ROWID XMFPATIENTRECORDTYPE (cr=4 pr=3 pw=0 time=37198 us)
2 INDEX UNIQUE SCAN PKPRT (cr=2 pr=1 pw=0 time=26746 us)(object id 56143)
66900 INDEX RANGE SCAN RECIDXPRTID (cr=142 pr=138 pw=0 time=51513 us)(object id 56410)
28753 INDEX RANGE SCAN RPXIDXRECID (cr=10359 pr=2158 pw=0 time=4518986 us)(object id 56453)
45 TABLE ACCESS BY INDEX ROWID ADTCASE (cr=139 pr=41 pw=0 time=423483 us)
45 INDEX UNIQUE SCAN PK_ADTCASE (cr=94 pr=23 pw=0 time=184866 us)(object id 55295)
45 TABLE ACCESS BY INDEX ROWID ADTPATIENT (cr=139 pr=53 pw=0 time=413067 us)
45 INDEX UNIQUE SCAN PK_ADTPATIENT (cr=94 pr=21 pw=0 time=195583 us)(object id 55361)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net break/reset to client 2 0.00 0.00
SQL*Net message to client 5 0.00 0.00
SQL*Net message from client 5 114.42 128.67
SQL*Net more data to client 1 0.00 0.00
db file sequential read 27969 0.13 51.57
db file scattered read 3271 0.05 4.61
Some lines from trace fils :
WAIT #1: nam='db file sequential read' ela= 12778 file#=4 block#=3726132 blocks=1 obj#=56817 tim=249799016372
WAIT #1: nam='db file scattered read' ela= 9271 file#=4 block#=3726133 blocks=4 obj#=56817 tim=249799025761
WAIT #1: nam='db file sequential read' ela= 18141 file#=4 block#=587487 blocks=1 obj#=55853 tim=249799043945
WAIT #1: nam='db file sequential read' ela= 18304 file#=4 block#=752595 blocks=1 obj#=56219 tim=249799062471
and the view XsvRecPerInfoV is :
SELECT d.RecID, d.PrtID, d.RecOrdDt, d.RecOrdID, d.RecExtOrdID, d.PocID, d.PriID, c.CasID, c. CasNo, c.CasClass, c.PocID, c.CasAdmit, c.CasNotValid, p.PatName, p.PatFName, p.PatBName, p.PatBDate, p.PatSex, p.PatNotValid, r.RstID, r.RstState, r.RstMeaningI18N, prt.PrtType, prt.PrtSubType, x.RpxType, x.RpxPrio, per.PerID, per.PerName, per.PerFName, per.PerTitle, per.PerType, per.AgnExtID
FROM XsvPatientRecord d,
AdtCase c,
AdtPatient p,
XmfReportState r,
XmfPatientRecordType prt,
XsvRecPerXRef x,
PerPerson per
WHERE
d.RecID = x.RecID
AND d.RstID = r.RstID
AND d.PrtID = prt.PrtID
AND d.CasID = c.CasID
AND x.PerID = per.PerID
AND c.PatID = p.PatID
i have two questions :
-1 The problem in tables XSVPATIENTRECORD and XSVRECPERXREF so how can i speed this query either by rewriting it or indexs?
-2 is my system i-o is slow ?
Best wishes
Edited by: welo on Oct 6, 2010 5:05 AMhi ,
it did not work with dynamic samplying. I am posting here trace 10053 output for the correct plan and wrong plan choosed but the optimizer i need soome one to help me in understanding why the optimizer is choosing wrong join order.
Sql statement and wrong plan :
tageCurrent SQL statement for this session:
SELECT t0.RecID, t0.PrtID, t0.RecOrdDt, t0.RecOrdID, t0.RecExtOrdID, t0.RecPocID, t0.PriID, t0.CasID, t0.CasNo, t0.CasClass, t0.CasPocID, t0.CasAdmit, t0.CasNotValid, t0.PatName, t0.PatFName, t0.PatBName, t0.PatBDate, t0.PatSex, t0.PatNotValid, t0.RstID, t0.RstState, t0.RstMeaningI18N, t0.PrtType, t0.PrtSubType, t0.RpxType, t0.RpxPrio, t0.PerID, t0.PerName, t0.PerFName, t0.PerTitle, t0.PerType, t0.AgnExtID
FROM XsvRecPerInfoV t0
WHERE
((((t0.AgnExtID = '1393621382') AND (t0.PrtID IN (72, 165))) AND (t0.RpxType IN (1, 2, 6, 3, 5))) AND (t0.RstState IN (202, 208, 210, 203, 206)))
--------------------------------------------------------------------+-----------------------------------+
| Id | Operation | Name | Rows | Bytes | Cost | Time |
--------------------------------------------------------------------+-----------------------------------+
| 0 | SELECT STATEMENT | | | | 842 | |
| 1 | NESTED LOOPS | | 1 | 204 | 842 | 00:00:11 |
| 2 | NESTED LOOPS | | 1 | 163 | 840 | 00:00:11 |
| 3 | HASH JOIN | | 1 | 129 | 838 | 00:00:11 |
| 4 | TABLE ACCESS BY INDEX ROWID | PERPERSON | 1 | 29 | 2 | 00:00:01 |
| 5 | INDEX RANGE SCAN | PERIDXAGNEXTID | 1 | | 1 | 00:00:01 |
| 6 | TABLE ACCESS BY INDEX ROWID | XSVRECPERXREF | 2 | 34 | 3 | 00:00:01 |
| 7 | NESTED LOOPS | | 379 | 37K | 835 | 00:00:11 |
| 8 | HASH JOIN | | 238 | 19K | 342 | 00:00:05 |
| 9 | TABLE ACCESS FULL | XMFREPORTSTATE | 5 | 65 | 3 | 00:00:01 |
| 10 | TABLE ACCESS BY INDEX ROWID | XSVPATIENTRECORD | 524 | 30K | 218 | 00:00:03 |
| 11 | NESTED LOOPS | | 1049 | 72K | 338 | 00:00:05 |
| 12 | INLIST ITERATOR | | | | | |
| 13 | TABLE ACCESS BY INDEX ROWID | XMFPATIENTRECORDTYPE| 2 | 22 | 2 | 00:00:01 |
| 14 | INDEX UNIQUE SCAN | PKPRT | 2 | | 1 | 00:00:01 |
| 15 | INDEX RANGE SCAN | RECIDXPRTID | 524 | | 119 | 00:00:02 |
| 16 | INDEX RANGE SCAN | RPXIDXRECID | 2 | | 2 | 00:00:01 |
| 17 | TABLE ACCESS BY INDEX ROWID | ADTCASE | 1 | 34 | 2 | 00:00:01 |
| 18 | INDEX UNIQUE SCAN | PK_ADTCASE | 1 | | 1 | 00:00:01 |
| 19 | TABLE ACCESS BY INDEX ROWID | ADTPATIENT | 1 | 41 | 2 | 00:00:01 |
| 20 | INDEX UNIQUE SCAN | PK_ADTPATIENT | 1 | | 1 | 00:00:01 |
--------------------------------------------------------------------+-----------------------------------+
3 - access("PER"."PERID"="X"."PERID")
5 - access("PER"."AGNEXTID"='1393621382')
6 - filter(("X"."RPXTYPE"=1 OR "X"."RPXTYPE"=2 OR "X"."RPXTYPE"=3 OR "X"."RPXTYPE"=5 OR "X"."RPXTYPE"=6))
8 - access("D"."RSTID"="R"."RSTID")
9 - filter(("R"."RSTSTATE"=202 OR "R"."RSTSTATE"=203 OR "R"."RSTSTATE"=206 OR "R"."RSTSTATE"=208 OR "R"."RSTSTATE"=210))
14 - access(("PRT"."PRTID"=72 OR "PRT"."PRTID"=165))
15 - access("D"."PRTID"="PRT"."PRTID")
15 - filter(("D"."PRTID"=72 OR "D"."PRTID"=165))
16 - access("X"."RECID"="D"."RECID")
18 - access("D"."CASID"="C"."CASID")
20 - access("C"."PATID"="P"."PATID")
Join order[7]: XMFPATIENTRECORDTYPE[PRT]#1 XSVPATIENTRECORD[D]#3 XMFREPORTSTATE[R]#2 XSVRECPERXREF[X]#5 PERPERSON[PER]#0 ADTCASE[C]#6 ADTPATIENT[P]#4
Now joining: XSVPATIENTRECORD[D]#3
NL Join
Outer table: Card: 2.00 Cost: 2.00 Resp: 2.00 Degree: 1 Bytes: 11
Inner table: XSVPATIENTRECORD Alias: D
Access Path: TableScan
NL Join: Cost: 53601.79 Resp: 53601.79 Degree: 1
Cost_io: 53336.00 Cost_cpu: 7967475433
Resp_io: 53336.00 Resp_cpu: 7967475433
kkofmx: index filter:
("D"."PRTID"=72 OR "D"."PRTID"=165) AND ("X"."RPXTYPE"=1 OR "X"."RPXTYPE"=2 OR "X"."RPXTYPE"=3 OR "X"."RPXTYPE"=5 OR "X"."RPXTYPE"=6) AND ("R"."RSTSTATE"=202 OR "R"."RSTSTATE"=203 OR "R"."RSTSTATE"=206 OR "R"."RSTSTATE"=208 OR "R"."RSTSTATE"=210) AND "PER"."PERID"="X"."PERID" AND "X"."RECID"="D"."RECID" AND "D"."RSTID"="R"."RSTID" AND "D"."PRTID"="PRT"."PRTID" AND "D"."CASID"="C"."CASID" AND "C"."PATID"="P"."PATID" AND ("PRT"."PRTID"=72 OR "PRT"."PRTID"=165)
kkofmx: index filter:"D"."PRTID"="PRT"."PRTID" AND "D"."CASID"="C"."CASID" AND "C"."PATID"="P"."PATID" AND ("PRT"."PRTID"=72 OR "PRT"."PRTID"=165)
kkofmx: index filter:
("D"."PRTID"=72 OR "D"."PRTID"=165) AND ("X"."RPXTYPE"=1 OR "X"."RPXTYPE"=2 OR "X"."RPXTYPE"=3 OR "X"."RPXTYPE"=5 OR "X"."RPXTYPE"=6) AND ("R"."RSTSTATE"=202 OR "R"."RSTSTATE"=203 OR "R"."RSTSTATE"=206 OR "R"."RSTSTATE"=208 OR "R"."RSTSTATE"=210) AND "PER"."PERID"="X"."PERID" AND "X"."RECID"="D"."RECID" AND "D"."RSTID"="R"."RSTID" AND "D"."PRTID"="PRT"."PRTID" AND "D"."CASID"="C"."CASID" AND "C"."PATID"="P"."PATID" AND ("PRT"."PRTID"=72 OR "PRT"."PRTID"=165)
Access Path: index (FullScan)
Index: IRECRECORDIDPRTID
resc_io: 43172.00 resc_cpu: 2118737558
ix_sel: 1 ix_sel_with_filters: 6.2392e-005
NL Join: Cost: 86121.14 Resp: 86121.14 Degree: 1
Cost_io: 85924.00 Cost_cpu: 5909611610
Resp_io: 85924.00 Resp_cpu: 5909611610
Access Path: index (AllEqJoinGuess)
Index: RECIDXPRTID
resc_io: 217.00 resc_cpu: 13774732
ix_sel: 0.0074074 ix_sel_with_filters: 6.2392e-005
NL Join (ordered): Cost: 338.30 Resp: 338.30 Degree: 1
Cost_io: 337.00 Cost_cpu: 39079056
Resp_io: 337.00 Resp_cpu: 39079056
****** trying bitmap/domain indexes ******
****** finished trying bitmap/domain indexes ******
Best NL cost: 338.30
resc: 338.30 resc_io: 337.00 resc_cpu: 39079056
resp: 338.30 resp_io: 337.00 resp_cpu: 39079056
Join Card: 1048.85 = outer (2.00) * inner (70797.49) * sel (0.0074074)
Join Card - Rounded: 1049 Computed: 1048.85
SM Join
Outer table:
resc: 2.00 card 2.00 bytes: 11 deg: 1 resp: 2.00
Inner table: XSVPATIENTRECORD Alias: D
resc: 13387.34 card: 70797.49 bytes: 59 deg: 1 resp: 13387.34
using dmeth: 2 #groups: 1
SORT resource Sort statistics
Sort width: 445 Area size: 390144 Max Area size: 78223360
Degree: 1
Blocks to Sort: 651 Row size: 75 Total Rows: 70797
Initial runs: 2 Merge passes: 1 IO Cost / pass: 354
Total IO sort cost: 1005 Total CPU sort cost: 97398867
Total Temp space used: 11969000
SM join: Resc: 14397.59 Resp: 14397.59 [multiMatchCost=0.00]
SM cost: 14397.59
resc: 14397.59 resc_io: 14389.81 resc_cpu: 233098276
resp: 14397.59 resp_io: 14389.81 resp_cpu: 233098276
HA Join
Outer table:
resc: 2.00 card 2.00 bytes: 11 deg: 1 resp: 2.00
Inner table: XSVPATIENTRECORD Alias: D
resc: 13387.34 card: 70797.49 bytes: 59 deg: 1 resp: 13387.34
using dmeth: 2 #groups: 1
Cost per ptn: 0.74 #ptns: 1
hash_area: 124 (max=19098) buildfrag: 1 probefrag: 614 ppasses: 1
Hash join: Resc: 13390.08 Resp: 13390.08 [multiMatchCost=0.00]
HA cost: 13390.08
resc: 13390.08 resc_io: 13384.81 resc_cpu: 157767585
resp: 13390.08 resp_io: 13384.81 resp_cpu: 157767585
Best:: JoinMethod: NestedLoop
Cost: 338.30 Degree: 1 Resp: 338.30 Card: 1048.85 Bytes: 70
Now joining: XMFREPORTSTATE[R]#2
NL Join
Outer table: Card: 1048.85 Cost: 338.30 Resp: 338.30 Degree: 1 Bytes: 70
Inner table: XMFREPORTSTATE Alias: R
Access Path: TableScan
NL Join: Cost: 1489.04 Resp: 1489.04 Degree: 1
Cost_io: 1486.00 Cost_cpu: 91090703
Resp_io: 1486.00 Resp_cpu: 91090703
Access Path: index (UniqueScan)
Index: PK_XMFREPORTSTATE
resc_io: 1.00 resc_cpu: 8697
ix_sel: 0.030303 ix_sel_with_filters: 0.030303
NL Join: Cost: 1387.61 Resp: 1387.61 Degree: 1
Cost_io: 1386.00 Cost_cpu: 48201937
Resp_io: 1386.00 Resp_cpu: 48201937
Access Path: index (AllEqUnique)
Index: PK_XMFREPORTSTATE
resc_io: 1.00 resc_cpu: 8697
ix_sel: 0.030303 ix_sel_with_filters: 0.030303
NL Join: Cost: 1387.61 Resp: 1387.61 Degree: 1
Cost_io: 1386.00 Cost_cpu: 48201937
Resp_io: 1386.00 Resp_cpu: 48201937
****** trying bitmap/domain indexes ******
****** finished trying bitmap/domain indexes ******
Best NL cost: 1387.61
resc: 1387.61 resc_io: 1386.00 resc_cpu: 48201937
resp: 1387.61 resp_io: 1386.00 resp_cpu: 48201937
Join Card: 238.38 = outer (1048.85) * inner (5.00) * sel (0.045455)
Join Card - Rounded: 238 Computed: 238.38
SM Join
Outer table:
resc: 338.30 card 1048.85 bytes: 70 deg: 1 resp: 338.30
Inner table: XMFREPORTSTATE Alias: R
resc: 3.00 card: 5.00 bytes: 13 deg: 1 resp: 3.00
using dmeth: 2 #groups: 1
SORT resource Sort statistics
Sort width: 445 Area size: 390144 Max Area size: 78223360
Degree: 1
Blocks to Sort: 12 Row size: 87 Total Rows: 1049
Initial runs: 1 Merge passes: 0 IO Cost / pass: 0
Total IO sort cost: 0 Total CPU sort cost: 30450620
Total Temp space used: 0
SORT resource Sort statistics
Sort width: 445 Area size: 390144 Max Area size: 78223360
Degree: 1
Blocks to Sort: 1 Row size: 25 Total Rows: 5
Initial runs: 1 Merge passes: 0 IO Cost / pass: 0
Total IO sort cost: 0 Total CPU sort cost: 29976876
Total Temp space used: 0
SM join: Resc: 343.32 Resp: 343.32 [multiMatchCost=0.00]
SM cost: 343.32
resc: 343.32 resc_io: 340.00 resc_cpu: 99556133
resp: 343.32 resp_io: 340.00 resp_cpu: 99556133
HA Join
Outer table:
resc: 338.30 card 1048.85 bytes: 70 deg: 1 resp: 338.30
Inner table: XMFREPORTSTATE Alias: R
resc: 3.00 card: 5.00 bytes: 13 deg: 1 resp: 3.00
using dmeth: 2 #groups: 1
Cost per ptn: 0.51 #ptns: 1
hash_area: 124 (max=19098) buildfrag: 11 probefrag: 1 ppasses: 1
Hash join: Resc: 341.81 Resp: 341.81 [multiMatchCost=0.00]
HA Join (swap)
Outer table:
resc: 3.00 card 5.00 bytes: 13 deg: 1 resp: 3.00
Inner table: XSVPATIENTRECORD Alias: D
resc: 338.30 card: 1048.85 bytes: 70 deg: 1 resp: 338.30
using dmeth: 2 #groups: 1
Cost per ptn: 0.50 #ptns: 1
hash_area: 124 (max=19098) buildfrag: 1 probefrag: 11 ppasses: 1
Hash join: Resc: 341.81 Resp: 341.81 [multiMatchCost=0.00]
HA cost: 341.81
resc: 341.81 resc_io: 340.00 resc_cpu: 54222464
resp: 341.81 resp_io: 340.00 resp_cpu: 54222464
Best:: JoinMethod: Hash
Cost: 341.81 Degree: 1 Resp: 341.81 Card: 238.38 Bytes: 83
Now joining: XSVRECPERXREF[X]#5
NL Join
Outer table: Card: 238.38 Cost: 341.81 Resp: 341.81 Degree: 1 Bytes: 83
Inner table: XSVRECPERXREF Alias: X
Access Path: TableScan
NL Join: Cost: 280914.52 Resp: 280914.52 Degree: 1
Cost_io: 275752.00 Cost_cpu: 154753663635
Resp_io: 275752.00 Resp_cpu: 154753663635
kkofmx: index filter:
("X"."RPXTYPE"=1 OR "X"."RPXTYPE"=2 OR "X"."RPXTYPE"=3 OR "X"."RPXTYPE"=5 OR "X"."RPXTYPE"=6) AND ("R"."RSTSTATE"=202 OR "R"."RSTSTATE"=203 OR "R"."RSTSTATE"=206 OR "R"."RSTSTATE"=208 OR "R"."RSTSTATE"=210) AND "PER"."PERID"="X"."PERID" AND "X"."RECID"="D"."RECID" AND "D"."RSTID"="R"."RSTID" AND "D"."PRTID"="PRT"."PRTID" AND "D"."CASID"="C"."CASID" AND "C"."PATID"="P"."PATID" AND ("PRT"."PRTID"=72 OR "PRT"."PRTID"=165)
Access Path: index (AllEqJoinGuess)
Index: RPXIDXRECID
resc_io: 3.00 resc_cpu: 23984
ix_sel: 1.6577e-006 ix_sel_with_filters: 1.6577e-006
NL Join: Cost: 835.02 Resp: 835.02 Degree: 1
Cost_io: 833.08 Cost_cpu: 58098995
Resp_io: 833.08 Resp_cpu: 58098995
Access Path: index (RangeScan)
Index: URPXRECPERTYPE
resc_io: 3.00 resc_cpu: 23274
ix_sel: 1.6577e-006 ix_sel_with_filters: 9.4822e-007
NL Join: Cost: 835.02 Resp: 835.02 Degree: 1
Cost_io: 833.08 Cost_cpu: 58181005
Resp_io: 833.08 Resp_cpu: 58181005
****** trying bitmap/domain indexes ******
****** finished trying bitmap/domain indexes ******
Best NL cost: 835.02
resc: 835.02 resc_io: 833.08 resc_cpu: 58098995
resp: 835.02 resp_io: 833.08 resp_cpu: 58098995
Join Card: 378.67 = outer (238.38) * inner (835508.80) * sel (1.9013e-006)
Join Card - Rounded: 379 Computed: 378.67
SM Join
Outer table:
resc: 341.81 card 238.38 bytes: 83 deg: 1 resp: 341.81
Inner table: XSVRECPERXREF Alias: X
resc: 1180.68 card: 835508.80 bytes: 17 deg: 1 resp: 1180.68
using dmeth: 2 #groups: 1
SORT resource Sort statistics
Sort width: 445 Area size: 390144 Max Area size: 78223360
Degree: 1
Blocks to Sort: 3 Row size: 102 Total Rows: 238
Initial runs: 1 Merge passes: 0 IO Cost / pass: 0
Total IO sort cost: 0 Total CPU sort cost: 30061009
Total Temp space used: 0
SORT resource Sort statistics
Sort width: 445 Area size: 390144 Max Area size: 78223360
Degree: 1
Blocks to Sort: 2967 Row size: 29 Total Rows: 835509
Initial runs: 2 Merge passes: 1 IO Cost / pass: 1608
Total IO sort cost: 4575 Total CPU sort cost: 843575684
Total Temp space used: 53699000
SM join: Resc: 6126.64 Resp: 6126.64 [multiMatchCost=0.00]
SM cost: 6126.64
resc: 6126.64 resc_io: 6074.00 resc_cpu: 1577856809
resp: 6126.64 resp_io: 6074.00 resp_cpu: 1577856809
HA Join
Outer table:
resc: 341.81 card 238.38 bytes: 83 deg: 1 resp: 341.81
Inner table: XSVRECPERXREF Alias: X
resc: 1180.68 card: 835508.80 bytes: 17 deg: 1 resp: 1180.68
using dmeth: 2 #groups: 1
Cost per ptn: 3.29 #ptns: 1
hash_area: 124 (max=19098) buildfrag: 3 probefrag: 2958 ppasses: 1
Hash join: Resc: 1525.78 Resp: 1525.78 [multiMatchCost=0.00]
HA cost: 1525.78
resc: 1525.78 resc_io: 1499.00 resc_cpu: 802794893
resp: 1525.78 resp_io: 1499.00 resp_cpu: 802794893
Best:: JoinMethod: NestedLoop
Cost: 835.02 Degree: 1 Resp: 835.02 Card: 378.67 Bytes: 100
Now joining: PERPERSON[PER]#0
NL Join
Outer table: Card: 378.67 Cost: 835.02 Resp: 835.02 Degree: 1 Bytes: 100
Inner table: PERPERSON Alias: PER
Access Path: TableScan
NL Join: Cost: 409701.78 Resp: 409701.78 Degree: 1
Cost_io: 408070.08 Cost_cpu: 48912477468
Resp_io: 408070.08 Resp_cpu: 48912477468
Access Path: index (UniqueScan)
Index: PKPER
resc_io: 2.00 resc_cpu: 16603
ix_sel: 2.7682e-006 ix_sel_with_filters: 2.7682e-006
NL Join: Cost: 1593.23 Resp: 1593.23 Degree: 1
Cost_io: 1591.08 Cost_cpu: 64391486
Resp_io: 1591.08 Resp_cpu: 64391486
Access Path: index (AllEqJoin)
Index: PERIDXAGNEXTID
resc_io: 2.00 resc_cpu: 15703
ix_sel: 0.001065 ix_sel_with_filters: 0.001065
NL Join: Cost: 1593.22 Resp: 1593.22 Degree: 1
Cost_io: 1591.08 Cost_cpu: 64050386
Resp_io: 1591.08 Resp_cpu: 64050386
Access Path: index (AllEqUnique)
Index: PKPER
resc_io: 2.00 resc_cpu: 16603
ix_sel: 2.7682e-006 ix_sel_with_filters: 2.7682e-006
NL Join: Cost: 1593.23 Resp: 1593.23 Degree: 1
Cost_io: 1591.08 Cost_cpu: 64391486
Resp_io: 1591.08 Resp_cpu: 64391486
****** trying bitmap/domain indexes ******
Access Path: index (AllEqJoin)
Index: PERIDXAGNEXTID
resc_io: 1.00 resc_cpu: 8171
ix_sel: 0.001065 ix_sel_with_filters: 0.001065
NL Join: Cost: 1214.12 Resp: 1214.12 Degree: 1
Cost_io: 1212.08 Cost_cpu: 61195971
Resp_io: 1212.08 Resp_cpu: 61195971
Access Path: index (AllEqUnique)
Index: PKPER
resc_io: 1.00 resc_cpu: 9021
ix_sel: 2.7682e-006 ix_sel_with_filters: 2.7682e-006
NL Join: Cost: 1214.13 Resp: 1214.13 Degree: 1
Cost_io: 1212.08 Cost_cpu: 61518121
Resp_io: 1212.08 Resp_cpu: 61518121
Access path: Bitmap index - rejected
Cost: 3293.30 Cost_io: 3287.25 Cost_cpu: 181295210 Sel: 9.5086e-007
Not believed to be index-only
****** finished trying bitmap/domain indexes ******
Best NL cost: 1593.22
resc: 1593.22 resc_io: 1591.08 resc_cpu: 64050386
resp: 1593.22 resp_io: 1591.08 resp_cpu: 64050386
Join Card: 0.34 = outer (378.67) * inner (1.00) * sel (8.9286e-004)
Join Card - Rounded: 1 Computed: 0.34
SM Join
Outer table:
resc: 835.02 card 378.67 bytes: 100 deg: 1 resp: 835.02
Inner table: PERPERSON Alias: PER
resc: 2.00 card: 1.00 bytes: 29 deg: 1 resp: 2.00
using dmeth: 2 #groups: 1
SORT resource Sort statistics
Sort width: 445 Area size: 390144 Max Area size: 78223360
Degree: 1
Blocks to Sort: 6 Row size: 120 Total Rows: 379
Initial runs: 1 Merge passes: 0 IO Cost / pass: 0
Total IO sort cost: 0 Total CPU sort cost: 30122624
Total Temp space used: 0
SORT resource Sort statistics
Sort width: 445 Area size: 390144 Max Area size: 78223360
Degree: 1
Blocks to Sort: 1 Row size: 42 Total Rows: 1
Initial runs: 1 Merge passes: 0 IO Cost / pass: 0
Total IO sort cost: 0 Total CPU sort cost: 29976353
Total Temp space used: 0
SM join: Resc: 839.02 Resp: 839.02 [multiMatchCost=0.00]
SM cost: 839.02
resc: 839.02 resc_io: 835.08 resc_cpu: 118213674
resp: 839.02 resp_io: 835.08 resp_cpu: 118213674
HA Join
Outer table:
resc: 835.02 card 378.67 bytes: 100 deg: 1 resp: 835.02
Inner table: PERPERSON Alias: PER
resc: 2.00 card: 1.00 bytes: 29 deg: 1 resp: 2.00
using dmeth: 2 #groups: 1
Cost per ptn: 0.50 #ptns: 1
hash_area: 124 (max=19098) buildfrag: 6 probefrag: 1 ppasses: 1
Hash join: Resc: 837.52 Resp: 837.52 [multiMatchCost=0.00]
HA Join (swap)
Outer table:
resc: 2.00 card 1.00 bytes: 29 deg: 1 resp: 2.00
Inner table: XSVRECPERXREF Alias: X
resc: 835.02 card: 378.67 bytes: 100 deg: 1 resp: 835.02
using dmeth: 2 #groups: 1
Cost per ptn: 0.50 #ptns: 1
hash_area: 124 (max=19098) buildfrag: 1 probefrag: 6 ppasses: 1
Hash join: Resc: 837.52 Resp: 837.52 [multiMatchCost=0.00]
HA cost: 837.52
resc: 837.52 resc_io: 835.08 resc_cpu: 73140924
resp: 837.52 resp_io: 835.08 resp_cpu: 73140924
Best:: JoinMethod: Hash
Cost: 837.52 Degree: 1 Resp: 837.52 Card: 0.34 Bytes: 129
Now joining: ADTCASE[C]#6
NL Join
Outer table: Card: 0.34 Cost: 837.52 Resp: 837.52 Degree: 1 Bytes: 129
Inner table: ADTCASE Alias: C
Access Path: TableScan
NL Join: Cost: 6458.89 Resp: 6458.89 Degree: 1
Cost_io: 6414.08 Cost_cpu: 1343349671
Resp_io: 6414.08 Resp_cpu: 1343349671
Access Path: index (UniqueScan)
Index: PK_ADTCASE
resc_io: 2.00 resc_cpu: 16573
ix_sel: 3.9499e-007 ix_sel_with_filters: 3.9499e-007
NL Join: Cost: 839.52 Resp: 839.52 Degree: 1
Cost_io: 837.08 Cost_cpu: 73157497
Resp_io: 837.08 Resp_cpu: 73157497
Access Path: index (AllEqUnique)
Index: PK_ADTCASE
resc_io: 2.00 resc_cpu: 16573
ix_sel: 3.9478e-007 ix_sel_with_filters: 3.9478e-007
NL Join: Cost: 839.52 Resp: 839.52 Degree: 1
Cost_io: 837.08 Cost_cpu: 73157497
Resp_io: 837.08 Resp_cpu: 73157497
****** trying bitmap/domain indexes ******
****** finished trying bitmap/domain indexes ******
Best NL cost: 839.52
resc: 839.52 resc_io: 837.08 resc_cpu: 73157497
resp: 839.52 resp_io: 837.08 resp_cpu: 73157497
Join Card: 0.34 = outer (0.34) * inner (2531689.00) * sel (3.9478e-007)
Join Card - Rounded: 1 Computed: 0.34
SM Join
Outer table:
resc: 837.52 card 0.34 bytes: 129 deg: 1 resp: 837.52
Inner table: ADTCASE Alias: C
resc: 5621.37 card: 2531689.00 bytes: 34 deg: 1 resp: 5621.37
using dmeth: 2 #groups: 1
SORT resource Sort statistics
Sort width: 445 Area size: 390144 Max Area size: 78223360
Degree: 1
Blocks to Sort: 1 Row size: 152 Total Rows: 1
Initial runs: 1 Merge passes: 0 IO Cost / pass: 0
Total IO sort cost: 0 Total CPU sort cost: 29976353
Total Temp space used: 0
SORT resource Sort statistics
Sort width: 445 Area size: 390144 Max Area size: 78223360
Degree: 1
Blocks to Sort: 14878 Row size: 48 Total Rows: 2531689
Initial runs: 2 Merge passes: 1 IO Cost / pass: 8060
Total IO sort cost: 22938 Total CPU sort cost: 2822696818
Total Temp space used: 264217000
SM join: Resc: 29492.06 Resp: 29492.06 [multiMatchCost=0.00]
SM cost: 29492.06
resc: 29492.06 resc_io: 29352.08 resc_cpu: 4196022842
resp: 29492.06 resp_io: 29352.08 resp_cpu: 4196022842
HA Join
Outer table:
resc: 837.52 card 0.34 bytes: 129 deg: 1 resp: 837.52
Inner table: ADTCASE Alias: C
resc: 5621.37 card: 2531689.00 bytes: 34 deg: 1 resp: 5621.37
using dmeth: 2 #groups: 1
Cost per ptn: 8.95 #ptns: 1
hash_area: 124 (max=19098) buildfrag: 1 probefrag: 14217 ppasses: 1
Hash join: Resc: 6467.84 Resp: 6467.84 [multiMatchCost=0.00]
HA cost: 6467.84
resc: 6467.84 resc_io: 6414.08 resc_cpu: 1611506897
resp: 6467.84 resp_io: 6414.08 resp_cpu: 1611506897
Best:: JoinMethod: NestedLoop
Cost: 839.52 Degree: 1 Resp: 839.52 Card: 0.34 Bytes: 163
Now joining: ADTPATIENT[P]#4
NL Join
Outer table: Card: 0.34 Cost: 839.52 Resp: 839.52 Degree: 1 Bytes: 163
Inner table: ADTPATIENT Alias: P
Access Path: TableScan
NL Join: Cost: 2172.07 Resp: 2172.07 Degree: 1
Cost_io: 2161.08 Cost_cpu: 329395913
Resp_io: 2161.08 Resp_cpu: 329395913
Access Path: index (UniqueScan)
Index: PK_ADTPATIENT
resc_io: 2.00 resc_cpu: 16533
ix_sel: 1.8294e-006 ix_sel_with_filters: 1.8294e-006
NL Join: Cost: 841.52 Resp: 841.52 Degree: 1
Cost_io: 839.08 Cost_cpu: 73174030
Resp_io: 839.08 Resp_cpu: 73174030
Access Path: index (AllEqUnique)
Index: PK_ADTPATIENT
resc_io: 2.00 resc_cpu: 16533
ix_sel: 1.8294e-006 ix_sel_with_filters: 1.8294e-006
NL Join: Cost: 841.52 Resp: 841.52 Degree: 1
Cost_io: 839.08 Cost_cpu: 73174030
Resp_io: 839.08 Resp_cpu: 73174030
****** trying bitmap/domain indexes ******
****** finished trying bitmap/domain indexes ******
Best NL cost: 841.52
resc: 841.52 resc_io: 839.08 resc_cpu: 73174030
resp: 841.52 resp_io: 839.08 resp_cpu: 73174030
Join Card: 0.34 = outer (0.34) * inner (546621.00) * sel (1.8294e-006)
Join Card - Rounded: 1 Computed: 0.34
SM Join
Outer table:
resc: 839.52 card 0.34 bytes: 163 deg: 1 resp: 839.52
Inner table: ADTPATIENT Alias: P
resc: 1332.55 card: 546621.00 bytes: 41 deg: 1 resp: 1332.55
using dmeth: 2 #groups: 1
SORT resource Sort statistics
Sort width: 445 Area size: 390144 Max Area size: 78223360
Degree: 1
Blocks to Sort: 1 Row size: 190 Total Rows: 1
Initial runs: 1 Merge passes: 0 IO Cost / pass: 0
Total IO sort cost: 0 Total CPU sort cost: 29976353
Total Temp space used: 0
SORT resource Sort statistics
Sort width: 445 Area size: 390144 Max Area size: 78223360
Degree: 1
Blocks to Sort: 3748 Row size: 56 Total Rows: 546621
Initial runs: 2 Merge passes: 1 IO Cost / pass: 2032
Total IO sort cost: 5780 Total CPU sort cost: 591684408
Total Temp space used: 65872000
SM join: Resc: 7972.81 Resp: 7972.81 [multiMatchCost=0.00]
SM cost: 7972.81
resc: 7972.81 resc_io: 7941.08 resc_cpu: 951056673
resp: 7972.81 resp_io: 7941.08 resp_cpu: 951056673
HA Join
Outer table:
resc: 839.52 card 0.34 bytes: 163 deg: 1 resp: 839.52
Inner table: ADTPATIENT Alias: P
resc: 1332.55 card: 546621.00 bytes: 41 deg: 1 resp: 1332.55
using dmeth: 2 #groups: 1
Cost per ptn: 2.32 #ptns: 1
hash_area: 124 (max=19098) buildfrag: 1 probefrag: 3537 ppasses: 1
Hash join: Resc: 2174.39 Resp: 2174.39 [multiMatchCost=0.00]
HA cost: 2174.39
resc: 2174.39 resc_io: 2161.08 resc_cpu: 399046339
resp: 2174.39 resp_io: 2161.08 resp_cpu: 399046339
Plan cardinality mismatch: best card= 0.33796097408 curr card= 0.33791727990
Best:: JoinMethod: NestedLoop
Cost: 841.52 Degree: 1 Resp: 841.52 Card: 0.34 Bytes: 204
Best so far: Table#: 1 cost: 2.0007 card: 2.0000 bytes: 22
Table#: 3 cost: 338.3037 card: 1048.8517 bytes: 73430
Table#: 2 cost: 341.8088 card: 238.3754 bytes: 19754
Table#: 5 cost: 835.0191 card: 378.6697 bytes: 37900
Table#: 0 cost: 837.5209 card: 0.3381 bytes: 129
Table#: 6 cost: 839.5214 card: 0.3379 bytes: 163
Table#: 4 cost: 841.5220 card: 0.3379 bytes: 204
tage -
In a SQL query whihc has join, How to reduce Multiple instance of a table
in a SQL query which has join, How to reduce Multiple instance of a table
Here is an example: I am using Oracle 9i
is there a way to reduce no.of Person instances from the following query? or can I optimize this query further?
TABLES:
mail_table
mail_id, from_person_id, to_person_id, cc_person_id, subject, body
person_table
person_id, name, email
QUERY:
SELECT p_from.name from, p_to.name to, p_cc.name cc, subject
FROM mail, person p_from, person p_to, person p_cc
WHERE from_person_id = p_from.person_id
AND to_person_id = p_to.person_id
AND cc_person_id = p_cc.person_id
Thnanks in advance,
Babu.SQL> select * from mail;
ID F T CC
1 1 2 3
SQL> select * from person;
PID NAME
1 a
2 b
3 c
--Query with only ne Instance of PERSON Table
SQL> select m.id,max(decode(m.f,p.pid,p.name)) frm_name,
2 max(decode(m.t,p.pid,p.name)) to_name,
3 max(decode(m.cc,p.pid,p.name)) cc_name
4 from mail m,person p
5 where m.f = p.pid
6 or m.t = p.pid
7 or m.cc = p.pid
8 group by m.id;
ID FRM_NAME TO_NAME CC_NAME
1 a b c
--Expalin plan for "One instance" Query
SQL> explain plan for
2 select m.id,max(decode(m.f,p.pid,p.name)) frm_name,
3 max(decode(m.t,p.pid,p.name)) to_name,
4 max(decode(m.cc,p.pid,p.name)) cc_name
5 from mail m,person p
6 where m.f = p.pid
7 or m.t = p.pid
8 or m.cc = p.pid
9 group by m.id;
Explained.
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 902563036
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 3 | 216 | 7 (15)| 00:00:01 |
| 1 | HASH GROUP BY | | 3 | 216 | 7 (15)| 00:00:01 |
| 2 | NESTED LOOPS | | 3 | 216 | 6 (0)| 00:00:01 |
| 3 | TABLE ACCESS FULL| MAIL | 1 | 52 | 3 (0)| 00:00:01 |
|* 4 | TABLE ACCESS FULL| PERSON | 3 | 60 | 3 (0)| 00:00:01 |
PLAN_TABLE_OUTPUT
Predicate Information (identified by operation id):
4 - filter("M"."F"="P"."PID" OR "M"."T"="P"."PID" OR
"M"."CC"="P"."PID")
Note
- dynamic sampling used for this statement
--Explain plan for "Normal" query
SQL> explain plan for
2 select m.id,pf.name fname,pt.name tname,pcc.name ccname
3 from mail m,person pf,person pt,person pcc
4 where m.f = pf.pid
5 and m.t = pt.pid
6 and m.cc = pcc.pid;
Explained.
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 4145845855
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 112 | 14 (15)| 00:00:01 |
|* 1 | HASH JOIN | | 1 | 112 | 14 (15)| 00:00:01 |
|* 2 | HASH JOIN | | 1 | 92 | 10 (10)| 00:00:01 |
|* 3 | HASH JOIN | | 1 | 72 | 7 (15)| 00:00:01 |
| 4 | TABLE ACCESS FULL| MAIL | 1 | 52 | 3 (0)| 00:00:01 |
| 5 | TABLE ACCESS FULL| PERSON | 3 | 60 | 3 (0)| 00:00:01 |
PLAN_TABLE_OUTPUT
| 6 | TABLE ACCESS FULL | PERSON | 3 | 60 | 3 (0)| 00:00:01 |
| 7 | TABLE ACCESS FULL | PERSON | 3 | 60 | 3 (0)| 00:00:01 |
Predicate Information (identified by operation id):
1 - access("M"."CC"="PCC"."PID")
2 - access("M"."T"="PT"."PID")
3 - access("M"."F"="PF"."PID")
PLAN_TABLE_OUTPUT
Note
- dynamic sampling used for this statement
25 rows selected.
Message was edited by:
jeneesh
No indexes created... -
End of file on communication channel when doing a (hash) join
I'm having a problem with a simple join between two tables (hash join, from the explain), one containing about 650k rows, the other 730k.
The query runs fine until I add to the select list a geometry field (oracle spatial). In that case I receive an end-of-file error, which seems to be caused by a memory saturation. I'm not sure about this, as I can't understand the trace very well...
I've increased the pga_aggregate_target and the pgamax_size but this have little effects on the problem...
Any hint? Could it be caused by the geometry field size?
thanks,
giovanniThanks for the quick reply. Here it is what you asked:
select from v$version;*
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Prod
PL/SQL Release 10.2.0.4.0 - Production
"CORE 10.2.0.4.0 Production"
TNS for 32-bit Windows: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production
an excerpt from the trace file:
*** ACTION NAME:() 2010-04-16 12:48:17.796
*** MODULE NAME:(SQL*Plus) 2010-04-16 12:48:17.796
*** SERVICE NAME:(ABRUZZO) 2010-04-16 12:48:17.796
*** SESSION ID:(149.10) 2010-04-16 12:48:17.796
*** 2010-04-16 12:48:17.796
ksedmp: internal or fatal error
ORA-07445: trovata eccezione: dump della memoria [ACCESS_VIOLATION] [_kokekd2m+24] [PC:0x11CF9E0] [ADDR:0xBA8C193C] [UNABLE_TO_READ] []
Current SQL statement for this session:
select g.cr375_idobj,g.cr375_geometria,t.cr374_codicectr,t.cr374_scarpt_cont
from DBTI.Cr374_Scarpata t, DBTI.Cr375g_a_Scarp g
where t.cr374_idobj=g.cr375_idobj
check trace file c:\oracle\product\10.2.0\db_1\rdbms\trace\abruzzo_ora_0.trc for preloading .sym file messages
----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)
_kokekd2m+24 00000000
kokeq2iro+178 CALLrel kokekd2m+0 99384C8 9937624 BA8C18D8
9968588 3660D954 3A52AC00
__VInfreq__rworupo+ CALLrel _kokeq2iro+0 9968218 A05C810 EA7
321
_kxhrUnpack+71 CALLreg 00000000 99693C8 A05C810 0 9 0
qerhjWalkHashBucke CALLrel kxhrUnpack+0 9967DD0 99693C8 9 A05C810 0
t+210
__PGOSF352__qerhjIn CALLrel _qerhjWalkHashBucke A05CED4 99693C0 8
nerProbeHashTable+4 t+0
78
_kdstf0000101km+230 CALLreg 00000000
kdsttgr+1263 CALLrel kdstf0000101km+0 -
Hash join ending up in huge wait events
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.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 -
HASH JOIN Issue - query performance issue
Hello friends:
I have a nested loop long query. When i execute this on Oracle 9i, the results comes back within no time (less than a sec) but the same query, same schema, the query takes over 20-30secs. Looking at the execution plan (pasted below) - the Oracle 10g is using HASH JOIN compared to NESTED LOOPS (Oracle 9i). The cost on 9i is much less than 10g due to the hash join form 10g --
Here's the explain plan for -- How do i make 10g plan to use the one from 9i--the nested loop?
Oracle 10g:
SORT(AGGREGATE) 1 33
HASH JOIN 25394 2082 68706
MAT_VIEW ACCESS(FULL) GMDB.NODE_ATTRIBUTES ANALYZED 17051 2082 56214
VIEW 8318 1714180 10285080
FILTER
CONNECT BY(WITH FILTERING)
Oracle 9i--
SORT(AGGREGATE) 1 40
NESTED LOOPS 166 65 2600
VIEW 36 65 845
FILTERjust noticed the "CONNECT BY" in the plan. connect by queries are special cases, should you should spell that out loud and clear for us next time. anyway, lots of problems in v10 with connect by:
metalink Note:394358.1
CONNECT BY SQL uses Full Table Scan In 10.2.0.2 - Used Index In earlier versions
solution:
alter session set "_optimizer_connect_by_cost_based"=false;
and bugs related to connect by fixed in the 10.2.0.2 release (other than the bug from the note bug, which was introduced):
metalink Note:358749.1
and
Note:3956141.8
OR filter in CONNECT BY query may be applied at table level (v 10.1.0.3) -
Hi everyone,
Version :- 10.1.0.5.0
Below is the query and it takes long time to execute due to hash joins. Is there ant other way to change change the join approach or rewrite the SQL.
Tables used
rhs_premium :- 830 GB with partitons.
bu_res_line_map :- small table 4 MB
mgt_unit_res_line_map :- small table with 4 MB
mgt_unit_reserving_lines :- View
bu_reserving_lines :- View
SELECT prem.business_unit,
prem.direct_assumed_ceded_code,
prem.ledger_currency_code,
prem.mcc_code,
prem.management_unit,
prem.product,
prem.financial_product,
nvl(prem.premium_in_ledger_currency,0) premium_in_ledger_currency, -- NVL added Aug 21, 2008
nvl(prem.premium_in_original_currency,0) premium_in_original_currency, -- Added Aug 21, 2008 M4640
nvl(prem.premium_in_us_dollars,0) premium_in_us_dollars, -- NVL added Aug 21, 2008
prem.rcc,
prem.pre_explosion_rcc, -- Issue M1997 Laks 09/15
prem.acc_code,
prem.transaction_code,
prem.accounting_period,
prem.exposure_period,
prem.policy_effective_month,
prem.policy_key,
prem.policy_line_of_business,
prem.producer_code,
prem.underwriting_year,
prem.ledger_key,
prem.account_key,
prem.policy_coverage_key,
nvl(prem.original_currency_code,' ') original_currency_code, -- NVL added Issue M4640 Aug 21, 2008
prem.authorized_unauthorized,
prem.transaction_effective_date,
prem.transaction_expiration_date,
prem.exposure_year,
prem.reinsurance_mask,
prem.rcccategory,
prem.rccclassification,
prem.detail_level_indicator,
prem.bermbase_level_indicator,
prem.padb_level_indicator,
prem.sas_level_indicator, -- Issue 443
prem.cnv_adjust_indicator, -- Issue 413
prem.originating_business_unit,
prem.actuarial_blend_indicator,
ml1.management_line_of_business_id management_lob_id_act,
mu1.reserving_line_id mgt_unit_reserving_lob_id_act,
bu1.reserving_line_id business_unit_lob_id_act,
ml1.reserving_class_id mgt_unit_res_class_lob_id_act, -- added A12
bl1.reserving_class_id business_unit_class_lob_id_act,-- added A12
ml2.management_line_of_business_id management_lob_id_fin,
mu2.reserving_line_id mgt_unit_reserving_lob_id_fin,
bu2.reserving_line_id business_unit_lob_id_fin,
ml2.reserving_class_id mgt_unit_res_class_lob_id_fin, -- added A12
bl2.reserving_class_id business_unit_class_lob_id_fin -- added A12
FROM rhs_premium prem,
bu_res_line_map bu1,
mgt_unit_res_line_map mu1,
mgt_unit_reserving_lines ml1,
bu_reserving_lines bl1, -- added A12
bu_res_line_map bu2,
mgt_unit_res_line_map mu2,
mgt_unit_reserving_lines ml2,
bu_reserving_lines bl2 -- added A12
WHERE ( prem.business_unit = bu1.business_unit (+)
AND prem.product = bu1.product (+)
AND ( prem.management_unit = mu1.management_unit (+)
AND prem.product = mu1.product(+)
AND mu1.reserving_line_id = ml1.reserving_line_id (+)
AND bu1.reserving_line_id = bl1.reserving_line_id (+) -- added A12
AND ( prem.business_unit = bu2.business_unit (+)
AND prem.financial_product = bu2.product (+)
AND ( prem.management_unit = mu2.management_unit (+)
AND prem.financial_product = mu2.product(+)
AND mu2.reserving_line_id = ml2.reserving_line_id (+)
AND bu2.reserving_line_id = bl2.reserving_line_id (+);
PLAN_TABLE_OUTPUT
Plan hash value: 3475794837
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop | TQ |IN-OUT| PQ Distrib |
| 0 | SELECT STATEMENT | | 346M| 124G| 416K (2)| 01:37:13 | | | | | |
| 1 | PX COORDINATOR | | | | | | | | | | |
| 2 | PX SEND QC (RANDOM) | :TQ10008 | 346M| 124G| 416K (2)| 01:37:13 | | | Q1,08 | P->S | QC (RAND) |
|* 3 | HASH JOIN RIGHT OUTER | | 346M| 124G| 416K (2)| 01:37:13 | | | Q1,08 | PCWP | |
| 4 | BUFFER SORT | | | | | | | | Q1,08 | PCWC | |
| 5 | PX RECEIVE | | 46 | 1196 | 7 (0)| 00:00:01 | | | Q1,08 | PCWP | |
| 6 | PX SEND BROADCAST | :TQ10000 | 46 | 1196 | 7 (0)| 00:00:01 | | | | S->P | BROADCAST |
| 7 | VIEW | BU_RESERVING_LINES | 46 | 1196 | 7 (0)| 00:00:01 | | | | | |
| 8 | NESTED LOOPS OUTER | | 46 | 1748 | 7 (0)| 00:00:01 | | | | | |
|* 9 | TABLE ACCESS FULL | RESERVING_LINES | 46 | 1564 | 7 (0)| 00:00:01 | | | | | |
|* 10 | INDEX UNIQUE SCAN | RESERVING_CLASSES_PK | 1 | 4 | 0 (0)| 00:00:01 | | | | | |
|* 11 | HASH JOIN RIGHT OUTER | | 346M| 116G| 415K (2)| 01:37:04 | | | Q1,08 | PCWP | |
| 12 | BUFFER SORT | | | | | | | | Q1,08 | PCWC | |
| 13 | PX RECEIVE | | 124K| 2182K| 87 (2)| 00:00:02 | | | Q1,08 | PCWP | |
| 14 | PX SEND BROADCAST | :TQ10001 | 124K| 2182K| 87 (2)| 00:00:02 | | | | S->P | BROADCAST |
| 15 | TABLE ACCESS FULL | BU_RES_LINE_MAP | 124K| 2182K| 87 (2)| 00:00:02 | | | | | |
|* 16 | HASH JOIN RIGHT OUTER | | 346M| 110G| 415K (2)| 01:36:54 | | | Q1,08 | PCWP | |
| 17 | BUFFER SORT | | | | | | | | Q1,08 | PCWC | |
| 18 | PX RECEIVE | | 46 | 1196 | 7 (0)| 00:00:01 | | | Q1,08 | PCWP | |
| 19 | PX SEND BROADCAST | :TQ10002 | 46 | 1196 | 7 (0)| 00:00:01 | | | | S->P | BROADCAST |
| 20 | VIEW | BU_RESERVING_LINES | 46 | 1196 | 7 (0)| 00:00:01 | | | | | |
| 21 | NESTED LOOPS OUTER | | 46 | 1748 | 7 (0)| 00:00:01 | | | | | |
|* 22 | TABLE ACCESS FULL | RESERVING_LINES | 46 | 1564 | 7 (0)| 00:00:01 | | | | | |
|* 23 | INDEX UNIQUE SCAN | RESERVING_CLASSES_PK | 1 | 4 | 0 (0)| 00:00:01 | | | | | |
|* 24 | HASH JOIN RIGHT OUTER | | 346M| 101G| 414K (1)| 01:36:45 | | | Q1,08 | PCWP | |
| 25 | BUFFER SORT | | | | | | | | Q1,08 | PCWC | |
| 26 | PX RECEIVE | | 124K| 2182K| 87 (2)| 00:00:02 | | | Q1,08 | PCWP | |
| 27 | PX SEND BROADCAST | :TQ10003 | 124K| 2182K| 87 (2)| 00:00:02 | | | | S->P | BROADCAST |
| 28 | TABLE ACCESS FULL | BU_RES_LINE_MAP | 124K| 2182K| 87 (2)| 00:00:02 | | | | | |
|* 29 | HASH JOIN RIGHT OUTER | | 346M| 96G| 413K (1)| 01:36:35 | | | Q1,08 | PCWP | |
| 30 | BUFFER SORT | | | | | | | | Q1,08 | PCWC | |
| 31 | PX RECEIVE | | 46 | 1794 | 11 (10)| 00:00:01 | | | Q1,08 | PCWP | |
| 32 | PX SEND BROADCAST | :TQ10004 | 46 | 1794 | 11 (10)| 00:00:01 | | | | S->P | BROADCAST |
| 33 | VIEW | MGT_UNIT_RESERVING_LINES | 46 | 1794 | 11 (10)| 00:00:01 | | | | | |
|* 34 | HASH JOIN OUTER | | 46 | 1886 | 11 (10)| 00:00:01 | | | | | |
|* 35 | TABLE ACCESS FULL | RESERVING_LINES | 46 | 1564 | 7 (0)| 00:00:01 | | | | | |
| 36 | TABLE ACCESS FULL | RESERVING_CLASSES | 107 | 749 | 3 (0)| 00:00:01 | | | | | |
|* 37 | HASH JOIN RIGHT OUTER | | 346M| 83G| 413K (1)| 01:36:26 | | | Q1,08 | PCWP | |
| 38 | BUFFER SORT | | | | | | | | Q1,08 | PCWC | |
| 39 | PX RECEIVE | | 93763 | 1648K| 59 (0)| 00:00:01 | | | Q1,08 | PCWP | |
| 40 | PX SEND BROADCAST | :TQ10005 | 93763 | 1648K| 59 (0)| 00:00:01 | | | | S->P | BROADCAST |
| 41 | INDEX FAST FULL SCAN | MGT_UNIT_RES_LINE_MAP_UK | 93763 | 1648K| 59 (0)| 00:00:01 | | | | | |
|* 42 | HASH JOIN RIGHT OUTER | | 346M| 77G| 412K (1)| 01:36:17 | | | Q1,08 | PCWP | |
| 43 | BUFFER SORT | | | | | | | | Q1,08 | PCWC | |
| 44 | PX RECEIVE | | 46 | 1794 | 11 (10)| 00:00:01 | | | Q1,08 | PCWP | |
| 45 | PX SEND BROADCAST | :TQ10006 | 46 | 1794 | 11 (10)| 00:00:01 | | | | S->P | BROADCAST |
| 46 | VIEW | MGT_UNIT_RESERVING_LINES | 46 | 1794 | 11 (10)| 00:00:01 | | | | | |
|* 47 | HASH JOIN OUTER | | 46 | 1886 | 11 (10)| 00:00:01 | | | | | |
|* 48 | TABLE ACCESS FULL | RESERVING_LINES | 46 | 1564 | 7 (0)| 00:00:01 | | | | | |
| 49 | TABLE ACCESS FULL | RESERVING_CLASSES | 107 | 749 | 3 (0)| 00:00:01 | | | | | |
|* 50 | HASH JOIN RIGHT OUTER | | 346M| 65G| 411K (1)| 01:36:08 | | | Q1,08 | PCWP | |
| 51 | BUFFER SORT | | | | | | | | Q1,08 | PCWC | |
| 52 | PX RECEIVE | | 93763 | 1648K| 59 (0)| 00:00:01 | | | Q1,08 | PCWP | |
| 53 | PX SEND BROADCAST | :TQ10007 | 93763 | 1648K| 59 (0)| 00:00:01 | | | | S->P | BROADCAST |
| 54 | INDEX FAST FULL SCAN| MGT_UNIT_RES_LINE_MAP_UK | 93763 | 1648K| 59 (0)| 00:00:01 | | | | | |
| 55 | PX BLOCK ITERATOR | | 346M| 59G| 411K (1)| 01:35:58 | 1 | 385 | Q1,08 | PCWC | |
| 56 | TABLE ACCESS FULL | RHS_PREMIUM_1 | 346M| 59G| 411K (1)| 01:35:58 | 1 | 385 | Q1,08 | PCWP | |
Predicate Information (identified by operation id):
3 - access("BU2"."RESERVING_LINE_ID"="BL2"."RESERVING_LINE_ID"(+))
9 - filter("RL"."RESERVING_LINE_TYPE"='BU')
10 - access("RL"."RESERVING_CLASS_ID"="RC"."RESERVING_CLASS_ID"(+))
11 - access("PREM"."BUSINESS_UNIT"="BU2"."BUSINESS_UNIT"(+) AND "PREM"."FINANCIAL_PRODUCT"="BU2"."PRODUCT"(+))
16 - access("BU1"."RESERVING_LINE_ID"="BL1"."RESERVING_LINE_ID"(+))
22 - filter("RL"."RESERVING_LINE_TYPE"='BU')
23 - access("RL"."RESERVING_CLASS_ID"="RC"."RESERVING_CLASS_ID"(+))
24 - access("PREM"."BUSINESS_UNIT"="BU1"."BUSINESS_UNIT"(+) AND "PREM"."PRODUCT"="BU1"."PRODUCT"(+))
29 - access("MU2"."RESERVING_LINE_ID"="ML2"."RESERVING_LINE_ID"(+))
34 - access("RL"."RESERVING_CLASS_ID"="RC"."RESERVING_CLASS_ID"(+))
35 - filter("RL"."RESERVING_LINE_TYPE"='MCC')
37 - access("PREM"."MANAGEMENT_UNIT"="MU2"."MANAGEMENT_UNIT"(+) AND "PREM"."FINANCIAL_PRODUCT"="MU2"."PRODUCT"(+))
42 - access("MU1"."RESERVING_LINE_ID"="ML1"."RESERVING_LINE_ID"(+))
47 - access("RL"."RESERVING_CLASS_ID"="RC"."RESERVING_CLASS_ID"(+))
48 - filter("RL"."RESERVING_LINE_TYPE"='MCC')
50 - access("PREM"."MANAGEMENT_UNIT"="MU1"."MANAGEMENT_UNIT"(+) AND "PREM"."PRODUCT"="MU1"."PRODUCT"(+))Please let me know if there is any possibilty.
Regards,
SandyBig query - 9 tables, outer joins, parallel query option. Reading/joining views - steps 7, 20, etc?
if you are reading most of the rows in both tables then hash joins are probably the most efficient way to read the data. The parallel query option may or may not be helping.
Outer joins usually make queries slower. Views can also have th same effect, and will probably affect the execution plan.
If you are reading views you can eliminate them by using the base tables to see how that affects performance. You can change the session parameter for DB_FILE_MULTIBLOCK_READ COUNT for more efficient full table scans if its set (the documentation and blog articles claim leaving it unset in the database is the most efficient use).
Edited by: riedelme on Jun 6, 2011 8:26 AM -
Optimizer choosing hash joins even when slower
We have several queries where joins are being evaluated by full scans / hash joins even when forcing index use results in an execution time about a quarter the duration of the hash join plan. It still happens if I run DMS_STATS.GATHER_TABLE_STATS with FOR ALL COLUMNS.
Is there a stats gathering option which is more likely to result in an indexd join without having to get developers to put optimizer hints in their queries?
11g on SuSE 10.
Many thanks.user10400178 wrote:
That would require me to post a large amount of schema information as well to be of any added value.
Surely there are some general recommendations one could make as to how to allow the optimizer to realise that joining through an index is going to be quicker than doing a full scan and hash join to a table.If you don't want to post the plans, then as a first step you basically need to verify yourself if the cardinality estimates returned by the execution plan correspond roughly to the actual cardinalities.
E.g. in your execution plan there are steps like "FULL TABLE SCAN" and these operations likely have a corresponding "FILTER" predicate in the "Predicate Information" section below the plan.
As first step you should run simple count queries ("select count(*) from ... where <FILTER/ACCESS predicates>") on the tables involved using the "FILTER" and "ACCESS" predicates mentioned to compare if the returned number of rows is in the same ballpark than the estimates mentioned in the plan.
If these estimates are already way off then you know that for some reason the optimizer makes wrong assumptions and that's probably the reason why the suboptimal access pattern is preferred.
One potential reason could be correlated column values, but since you're already on 11g you could make use of extended column statistics. See here for more details:
http://download.oracle.com/docs/cd/B28359_01/server.111/b28274/stats.htm#BEIEEIJA
Another reason might simply that you're choosing a too low "estimate" sample size for the statistics collection. In 11g you should always use the DBMS_STATS.AUTO_SAMPLE_SIZE for the "estimate_percent" parameter of the DBMS_STATS.GATHER__STATS procedures. It should generate accurate statistics without the need to analyze all of the data. See here in Greg Rahn's blog for an example:
http://structureddata.org/2007/09/17/oracle-11g-enhancements-to-dbms_stats/
Regarding the histograms: Oracle 11g by default generates histograms if it deems them to be beneficial. It is controlled by the parameter "METHOD_OPT" which has the default value of "FOR ALL COLUMNS SIZE AUTO". The "SIZE" keyword determines the generation of histograms. You could use "SIZE 1" to prevent histogram generation, "SIZE <n>" to control the number of buckets to use for the histogram or "SIZE AUTO" to let Oracle decide itself when and how to generate histograms.
Regarding the stored outlines: You could have so called "stored outlines" that force the optimizer to stick to a certain plan. That features was introduced a long time ago and is sometimes also referred to as "plan stability", its main purpose was an attempt to smooth the transition from the rule based optimizer (RBO) to the cost based optimizer (CBO) introduced in Oracle 7 (although you can use it for other purposes, too, of course). Oracle 11g offers now the new "SQL plan management" feature that is supposed to supersede the "plan stability" feature. For more information, look here:
http://download.oracle.com/docs/cd/B28359_01/server.111/b28274/outlines.htm#PFGRF707
Regards,
Randolf
Oracle related stuff blog:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/
Edited by: Randolf Geist on Oct 16, 2008 4:20 PM
Sample size note added
Edited by: Randolf Geist on Oct 16, 2008 6:54 PM
Outline info added
Maybe you are looking for
-
I'm getting an error 1055 in the report generation - my Labview ver is 8.6.1 I don't know what to do here to resolve this I thank for your help. Dana Solved! Go to Solution. Attachments: err vi.png 71 KB
-
Best method for networking with ubuntu linux
Hi, I'm setting up an ubuntu linux fileserver, and I was wondering what the best method for filesharing with my mac is. I'm currently running osx 10.4.11, though I may be upgrading to 10.5 soon. I'll be running SMB networking for a couple of other co
-
Where are Plugins for Photoshop CS5?
There is no plugin on the CD:s.
-
My Itouch has been working fine, but after I hooked it up to my Xbox 360 in the USB port it wont turn on. The Xbox 360 will let you hook up your Ipod and listen, but I guess the new ipod dont work. Well after hooking it up it turned on and was chargi
-
How to efficiently select random rows from a large table ?
Hello, The following code will select 5 rows out of a random set of rows from the emp (employee) table select * from ( select ename, job from emp order by dbms_random.value() where rownum <= 5my concern is that the inner sele