Very different execution plan in Oracle 10g vs. 9i

Good afternoon,
A few days ago I migrated an Oracle database 9i to 10g.
Right now I have an exact copy of the 9i instance running on another machine.
I noticed that the time for some queries take much more. For example, when comparing the execution plan for this query on the instance with Oracle 9i and Oracle 10g instance, I see that the cost in 10g is 94981765382, while in 9i is 120106.
Any idea what might be happening?
Execution Plan Oracle 9: http://blog.davidlozanolucas.com/uploads/execution_plan_Oracle_9i.jpg
Execution Plan Oracle 10g: http://blog.davidlozanolucas.com/uploads/execution_plan_Oracle_10g.jpg
Edited by: david_lozano_lucas on Dec 14, 2011 4:54 PM

Sorry,
Here are the details.
For Oracle 9i:
PLAN_TABLE_OUTPUT
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Pstart| Pstop | TQ |IN-OUT| PQ Distrib |
| 0 | SELECT STATEMENT | | 16M| 3675M| | 120K (0)| | | | | |
|* 1 | FILTER | | | | | | | | | | |
|* 2 | HASH JOIN | | 16M| 3675M| | 120K (0)| | | 03,09 | P->S | QC (RAND) |
| 3 | TABLE ACCESS FULL | ORG_LOC_DM | 2261 | 13566 | | 8 (0)| | | 03,01 | S->P | HASH |
|* 4 | HASH JOIN OUTER | | 16M| 3582M| 1023M| 120K (0)| | | 03,08 | P->P | HASH |
|* 5 | HASH JOIN OUTER | | 16M| 2783M| 1041M| 102K (0)| | | 03,08 | PCWP | |
|* 6 | HASH JOIN OUTER | | 16M| 2521M| 715M| 69515 (0)| | | 03,08 | PCWP | |
| 7 | PARTITION RANGE ALL | | | | | | 1 | 14 | 03,08 | PCWP | |
| 8 | TABLE ACCESS FULL | SURT_SKU_LD_DM | 16M| 1922M| | 60988 (0)| 1 | 14 | 03,04 | P->P | HASH |
| 9 | VIEW | | 909K| 33M| | | | | 03,05 | P->P | HASH |
| 10 | SORT GROUP BY | | 909K| 19M| 62M| 1553 (0)| | | 03,05 | PCWP | |
|* 11 | HASH JOIN | | 909K| 19M| | 164 (0)| | | 03,05 | PCWP | |
|* 12 | TABLE ACCESS FULL| ORG_LOC_DM | 1131 | 6786 | | 8 (0)| | | 03,00 | S->P | HASH |
|* 13 | TABLE ACCESS FULL| INV_MOVE_SKU_LCM_DM | 909K| 13M| | 154 (0)| 60 | 60 | 03,02 | P->P | HASH |
|* 14 | TABLE ACCESS FULL | SURT_SKU_LCM_DM | 16M| 260M| | 6457 (0)| 59 | 59 | 03,06 | P->P | HASH |
| 15 | VIEW | | 1795K| 89M| | | | | 03,07 | P->P | HASH |
| 16 | SORT GROUP BY | | 1795K| 63M| 233M| 4565 (0)| | | 03,07 | PCWP | |
|* 17 | TABLE ACCESS FULL | SLS_SKU_LCM_DM | 1795K| 63M| | 599 (0)| 60 | 60 | 03,03 | P->P | HASH |
| 18 | NESTED LOOPS | | 1 | 16 | | 7 (15)| | | | | |
| 19 | TABLE ACCESS FULL | MAINT_LOAD_DT | 1 | 8 | | 1 (0)| | | | | |
|* 20 | INDEX RANGE SCAN | DAY_IDNT_I1 | 1 | 8 | | 1 (0)| | | | | |
Predicate Information (identified by operation id):
1 - filter("SYS_ALIAS_1"."DAY_IDNT"= (SELECT /*+ */ :B1 FROM "RDW91_DM"."MAINT_LOAD_DT" "Y","RDW91_DM"."TIME_DAY_DM" "X" WHERE
"X"."DAY_DT"="Y"."CURR_LOAD_DT"))
2 - access("SYS_ALIAS_1"."LOC_KEY"="G"."LOC_KEY")
4 - access("SYS_ALIAS_1"."LOC_KEY"="I"."LOC_KEY"(+) AND "SYS_ALIAS_1"."SKU_KEY"="I"."SKU_KEY"(+))
5 - access("SYS_ALIAS_1"."LOC_KEY"="B"."LOC_KEY"(+) AND "SYS_ALIAS_1"."SKU_KEY"="B"."SKU_KEY"(+))
6 - access("SYS_ALIAS_1"."LOC_KEY"="J"."LOC_KEY"(+) AND "SYS_ALIAS_1"."SKU_KEY"="J"."SKU_KEY"(+))
11 - access("A"."LOC_KEY"="B"."LOC_KEY")
12 - filter("B"."LOC_TYPE_CDE"='W')
13 - filter("A"."CMTH_IDNT"=201112)
14 - filter("B"."CMTH_IDNT"(+)=201111)
17 - filter("SLS_SKU_LCM_DM"."CMTH_IDNT"=201112)
20 - access("X"."DAY_DT"="Y"."CURR_LOAD_DT")
For 10g:
PLAN_TABLE_OUTPUT
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost | Pstart| Pstop | TQ |IN-OUT| PQ Distrib |
| 0 | SELECT STATEMENT | | 16M| 3685M| | 94G| | | | | |
| 1 | FILTER | | | | | | | | | | |
| 2 | PX COORDINATOR | | | | | | | | | | |
| 3 | PX SEND QC (RANDOM) | :TQ10008 | 16M| 3685M| | 94G| | | Q1,08 | P->S | QC (RAND) |
| 4 | BUFFER SORT | | 16M| 3685M| | | | | Q1,08 | PCWP | |
| 5 | NESTED LOOPS OUTER | | 16M| 3685M| | 94G| | | Q1,08 | PCWP | |
| 6 | HASH JOIN | | 16M| 3424M| | 201K| | | Q1,08 | PCWP | |
| 7 | BUFFER SORT | | | | | | | | Q1,08 | PCWC | |
| 8 | PX RECEIVE | | 2261 | 13566 | | 8 | | | Q1,08 | PCWP | |
| 9 | PX SEND HASH | :TQ10001 | 2261 | 13566 | | 8 | | | | S->P | HASH |
| 10 | TABLE ACCESS FULL | ORG_LOC_DM | 2261 | 13566 | | 8 | | | | | |
| 11 | PX RECEIVE | | 16M| 3332M| | 201K| | | Q1,08 | PCWP | |
| 12 | PX SEND HASH | :TQ10007 | 16M| 3332M| | 201K| | | Q1,07 | P->P | HASH |
| 13 | HASH JOIN OUTER BUFFERED | | 16M| 3332M| 982M| 201K| | | Q1,07 | PCWP | |
| 14 | HASH JOIN OUTER | | 16M| 2733M| 735M| 127K| | | Q1,07 | PCWP | |
| 15 | PX RECEIVE | | 16M| 1934M| | 75785 | | | Q1,07 | PCWP | |
| 16 | PX SEND HASH | :TQ10004 | 16M| 1934M| | 75785 | | | Q1,04 | P->P | HASH |
| 17 | PX BLOCK ITERATOR | | 16M| 1934M| | 75785 | 1 | 14 | Q1,04 | PCWC | |
| 18 | TABLE ACCESS FULL | SURT_SKU_LD_DM | 16M| 1934M| | 75785 | 1 | 14 | Q1,04 | PCWP | |
| 19 | PX RECEIVE | | 1450K| 71M| | 3892 | | | Q1,07 | PCWP | |
| 20 | PX SEND HASH | :TQ10005 | 1450K| 71M| | 3892 | | | Q1,05 | P->P | HASH |
| 21 | VIEW | | 1450K| 71M| | 3892 | | | Q1,05 | PCWP | |
| 22 | SORT GROUP BY | | 1450K| 53M| 188M| 3892 | | | Q1,05 | PCWP | |
| 23 | PX RECEIVE | | 1450K| 53M| | 562 | | | Q1,05 | PCWP | |
| 24 | PX SEND HASH | :TQ10002 | 1450K| 53M| | 562 | | | Q1,02 | P->P | HASH |
| 25 | PX BLOCK ITERATOR | | 1450K| 53M| | 562 | 60 | 60 | Q1,02 | PCWC | |
| 26 | MAT_VIEW ACCESS FULL| SLS_SKU_LCM_DM | 1450K| 53M| | 562 | 60 | 60 | Q1,02 | PCWP | |
| 27 | PX RECEIVE | | 652K| 24M| | 1150 | | | Q1,07 | PCWP | |
| 28 | PX SEND HASH | :TQ10006 | 652K| 24M| | 1150 | | | Q1,06 | P->P | HASH |
| 29 | VIEW | | 652K| 24M| | 1150 | | | Q1,06 | PCWP | |
| 30 | SORT GROUP BY | | 652K| 14M| | 1150 | | | Q1,06 | PCWP | |
| 31 | HASH JOIN | | 652K| 14M| | 128 | | | Q1,06 | PCWP | |
| 32 | BUFFER SORT | | | | | | | | Q1,06 | PCWC | |
| 33 | PX RECEIVE | | 1131 | 6786 | | 8 | | | Q1,06 | PCWP | |
| 34 | PX SEND HASH | :TQ10000 | 1131 | 6786 | | 8 | | | | S->P | HASH |
| 35 | TABLE ACCESS FULL | ORG_LOC_DM | 1131 | 6786 | | 8 | | | | | |
| 36 | PX RECEIVE | | 652K| 10M| | 118 | | | Q1,06 | PCWP | |
| 37 | PX SEND HASH | :TQ10003 | 652K| 10M| | 118 | | | Q1,03 | P->P | HASH |
| 38 | PX BLOCK ITERATOR | | 652K| 10M| | 118 | 60 | 60 | Q1,03 | PCWC | |
| 39 | MAT_VIEW ACCESS FULL| INV_MOVE_SKU_LCM_DM | 652K| 10M| | 118 | 60 | 60 | Q1,03 | PCWP | |
| 40 | PARTITION RANGE SINGLE | | 1 | 17 | | 8609 | 59 | 59 | Q1,08 | PCWP | |
| 41 | TABLE ACCESS FULL | SURT_SKU_LCM_DM | 1 | 17 | | 8609 | 59 | 59 | Q1,08 | PCWP | |
| 42 | NESTED LOOPS | | 1 | 16 | | 6 | | | | | |
| 43 | TABLE ACCESS FULL | MAINT_LOAD_DT | 1 | 8 | | 1 | | | | | |
| 44 | INDEX RANGE SCAN | DAY_IDNT_I1 | 1 | 8 | | 5 | | | | | |
Note
- 'PLAN_TABLE' is old version
- cpu costing is off (consider enabling it)

Similar Messages

Same Query returning different result (Different execution plan)

Hi all,
To day i have discovered a strange thing: a query that return a different result when using a different execution plan.
The query :
SELECT *
FROM schema.table@database a
WHERE     column1 IN ('3')
       AND column2 = '101'
       AND EXISTS
              (SELECT null
                 FROM schema.table2 c
                WHERE a.column3 = SUBSTR (c.column1, 2, 12));where schema.table@database is a remote table.
when executed with the hint /*+ ordered use_nl(a c) */ these query return no result and its execution plan is :
Rows     Row Source Operation
      0 NESTED LOOPS (cr=31 r=0 w=0 time=4894659 us)
   4323   SORT UNIQUE (cr=31 r=0 w=0 time=50835 us)
   4336    TABLE ACCESS FULL TABLE2 (cr=31 r=0 w=0 time=7607 us)
      0   REMOTE (cr=0 r=0 w=0 time=130536 us)When i changed the execution plan with the hint /*+ use_hash(c a) */
Rows     Row Source Operation
   3702 HASH JOIN SEMI (cr=35 r=0 w=0 time=497839 us)
22556   REMOTE (cr=0 r=0 w=0 time=401176 us)
   4336   TABLE ACCESS FULL TABLE2 (cr=35 r=0 w=0 time=7709 us)It seem that when the execution plan have changed the remote query return no result.
It'is a bug or i have missed somthing ?
PS: The two table are no subject to insert or update statement.
Oracle version : 9.2.0.2.0
System version : HP-UX v1
Thanks.

H.Mahmoud wrote:
Oracle version : 9.2.0.2.0
System version : HP-UX v1Hard to say. You're using a very old and deprecated version of the database, and one that was known to contain bugs.
9.2.0.7 was really the lowest version of 9i that was considered to be 'stable', but even so, it's old and lacking in many ways.
Consider upgrading to the latest database version at your earliest opportunity. (or at least apply patches up to the latest 9i version before querying if there is bugs in your really low buggy version)

Same sqlID with different execution plan and Elapsed Time (s), Executions time

Hello All,
The AWR reports for two days with same sqlID with different execution plan and Elapsed Time (s), Executions time please help me to find out what is reason for this change.
Please find the below detail 17th day my process are very slow as compare to 18th
17th Oct 18th Oct
221,808,602
21
2tc2d3u52rppt
213,170,100
72,495,618
9c8wqzz7kyf37
209,239,059
71,477,888
9c8wqzz7kyf37
139,331,777
1
7b0kzmf0pfpzn
144,813,295
1
0cqc3bxxd1yqy
102,045,818
1
8vp1ap3af0ma5
128,892,787
16,673,829
84cqfur5na6fg
89,485,065
1
5kk8nd3uzkw13
127,467,250
16,642,939
1uz87xssm312g
67,520,695
8,058,820
a9n705a9gfb71
104,490,582
12,443,376
a9n705a9gfb71
62,627,205
1
ctwjy8cs6vng2
101,677,382
15,147,771
3p8q3q0scmr2k
57,965,892
268,353
akp7vwtyfmuas
98,000,414
1
0ybdwg85v9v6m
57,519,802
53
1kn9bv63xvjtc
87,293,909
1
5kk8nd3uzkw13
52,690,398
0
9btkg0axsk114
77,786,274
74
1kn9bv63xvjtc
34,767,882
1,003
bdgma0tn8ajz9
Not only queries are different but also the number of blocks read by top 10 queries are much higher on 17th than 18th.
The other big difference is the average read time on two days
Tablespace IO Stats
17th Oct
Tablespace
Reads
Av Reads/s
Av Rd(ms)
Av Blks/Rd
Writes
Av Writes/s
Buffer Waits
Av Buf Wt(ms)
INDUS_TRN_DATA01
947,766
59
4.24
4.86
185,084
11
2,887
6.42
UNDOTBS2
517,609
32
4.27
1.00
112,070
7
108
11.85
INDUS_MST_DATA01
288,994
18
8.63
8.38
52,541
3
23,490
7.45
INDUS_TRN_INDX01
223,581
14
11.50
2.03
59,882
4
533
4.26
TEMP
198,936
12
2.77
17.88
11,179
1
732
2.13
INDUS_LOG_DATA01
45,838
3
4.81
14.36
348
0
1
0.00
INDUS_TMP_DATA01
44,020
3
4.41
16.55
244
0
1,587
4.79
SYSAUX
19,373
1
19.81
1.05
14,489
1
0
0.00
INDUS_LOG_INDX01
17,559
1
4.75
1.96
2,837
0
2
0.00
SYSTEM
7,881
0
12.15
1.04
1,361
0
109
7.71
INDUS_TMP_INDX01
1,873
0
11.48
13.62
231
0
0
0.00
INDUS_MST_INDX01
256
0
13.09
1.04
194
0
2
10.00
UNDOTBS1
70
0
1.86
1.00
60
0
0
0.00
STG_DATA01
63
0
1.27
1.00
60
0
0
0.00
USERS
63
0
0.32
1.00
60
0
0
0.00
INDUS_LOB_DATA01
62
0
0.32
1.00
60
0
0
0.00
TS_AUDIT
62
0
0.48
1.00
60
0
0
0.00
18th Oct
Tablespace
Reads
Av Reads/s
Av Rd(ms)
Av Blks/Rd
Writes
Av Writes/s
Buffer Waits
Av Buf Wt(ms)
INDUS_TRN_DATA01
980,283
91
1.40
4.74

The AWR reports for two days with same sqlID with different execution plan and Elapsed Time (s), Executions time please help me to find out what is reason for this change.
Please find the below detail 17th day my process are very slow as compare to 18th
You wrote with different execution plan, I think, you saw plans. It is very difficult, you get old plan.
I think Execution plans is not changed in different days, if you not added index or ...
What say ADDM report about this script?
As you know, It is normally, different Elapsed Time for same statement in different day.
It is depend your database workload.
It think you must use SQL Access and SQl Tuning advisor for this script.
You can get solution for slow running problem.
Regards
Mahir M. Quluzade

Same query at same time, but different execution plans from two schemas

Hi!
We just had some performance problems in our production system and I would like to ask for some advice from you.
We had a select-query that was run from USER1 on SCHEMA1, and it ran a table scan on a huge table.
Using session browser in TOAD I copied the Sql-statement, logged on SCHEMA1 and ran the same query. I got a different execution plan where I avoided the table scan.
So my question is:
How is it possible that the same query get different execution plans when running in two different schemas at the same time.
Some more information:
The user USER1 runs "alter session set current_schema=SCHEMA1;" when it logs on. Besides that it doesn't do anything so session parameter values are the same for USER1 and SCHEMA1.
SCHEMA1 is the schema owning the tables.
ALL_ROWS is used for both USER1 and SCHEMA1
Our database:
Oracle9i Enterprise Edition Release 9.2.0.8.0 - 64bit Production
PL/SQL Release 9.2.0.8.0 - Production
CORE 9.2.0.8.0 Production
TNS for Linux: Version 9.2.0.8.0 - Production
NLSRTL Version 9.2.0.8.0 - Production
Anybody has some suggestions to why I experience different execution plan for the same query, run at the same time, but from different users?

Thanks for clarification of the schema structure.
What happens if instead of setting the current session schema to SCHEMA1, if you simply add the schema name to alle tables, views and other objects inside your select statement?
As in select * from schema1.dual;I know that this is not what you want eventually, but it might help to find any misleading objects.
Furthermore it is not clear what you meant with: "avoided a table scan".
Did you avoid a full table scan (FTS) or was the table completely removed from the execution plan?
Can you post both plans?
Edited by: Sven W. on Mar 30, 2010 5:27 PM

Same query with different execution plan

Hello All,
I wonder why does sql server create different execution plan for these below queries ?
Thanks.

You can look at the expected query plan. Either visually in SSMS, or alternatively, you can run the query after the instruction SET SHOWPLAN_TEXT ON.
The Optimizer is the component of SQL Server that determines how the query is executed. It is cost based. It will assess different execution plans, estimate the cost of each of them and then select the cheapest. In this context, cheapest means the one with
the shortest runtime.
In your particular case, the estimation for the second query is, that scanning just a small part of the nonclustered index and then looking up the table data of the qualifying rows is the cheapest approach, because the estimated number of qualifying rows
is low.
In the first query, it estimated that looking up the many qualifying rows there would be too expensive, and that it would be cheaper to simply scan the entire clustered index, and simply filter out all unwanted rows. Note that the clustered index includes
the actual table data.
Gert-Jan

How to fix different execution plan for different bind variable values?

Please find the below query. The execution plan is fine. The problem That I am facing is in some cases for different bind variable values execution plan gets changed and degrades performance. I have used 6 tables here and all of the tables have histogram on all columns. Database version is Oracle 10g and the value of method_opt is 'For all columns size auto'
SELECT l.LineNumber INTO :b0
FROM Lines l ,LineVersions lv ,Statuses s
WHERE (((((((((((l.serviceContractId=:b1 AND l.LineId<>:b2)
AND lv.LineId=l.LineId) AND lv.StatusId=s.StatusId)
AND s.Code IN ('EPR','ERE','EEP','ERP','PRP','PRD','AAC'))
AND NOT (s.CODE='AAC' AND lv.activeto<TO_DATE(:b3,:b4)))
AND lv.EquipmentDetailId=:b5) AND lv.RouteDetailId=:b6)
AND (lv.cargoDetailId=:b7 OR lv.cargoDetailId IN
(SELECT i_cd1.cargoDetailId
FROM CargoDetails i_cd1 ,CargoDetails i_cd2 ,CargoCommodities i_cc1 ,
CargoCommodities i_cc2 WHERE
((((((i_cd2.cargoDetailId=:b7 AND i_cd1.cargoDetailId<>:b7)
AND i_cd1.ServiceContractId=:b1) AND i_cd1.cargoTypeId=i_cd2.cargoTypeId)
AND i_cc1.cargoDetailId=i_cd1.cargoDetailId)
AND i_cc2.cargoDetailId=i_cd2.cargoDetailId)
AND i_cc1.commodityId=i_cc2.commodityId))))
AND ((lv.customerGroupId IS NULL AND :b11=0) OR lv.customerGroupId IN
(SELECT cgm1.customerGroupId
FROM CustomerGroupMembers cgm1 ,CustomerGroupMembers cgm2 ,CustomerGroups cg1
WHERE (((cgm2.customerGroupId=:b11 AND cgm1.customerNoId=cgm2.customerNoId)
AND cg1.CustomerGroupId=cgm1.CustomerGroupId)
AND cg1.ServiceContractId=l.ServiceContractId)))) AND lv.linetype='C')
AND ROWNUM=1)
After searching in several blogs I have found the below solutions. Please see it and let me know it is correct or not
Solution 1:-Get rid of histogram that does nothing but messes up execution plan by giving below command
exec dbms_stats.gather_table_stats(owner, tablename, method_opt => 'for all columns size 1', cascade => true);
As 6 tables are there I need to execute above command 6 times.
Solution 2:- Use stored outline. Not sure how to get the best execution plan.
I am looking for answers ASAP. Thanks in advance

As you have probably read, bind variables and histograms do not mix well.
Histograms suggest that you have skew in your data such that different values should get different plans
Bind variables exist so that SQL with different supplied values can be shared.
Mix the two together and at parse time with bind variable peeking you get plans for specific values shared for all values.
The solutions you have mentioned are the common approaches, together with a third - use literals not binds if you've got data skew (i.e. your histograms are justified) and don't want shared SQL.
I would have thought that getting rid of some of these histograms may be the right approach if you're none of your application SQL is using literals to benefit from them.
Can you confirm your version of Oracle.
Further reading:
http://jonathanlewis.wordpress.com/2009/05/06/philosophy-1/
http://structureddata.org/2008/03/26/choosing-an-optimal-stats-gathering-strategy/
http://richardfoote.wordpress.com/2008/01/04/dbms_stats-method_opt-default-behaviour-changed-in-10g-be-careful/

Different execution plan in ApEx and SQL/PLUS

Hi
I have weird problem with sql query exectuion plans.
DB version: 10.2.0.1
ApEx version: 3.1.2
I have workspace parsed as SCHEMA1.
I have a view under different schema - SCHEMA2.view1 and a function SCHEMA2.func1.
I have a query like SELECT * from SCHEMA2.view1 WHERE col1 = SCHEMA2.func1(:bind1)
"col1" is a indexed column.
When I execute this query in SQL/PLUS under user SCHEMA1 with the same bind value, then index is used perfectly.
When I execute this query in ApEx report then index is not used, full scan is performed and hash join is done between the tables used in the view and explain plan shows that a view is formed during execution.
What can be the reason for such a different behaviour.
Statistics are freshly calculated, FIRST_ROWS hint doesn't help, using the INDEX hint results only index full scan.
This happens only if I use a view and pl/sql function together in the query. If I use view with Oracle built in function like NVL instead then it works perfectly. Also when I access directly the same tabels with the same PL/SQL function then the execution plan is perfect. Only if the view and pl/sql function is used together in the query then execution plan is bad.
It is not a problem of this specific query but, many different other queries with same pattern also. I have tried ApEx versions 3.0, 3.1.1 and 3.1.2.
At the same time the exectuion plan is good in SQL/PLUS and TOAD.
Any ideas?
Best regards,
jan

I didn't help. But I rewrote the queries so that there is no database view and PL/SQL function used in the same query. I still don't know the reason for such different behavior, but I just try to accept it and keep in mind for future :)
Thanks anyway!
jan

One query - one database - different execution plan for different users.

Hi everyone.
I've encountered one of the strangest things I've ever seen with Oracle. I'm hoping that someone else here has seen something like this before and solved it! On an 11g database I have a query that runs differently depending on which user runs it. If the owner of the tables or someone with the DBA role runs the query I get a perfect execution plan. If someone else runs it, I get a really bad execution plan - though the query still executes. So it almost seems like depending on who is running the query, the optimizer might not have access to the same statistics?? I'm really grasping at straws here - any help would be greatfully accepted!!!
Here is the query and the two plans for it...
On TASD as a General User (Bad execution plan) - CA17062 is USER
Connected to Oracle Database 11g Enterprise Edition Release 11.2.0.3.0
Connected as ca17062
SQL> explain plan for
select w.worker_id, w.worker_name
from worker_v                   w,
       worker_cost_centre_v       c
where w.worker_id = c.worker_id
   and c.effective_date <= trunc(sysdate)
   and c.expiration_date >= trunc(sysdate)
   and c.cost_centre = '100033'
   and pkg_taw_security.user_worker_access('CA17062',
                                           'TIMEKEEPER',
                                           w.worker_id,
                                           trunc(sysdate)) = 1
order by w.worker_name;
Explained
Executed in 0.234 seconds
PLAN_TABLE_OUTPUT
Plan hash value: 1726112176
| Id | Pid | Ord | Operation                      | Name                   | Rows | Bytes | Cost (%CPU)| Time     |
|   0 |     |   8 | SELECT STATEMENT               |                        |    18 | 1800 |   606   (1)| 00:00:01 |
|   1 |   0 |   7 | SORT ORDER BY                 |                        |    18 | 1800 |   606   (1)| 00:00:01 |
|* 2 |   1 |   6 |   HASH JOIN                    |                        |    18 | 1800 |   605   (1)| 00:00:01 |
|   3 |   2 |   3 |    VIEW                        | WORKER_COST_CENTRE_V   |    18 |   558 |    19   (0)| 00:00:01 |
|* 4 |   3 |   2 |     TABLE ACCESS BY INDEX ROWID| WORKER_COST_CENTRE_TBL |    18 |   522 |    19   (0)| 00:00:01 |
|* 5 |   4 |   1 |      INDEX RANGE SCAN          | WORKER_CC_CC_IDX       |    29 |       |     3   (0)| 00:00:01 |
|* 6 |   2 |   5 |    VIEW                        | WORKER_V               |   161K|    10M|   584   (1)| 00:00:01 |
|   7 |   6 |   4 |     TABLE ACCESS FULL          | WORKER_TBL             |   161K| 3466K|   584   (1)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - access("W"."WORKER_ID"="C"."WORKER_ID")
   4 - filter("X"."EXPIRATION_DATE">=TRUNC(SYSDATE@!))
PLAN_TABLE_OUTPUT
   5 - access("X"."COST_CENTRE"='100033' AND "X"."EFFECTIVE_DATE"<=TRUNC(SYSDATE@!))
   6 - filter("PKG_TAW_SECURITY"."USER_WORKER_ACCESS"('CA17062','TIMEKEEPER',"W"."WORKER_ID",TRUN
              C(SYSDATE@!))=1)
About
- XPlan v1.2 by Adrian Billington (http://www.oracle-developer.net)
23 rows selected
Executed in 0.577 seconds
WORKER_ID WORKER_NAME
123703    FADDEN, CLAYTON
11131     HAHN, BRAD
33811     HALL, MAUREEN
53934     JANES, CATHERINE
Executed in 35.241 seconds
On TASD as the owner of the tables or as someone with the DBA role (Good Execution) - TAS is USER:
Connected to Oracle Database 11g Enterprise Edition Release 11.2.0.3.0
Connected as tas
SQL> explain plan for
select w.worker_id, w.worker_name
from worker_v                   w,
       worker_cost_centre_v       c
where w.worker_id = c.worker_id
   and c.effective_date <= trunc(sysdate)
   and c.expiration_date >= trunc(sysdate)
   and c.cost_centre = '100033'
   and pkg_taw_security.user_worker_access('CA17062',
                                           'TIMEKEEPER',
                                           w.worker_id,
                                           trunc(sysdate)) = 1
order by w.worker_name;
Explained
Executed in 0.203 seconds
PLAN_TABLE_OUTPUT
Plan hash value: 3435904055
| Id | Pid | Ord | Operation                      | Name                   | Rows | Bytes | Cost (%CPU)| Time     |
|   0 |     |   8 | SELECT STATEMENT               |                        |    18 |   918 |    38   (3)| 00:00:01 |
|   1 |   0 |   7 | SORT ORDER BY                 |                        |    18 |   918 |    38   (3)| 00:00:01 |
|   2 |   1 |   6 |   NESTED LOOPS                 |                        |       |       |            |          |
|   3 |   2 |   4 |    NESTED LOOPS                |                        |    18 |   918 |    37   (0)| 00:00:01 |
|* 4 |   3 |   2 |     TABLE ACCESS BY INDEX ROWID| WORKER_COST_CENTRE_TBL |    18 |   522 |    19   (0)| 00:00:01 |
|* 5 |   4 |   1 |      INDEX RANGE SCAN          | WORKER_CC_CC_IDX       |    29 |       |     3   (0)| 00:00:01 |
|* 6 |   3 |   3 |     INDEX UNIQUE SCAN          | WORKER_PK              |     1 |       |     0   (0)| 00:00:01 |
|   7 |   2 |   5 |    TABLE ACCESS BY INDEX ROWID | WORKER_TBL             |     1 |    22 |     1   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   4 - filter("X"."EXPIRATION_DATE">=TRUNC(SYSDATE@!))
   5 - access("X"."COST_CENTRE"='100033' AND "X"."EFFECTIVE_DATE"<=TRUNC(SYSDATE@!))
PLAN_TABLE_OUTPUT
   6 - access("X"."WORKER_ID"="X"."WORKER_ID")
       filter("PKG_TAW_SECURITY"."USER_WORKER_ACCESS"('CA17062','TIMEKEEPER',"X"."WORKER_ID",TRUN
              C(SYSDATE@!))=1)
About
- XPlan v1.2 by Adrian Billington (http://www.oracle-developer.net)
23 rows selected
Executed in 0.624 seconds
WORKER_ID WORKER_NAME
123703    FADDEN, CLAYTON
11131     HAHN, BRAD
33811     HALL, MAUREEN
53934     JANES, CATHERINE
Executed in 1.307 seconds
THANKS!!!
Cory Aston

I reran the whole thing - with full declared view names and display_cursor. Here are the results...
On TASD as CA17062 (BAD EXECUTION PLAN)
SQL> set linesize 160
SQL> set serveroutput off
SQL>
SQL> select /*+ gather_plan_statistics */
2         w.worker_id, w.worker_name
3    from tas.worker_v                   w,
4         tas.worker_cost_centre_v       c
5   where w.worker_id = c.worker_id
6     and c.effective_date <= trunc(sysdate)
7     and c.expiration_date >= trunc(sysdate)
8     and c.cost_centre = '100033'
9     and tas_user.pkg_taw_security.user_worker_access('CA17062',
10                                             'TIMEKEEPER',
11                                             w.worker_id,
12                                             trunc(sysdate)) = 1
13   order by w.worker_name;
WORKER_ID WORKER_NAME
123703    FADDEN, CLAYTON
11131     HAHN, BRAD
33811     HALL, MAUREEN
53934     JANES, CATHERINE
SQL>
SQL> select * from table(dbms_xplan.display_cursor(null, null, 'ALLSTATS LAST'));
PLAN_TABLE_OUTPUT
SQL_ID gs5vtgany8vbv, child number 3
select /*+ gather_plan_statistics */        w.worker_id, w.worker_name
from tas.worker_v                   w,        tas.worker_cost_centre_v
      c where w.worker_id = c.worker_id    and c.effective_date <=
trunc(sysdate)    and c.expiration_date >= trunc(sysdate)    and
c.cost_centre = '100033'    and tas_user.pkg_taw_security.user_worker_ac
cess('CA17062',
'TIMEKEEPER',                                            w.worker_id,
                                         trunc(sysdate)) = 1 order by
w.worker_name
Plan hash value: 1726112176
| Id | Operation                      | Name                   | Starts | E-Rows | A-Rows |   A-Time   | Buffers | OMem | 1Mem | Used-Mem |
|   0 | SELECT STATEMENT               |                        |      1 |        |      4 |00:00:18.52 |     947K|       |       |          |
|   1 | SORT ORDER BY                 |                        |      1 |      4 |      4 |00:00:18.52 |     947K| 2048 | 2048 | 2048 (0)|
|* 2 |   HASH JOIN                    |                        |      1 |      4 |      4 |00:00:15.84 |     947K| 1348K| 1348K| 791K (0)|
|   3 |    VIEW                        | WORKER_COST_CENTRE_V   |      1 |      4 |      4 |00:00:00.01 |      18 |       |       |          |
|* 4 |     TABLE ACCESS BY INDEX ROWID| WORKER_COST_CENTRE_TBL |      1 |      4 |      4 |00:00:00.01 |      18 |       |       |          |
|* 5 |      INDEX RANGE SCAN          | WORKER_CC_CC_IDX       |      1 |     29 |     21 |00:00:00.01 |       3 |       |       |          |
|* 6 |    VIEW                        | WORKER_V               |      1 |    161K|      4 |00:00:15.84 |     946K|       |       |          |
|   7 |     TABLE ACCESS FULL          | WORKER_TBL             |      1 |    161K|    160K|00:00:00.09 |    2135 |       |       |          |
Predicate Information (identified by operation id):
   2 - access("W"."WORKER_ID"="C"."WORKER_ID")
   4 - filter("X"."EXPIRATION_DATE">=TRUNC(SYSDATE@!))
   5 - access("X"."COST_CENTRE"='100033' AND "X"."EFFECTIVE_DATE"<=TRUNC(SYSDATE@!))
   6 - filter("PKG_TAW_SECURITY"."USER_WORKER_ACCESS"('CA17062','TIMEKEEPER',"W"."WORKER_ID",TRUNC(SYSDATE@!))=1)
Note
   - cardinality feedback used for this statement
39 rows selected.
SQL>
On TASD as TAS: (GOOD EXECUTION PLAN)
SQL> set serveroutput off
SQL>
SQL> select /*+ gather_plan_statistics */
2         w.worker_id, w.worker_name
3    from tas.worker_v                   w,
4         tas.worker_cost_centre_v       c
5   where w.worker_id = c.worker_id
6     and c.effective_date <= trunc(sysdate)
7     and c.expiration_date >= trunc(sysdate)
8     and c.cost_centre = '100033'
9     and tas_user.pkg_taw_security.user_worker_access('CA17062',
10                                             'TIMEKEEPER',
11                                             w.worker_id,
12                                             trunc(sysdate)) = 1
13   order by w.worker_name;
WORKER_ID WORKER_NAME
123703    FADDEN, CLAYTON
11131     HAHN, BRAD
33811     HALL, MAUREEN
53934     JANES, CATHERINE
SQL>
SQL> select * from table(dbms_xplan.display_cursor(null, null, 'ALLSTATS LAST'));
PLAN_TABLE_OUTPUT
SQL_ID gs5vtgany8vbv, child number 1
select /*+ gather_plan_statistics */        w.worker_id, w.worker_name
from tas.worker_v                   w,        tas.worker_cost_centre_v
      c where w.worker_id = c.worker_id    and c.effective_date <=
trunc(sysdate)    and c.expiration_date >= trunc(sysdate)    and
c.cost_centre = '100033'    and tas_user.pkg_taw_security.user_worker_ac
cess('CA17062',
'TIMEKEEPER',                                            w.worker_id,
                                         trunc(sysdate)) = 1 order by
w.worker_name
Plan hash value: 3435904055
| Id | Operation                      | Name                   | Starts | E-Rows | A-Rows |   A-Time   | Buffers | OMem | 1Mem | Used-Mem |
|   0 | SELECT STATEMENT               |                        |      1 |        |      4 |00:00:00.01 |     185 |       |       |          |
|   1 | SORT ORDER BY                 |                        |      1 |      4 |      4 |00:00:00.01 |     185 | 2048 | 2048 | 2048 (0)|
|   2 |   NESTED LOOPS                 |                        |      1 |        |      4 |00:00:00.01 |     185 |       |       |          |
|   3 |    NESTED LOOPS                |                        |      1 |      4 |      4 |00:00:00.01 |     181 |       |       |          |
|* 4 |     TABLE ACCESS BY INDEX ROWID| WORKER_COST_CENTRE_TBL |      1 |      4 |      4 |00:00:00.01 |      18 |       |       |          |
|* 5 |      INDEX RANGE SCAN          | WORKER_CC_CC_IDX       |      1 |     29 |     21 |00:00:00.01 |       3 |       |       |          |
|* 6 |     INDEX UNIQUE SCAN          | WORKER_PK              |      4 |      1 |      4 |00:00:00.01 |     163 |       |       |          |
|   7 |    TABLE ACCESS BY INDEX ROWID | WORKER_TBL             |      4 |      1 |      4 |00:00:00.01 |       4 |       |       |          |
Predicate Information (identified by operation id):
   4 - filter("X"."EXPIRATION_DATE">=TRUNC(SYSDATE@!))
   5 - access("X"."COST_CENTRE"='100033' AND "X"."EFFECTIVE_DATE"<=TRUNC(SYSDATE@!))
   6 - access("X"."WORKER_ID"="X"."WORKER_ID")
       filter("PKG_TAW_SECURITY"."USER_WORKER_ACCESS"('CA17062','TIMEKEEPER',"X"."WORKER_ID",TRUNC(SYSDATE@!))=1)
Note
   - cardinality feedback used for this statement
39 rows selected.
SQL>

Different 'execution plans' for same sql in 10R2

DB=10.2.0.5
OS=RHEL 3
Im not sure of this, but seeing different plans for same SQL.
select sql_text from v$sqlarea where sql_id='92mb4z83fg4st'; <---TOP SQL from AWR
SELECT /*+ OPAQUE_TRANSFORM */ "ENDUSERID","LASTLOGINATTEMPTTIMESTAMP","LOGINSOURCECD","LOGINSUCCESSFLG",
"ENDUSERLOGINATTEMPTHISTORYID","VERSION_NUM","CREATEDATE"
FROM "BOMB"."ENDUSERLOGINATTEMPTHISTORY" "ENDUSERLOGINATTEMPTHISTORY";
SQL> set autotrace traceonly
SQL> SELECT /*+ OPAQUE_TRANSFORM */ "ENDUSERID","LASTLOGINATTEMPTTIMESTAMP","LOGINSOURCECD","LOGINSUCCESSFLG",
"ENDUSERLOGINATTEMPTHISTORYID","VERSION_NUM","CREATEDATE"
FROM "BOMB"."ENDUSERLOGINATTEMPTHISTORY" "ENDUSERLOGINATTEMPTHISTORY"; 2 3
1822203 rows selected.
Execution Plan
Plan hash value: 568996432
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1803K| 75M| 2919 (2)| 00:00:36 |
| 1 | TABLE ACCESS FULL| ENDUSERLOGINATTEMPTHISTORY | 1803K| 75M| 2919 (2)| 00:00:36 |
Statistics
0 recursive calls
0 db block gets
133793 consistent gets
0 physical reads
0 redo size
76637183 bytes sent via SQL*Net to client
1336772 bytes received via SQL*Net from client
121482 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1822203 rows processed
===================================== another plan ===============
SQL> select * from TABLE(dbms_xplan.display_awr('92mb4z83fg4st'));
15 rows selected.
Execution Plan
Plan hash value: 3015018810
| Id | Operation | Name |
| 0 | SELECT STATEMENT | |
| 1 | COLLECTION ITERATOR PICKLER FETCH| DISPLAY_AWR |
Note
- rule based optimizer used (consider using cbo)
Statistics
24 recursive calls
24 db block gets
49 consistent gets
0 physical reads
0 redo size
1529 bytes sent via SQL*Net to client
492 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
15 rows processed
=========second one shows only 15 rows...
Which one is correct ?

Understood, second plan is for self 'dbms_xplan'.
Anyhow I opened a new session where I did NOT on 'auto-trace'. but plan is somewhat than the original.
SQL> /
PLAN_TABLE_OUTPUT
SQL_ID 92mb4z83fg4st
SELECT /*+ OPAQUE_TRANSFORM */ "ENDUSERID","LASTLOGINATTEMPTTIMESTAMP","LOGINSOURCECD","
LOGINSUCCESSFLG","ENDUSERLOGINATTEMPTHISTORYID","VERSION_NUM","CREATEDATE" FROM
"BOMB"."ENDUSERLOGINATTEMPTHISTORY" "ENDUSERLOGINATTEMPTHISTORY"
Plan hash value: 568996432
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
PLAN_TABLE_OUTPUT
| 0 | SELECT STATEMENT | | | | 2919 (100)| |
| 1 | TABLE ACCESS FULL| ENDUSERLOGINATTEMPTHISTORY | 1803K| 75M| 2919 (2)| 00:00:36 |
15 rows selected.
I am just wondering, which plan is the accurate and which I need to believe ?

How to transfer data between different tables in an Oracle 10g databse?

I have to do the following: there are 5 database tables in our Oracle 10g database that store certain data. Then there are 2 new tables where we want the data to go to. My task is to somehow transfer all the data that is in the first 5 tables and insert it in the 2 new ones. All tables are in the same database. The challenge lies in the fact that the structures of the tables are very dissimilar so it won't be a matter of a simple INSERT SQL query.
The data access tier of our application is developed in JAVA. We use EJB. So one way I am thinking of doing the above mentioned data transfer is to simply code it in the JAVA backed. But that might be to slow, there are millions of records in those first 5 tables. What is the best way to do something like that? Perhaps a custom (Perl?) script or some such?
Thanks.

The problem is that the way the data is stored in the old tables you cannot write a query that would return it in such a format that you could immediately insert it in the new table without some formatting. Let me illustrate with an example. To pull the data from the old tables I use this query:
SELECT
     SXML_DOCUMENT_DATA.VALUE As DocumentValue,
SXML_ELEMENT.NAME As ElementName
FROM
     SXML_DOCUMENT,
     SXML_DOCUMENT_DATA,
     SXML_DOCUMENT_DETAIL,
     SXML_ELEMENT,
     SXML_TYPE
WHERE
     SXML_TYPE.XML_TYPE_KEY = SXML_DOCUMENT.XML_TYPE_KEY
AND     SXML_DOCUMENT.XML_DOCUMENT_KEY = SXML_DOCUMENT_DETAIL.XML_DOCUMENT_KEY
AND     SXML_DOCUMENT_DETAIL.XML_DOCUMENT_DETAIL_KEY = SXML_DOCUMENT_DATA.XML_DOCUMENT_DETAIL_KEY
AND     SXML_ELEMENT.XML_ELEMENT_KEY = SXML_DOCUMENT_DATA.XML_ELEMENT_KEY
AND     SXML_TYPE.NAME = 'DA_UNIT_COMMITMENT'
AND     (SXML_ELEMENT.NAME = 'resource'
     OR SXML_ELEMENT.NAME = 'resourceType'
     OR SXML_ELEMENT.NAME = 'commitmentType'
     OR SXML_ELEMENT.NAME = 'startTime'
     OR SXML_ELEMENT.NAME = 'endTime'
     OR SXML_ELEMENT.NAME = 'schedulingCoordinator')
ORDER BY
     SXML_DOCUMENT.NAME,
     SXML_DOCUMENT_DETAIL.XML_DOCUMENT_DETAIL_KEY,
     SXML_DOCUMENT_DATA.XML_DOCUMENT_DATA_KEY,
     SXML_ELEMENT.NAME;
The results from the SQL query above look like this:
DOCUMENTVALUE | ELEMENTNAME
1 | ALAMIT_7_UNIT_1 | resource
2 | GEN | resourceType
3 | BRS8 | schedulingCoordinator
4 | IFM | commitmentType
5 | 2008-07-29T18:00:00:00 | startTime
6 | 2008-07-30T00:00:00 | endTime
7 | ALAMIT_7_UNIT_1 | resource
8 | GEN | resourceType
9 | BRS8 | schedulingCoordinator
10 | IFM | commitmentType
11 | 2008-07-29T00:00:00 | startTime
12 | 2008-07-29T04:00:00 | endTime
and so on. The type of data repeats every 6 records. And the values of each 6 records corresponds to 1 row in the new table, which looks like this:
schedulingCoordinator | resource | resourceType | commitmentType | startDate | endDate
1| 1 | 27 | GEN | IFM | 2008-07-29T18:00:00:00 | 2008-07-30T00:00:00
2| 1 | 27 | GEN | | 2008-07-29T00:00:00 | 2008-07-29T04:00:00
So hopefully now you see the challenge. It is not as simple as writing a SQL query that returns result rows corresponding 1 to 1 to a row in the new table. Somehow I need to take the first 6 result rows from that big SQL query and put them in the first row of the new table. Then the next 6 and put them in the second row and so on. And also, we are talking about millions of records. What happens if I process the first 2 million and then some error occurs? Do I start from the beginning again? One idea I have is to process the data in chunks, say process 500 results, commit, process another 500, commit, and so on.
Edited by: 799984 on Oct 11, 2010 9:08 AM

Capacity Plan with Oracle 10g

Good Day to all,
I've little time working in environments with Oracle databases, I have requested to carry out a capacity plan with Oracle Database 10g for a data warehouse project that is leading the company in which they work. I request to make a plan specifying, among other things: size and number of tablespace and datafiles, projection growth taking into account the initial charge and the charge per week (incremental). The truth is a bit complicated for my inexperience in this kind of sizing requirements we will ask for your valuable cooperation. There are mathematical formulas that allow me to take those projections into account the type of data and their lengths? , There is a standard for creating the tablespace and datafiles?.
In advance thank you for your contributions.

The first thing you need to get management to do is give you two things.
1. The cost to the organization for downtime, rated in dollars/hour.
2. The service level agreement for the system's customers.
3. The amount of data to be loaded into the system and the retention time.
4. What version of RAID or what ASM redundancy is planned.
With that you can start at the grossest level which is planning for database + archived redo logs + online back files.
I generally figure the database, itself, at about 25% of required storage because I like to have at least two full backups, a bunch of incremental backups, plus all of the archived redo logs that support them. And all on separate shelves.
The number of tablespaces and data files is really just a question of maintenance. Ease of transport. Ease of movement. Ease of backing up.
If you want to get down to the actual sizes of tables and indexes the best place to go is the DBMS_SPACE built-in package. Play with these two procedures:
CREATE_TABLE_COST and CREATE_INDEX_COST which do the job far more efficiently and accurately than any formulas you will receive. You can find demos
of this capability here: http://www.morganslibrary.org/reference/dbms_space.html.

Different execution plan for same query but for different condition value

Hi All,
I'm facing a strange situation where same query for different condition not working.
1--
Select top 10 * from revenuefact(nolock)
where feecode ='OW4'
2--
Select top 10 * from revenuefact(nolock)
where feecode ='BTE'
1st query is returning result easily but 2nd query is taking too long. Column
feecode has already Non-clustered index and Clustered index is also available for another col RevenueSID.
I was surprised when checked the query execution plan for both the above queries which is quite different (as per attached below). Can anyone suggest me the reason behind it.
And solution for the same. One more thing that data for feecode BTE is inserting through different source instead of others feecode and table contains more than 300 million rows.

When I speak with people inside Microsoft who work with the optimizer, the refuse to accept the work "bug" when a query produces the correct result, but with a suboptimal plan. They prefer to use the word "limitation".
The limitation here is that when the optimizer compares two plans, it only looks at the estimated cost. As far as I know, it does not perform any analysis from the perspective "what if the statistics are wrong"? They do provide the hint OPTIMIZE
FOR UNKNOWN, but that does not work then there is a constant as in this case.
The optimizer will surely distinguish between TOP 10 and TOP 10000000. With the latter, you have all reason to expect a Clustered Index Scan no matter which value you search for - unless you pick a value for which the histogram indicates that there are no
rows.
Interesting enough, I was able to reproduce the situation in my Northgale database, which is an inflated version of Northwind, and where statistics should be accurate.
SELECT TOP 10 * FROM Orders WHERE EmployeeID = 8
results in a CI scan, and so does also EmployeeID = 7, and even 5. There are only 2292 rows out of a total of 344305 rows. If I try EmployeeID 808 for which there are 1797, the optimizer goes for the index seek.
Erland Sommarskog, SQL Server MVP, [email protected]

Different execution plans for the same SQL query

Good afternoon,
My customer is sending an SQL query that goes slower after some time.
He has verified the exection plan, and this seems to change after some time.
At first (when the database has just been restarted), it looks like this:
Rows Row Source Operation
3 TABLE ACCESS BY GLOBAL INDEX ROWID <TABLE1> PARTITION: 1 1
22 NESTED LOOPS
3 VIEW
3 MINUS
14215 SORT UNIQUE
14215 NESTED LOOPS
14215 TABLE ACCESS FULL <TABLE1> PARTITION: 1 1
14215 TABLE ACCESS BY GLOBAL INDEX ROWID <TABLE2> PARTITION: 1 1
14215 INDEX UNIQUE SCAN <INDEX2> (object id 26024)
14212 SORT UNIQUE
14212 REMOTE
18 INDEX RANGE SCAN <INDEX1> (object id 25911)
After a while, this becomes:
Rows Row Source Operation
8 NESTED LOOPS
14218 TABLE ACCESS FULL <TABLE1> PARTITION: 1 1
8 VIEW
113744 MINUS
202151524 SORT UNIQUE
14218 NESTED LOOPS
14218 TABLE ACCESS FULL <TABLE1> PARTITION: 1 1
14218 TABLE ACCESS BY GLOBAL INDEX ROWID <TABLE2> PARTITION: 1 1
14218 INDEX UNIQUE SCAN <INDEX_2> (object id 26024)
202037780 SORT UNIQUE
14210 REMOTE
At regular intervals a "coalesce" of the <INDEX2> is scheduled.
Do you have any idea what might cause this different plans? (it's heavily impacting performance, because the second execution plan takes 5 times more time)
Thanks
Dominique
Edited by: scampsd on May 17, 2011 1:42 PM

scampsd wrote:
Good afternoon,
My customer is sending an SQL query that goes slower after some time.
He has verified the exection plan, and this seems to change after some time.
At first (when the database has just been restarted), it looks like this:
At regular intervals a "coalesce" of the <INDEX2> is scheduled.
Do you have any idea what might cause this different plans? (it's heavily impacting performance, because the second execution plan takes 5 times more time)Something on your system is changing. Unfortunately if finding out what were easy you would have done it already
You have isolated a couple of things. What happends of you disable the index maintenance?
It is odd that performance as you described it degrands merely because of time the database has been up

Different execution plans for the same sql

Hi,
Im testing our new 10gR2 database on Linux and I can't understand why the same query use different plan.
Here are the details.
Table name: invoice_detail
Records: About 10,670,900
Columns:
No
seq (the primary key is No+Seq). Each invoices contains +/- 10 invoice_details.
category ( <- 10 different values )
State ( <- 3 different values )
Basically, I have an index on the primary key and another index on Category + State.
My request:
select *
from invoice_detail
where no=123456 <- Best index to use
and state <> 'CANCEL'
and category = 'INVOICE'
If i run this query from Toad or sql+, that's fine.
The same query (i'm watching it from EM) executed via Forms use the category+state index.
When I first import the database, the last thing I do is to run DBMS_STATS.GATHER_DATABASE_STATS.
At this point, Forms use the right index.
The day after (after the database has been analyzed with the predefined job via EM) Forms use the wrong index.
I re-analyzed everything with exec DBMS_STATS.GATHER_DATABASE_STATS but the problem is still there.
Thanks in advance

I'm already using bind variables.
I changed the "Estimated Percentage" to 100% in "Gather Optimizer Statistics Default Options" and now it seems to use the correct index. I'm stressed because I dont understand why it chooses different plan for the same sql.
Actually, my users test the migration 1 day after I load all the data (drop schema-create schema-load data-analyze database) and at this point everythings go fine. After the second analyze of the database, the DB choose the wrong indexes.
I really cannot migrate until I understand why it happens.
Any ideas?
TIA

Can Oracle make mistakes while making execution plan?

Env: Running Oracle DB 11g Rel 1.
Is it possible that oracle may use a different execution plan for the same query depending on the environment where its running due to any reason. I am running an oracle report 6i/10g which has started to take too long to run but at the same time runs better/faster while in sql*plus or toad. Report has nothing more than a query (like: no pl/sql, or triggers with sqls).
Is it also possible that depending on the different environment that runs the query or user profile, oracle might be using a different (may be bad) execution plan. Though at the same time database is same, no parameters are changed at run time explicitly by user or application. Base table of the query are all analyzed on regular basis.
Or, is it possible that at some point in time in the past, the same query had a bad plan and oracle kept using it from the cache (though I can't find any doc which would support this). I think that estimated plan might be bad based on past statistics but actual plan shouldn't be same bad as estimated. Does clearing the cache help?
Any insight or links to docs are appreciated.

ocp9i wrote:
Env: Running Oracle DB 11g Rel 1.
Is it possible that oracle may use a different execution plan for the same query depending on the environment where its running due to any reason. That is after all what cost based optimisation is.. taking the existing factors into consideration for determining the execution plans. Different factors may apply for future executions of that SQL - which could mean a different execution plan.
CBO does not mean that there will be a consistent-always-the-same execution plan for a SQL. It can and often will differ over time.
I am running an oracle report 6i/10g which has started to take too long to run but at the same time runs better/faster while in sql*plus or toad.You cannot evaluate performance using elapsed execution time - that is a flawed approach. The very same query can run a lot faster after the 1st execution as the 1st execution did expensive physical I/O from disk. Subsequent execution of that query will find the data in the buffer cache and instead of physical I/O, do cheaper logical I/O.
Also, reporting will typically include rendering. This is an added overhead that a plain SQL select in comparison will not have.
So you need to be careful in how you match the performance of a query like this. There's a lot more to it than meets the eye.
Or, is it possible that at some point in time in the past, the same query had a bad plan and oracle kept using it from the cache (though I can't find any doc which would support this). How do you know that this is a bad execution plan? How do you know that the report SQL uses a different execution plan than what your plain SQL select test does?
If the query is exactly the same (proper shared SQL), then there will be a single execution plan for that query. The 1st time that the query is hard parsed, this execution plan is created. Subsequent processes/sessions will use the very same execution plan (soft parsing) until that cursor is aged from the Shared Pool.
Thus if you are firing off an identical query via Reports and something like SQL*Plus.. chances are excellent that both is using the exact same execution plan.
Any insight or links to docs are appreciated.Suggest that you look at the Oracle Concepts guide. You'll find it via http://tahiti.oracle.com

Very different execution plan in Oracle 10g vs. 9i

Similar Messages

Maybe you are looking for