Query with diff. explain plans

Hi,
Our query returns different execution plans in Prod and non-prod. It is slow in PROD. The data size is the same in both DBs and stats are gathered at 50% estimate for both schemas:
Prod (slow) explain plan:
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 852 | 33 (4)| 00:00:01 |
|* 1 | FILTER | | | | | |
| 2 | HASH GROUP BY | | 1 | 852 | 33 (4)| 00:00:01 |
| 3 | NESTED LOOPS | | 1 | 852 | 32 (0)| 00:00:01 |
| 4 | NESTED LOOPS | | 1 | 802 | 31 (0)| 00:00:01 |
| 5 | NESTED LOOPS OUTER | | 1 | 785 | 30 (0)| 00:00:01 |
| 6 | NESTED LOOPS OUTER | | 1 | 742 | 29 (0)| 00:00:01 |
| 7 | NESTED LOOPS | | 1 | 732 | 29 (0)| 00:00:01 |
| 8 | NESTED LOOPS | | 1 | 678 | 26 (0)| 00:00:01 |
| 9 | NESTED LOOPS | | 1 | 666 | 26 (0)| 00:00:01 |
| 10 | NESTED LOOPS | | 1 | 623 | 25 (0)| 00:00:01 |
| 11 | NESTED LOOPS | | 1 | 580 | 24 (0)| 00:00:01 |
| 12 | NESTED LOOPS | | 1 | 576 | 24 (0)| 00:00:01 |
| 13 | NESTED LOOPS | | 2 | 1076 | 13 (0)| 00:00:01 |
| 14 | NESTED LOOPS | | 2 | 1040 | 13 (0)| 00:00:01 |
| 15 | NESTED LOOPS | | 2 | 1028 | 13 (0)| 00:00:01 |
| 16 | NESTED LOOPS | | 2 | 996 | 13 (0)| 00:00:01 |
| 17 | NESTED LOOPS | | 2 | 988 | 13 (0)| 00:00:01 |
| 18 | NESTED LOOPS | | 2 | 954 | 13 (0)| 00:00:01 |
| 19 | NESTED LOOPS | | 2 | 944 | 13 (0)| 00:00:01 |
| 20 | NESTED LOOPS | | 2 | 920 | 13 (0)| 00:00:01 |
| 21 | NESTED LOOPS | | 2 | 912 | 13 (0)| 00:00:01 |
| 22 | NESTED LOOPS | | 2 | 826 | 11 (0)| 00:00:01 |
| 23 | NESTED LOOPS | | 1 | 370 | 9 (0)| 00:00:01 |
| 24 | NESTED LOOPS | | 1 | 306 | 8 (0)| 00:00:01 |
| 25 | NESTED LOOPS | | 1 | 263 | 7 (0)| 00:00:01 |
| 26 | NESTED LOOPS | | 1 | 220 | 6 (0)| 00:00:01 |
| 27 | NESTED LOOPS | | 1 | 177 | 5 (0)| 00:00:01 |
| 28 | NESTED LOOPS | | 1 | 129 | 4 (0)| 00:00:01 |
| 29 | NESTED LOOPS | | 1 | 86 | 3 (0)| 00:00:01 |
| 30 | TABLE ACCESS BY INDEX ROWID| SYMMETADATA | 1 | 43 | 2 (0)| 00:00:01 |
|* 31 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 1 | | 1 (0)| 00:00:01 |
| 32 | TABLE ACCESS BY INDEX ROWID| SYMMETADATA | 1 | 43 | 1 (0)| 00:00:01 |
|* 33 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 1 | | 0 (0)| 00:00:01 |
| 34 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 1 | 43 | 1 (0)| 00:00:01 |
|* 35 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 1 | | 0 (0)| 00:00:01 |
| 36 | TABLE ACCESS BY INDEX ROWID | TPRODUCT | 1 | 48 | 1 (0)| 00:00:01 |
|* 37 | INDEX UNIQUE SCAN | TPRODUCT_UNIQUE | 1 | | 0 (0)| 00:00:01 |
| 38 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 1 | 43 | 1 (0)| 00:00:01 |
|* 39 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 1 | | 0 (0)| 00:00:01 |
| 40 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 1 | 43 | 1 (0)| 00:00:01 |
|* 41 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 1 | | 0 (0)| 00:00:01 |
| 42 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 1 | 43 | 1 (0)| 00:00:01 |
|* 43 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 1 | | 0 (0)| 00:00:01 |
| 44 | TABLE ACCESS BY INDEX ROWID | TPRODUCT | 1 | 64 | 1 (0)| 00:00:01 |
|* 45 | INDEX UNIQUE SCAN | TPRODUCT_UNIQUE | 1 | | 0 (0)| 00:00:01 |
| 46 | INLIST ITERATOR | | | | | |
| 47 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 2 | 86 | 2 (0)| 00:00:01 |
|* 48 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 2 | | 1 (0)| 00:00:01 |
| 49 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 1 | 43 | 1 (0)| 00:00:01 |
|* 50 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 1 | | 0 (0)| 00:00:01 |
|* 51 | INDEX UNIQUE SCAN | SYMUSERCOUNT_PK | 1 | 4 | 0 (0)| 00:00:01 |
|* 52 | INDEX UNIQUE SCAN | SYMUSERCOUNT_PK | 1 | 12 | 0 (0)| 00:00:01 |
|* 53 | INDEX UNIQUE SCAN | SYMSKUTYPE_PK | 1 | 5 | 0 (0)| 00:00:01 |
|* 54 | INDEX UNIQUE SCAN | SYMSKUTYPE_PK | 1 | 17 | 0 (0)| 00:00:01 |
|* 55 | INDEX UNIQUE SCAN | SYMSKULANGUAGE_PK | 1 | 4 | 0 (0)| 00:00:01 |
|* 56 | INDEX UNIQUE SCAN | SYMSKULANGUAGE_PK | 1 | 16 | 0 (0)| 00:00:01 |
|* 57 | INDEX UNIQUE SCAN | SYMVENDOR_PK | 1 | 6 | 0 (0)| 00:00:01 |
|* 58 | INDEX UNIQUE SCAN | SYMVENDOR_PK | 1 | 18 | 0 (0)| 00:00:01 |
| 59 | TABLE ACCESS BY INDEX ROWID | SYMPRODUCTSKU | 1 | 38 | 6 (0)| 00:00:01 |
|* 60 | INDEX RANGE SCAN | I_PSKU_MERCH_LOOKUP | 1 | | 5 (0)| 00:00:01 |
|* 61 | INDEX UNIQUE SCAN | SYMMEDIATYPE_PK | 1 | 4 | 0 (0)| 00:00:01 |
|* 62 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 1 | 43 | 1 (0)| 00:00:01 |
|* 63 | INDEX UNIQUE SCAN | SYMMETADATA_PK | 1 | | 0 (0)| 00:00:01 |
| 64 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 1 | 43 | 1 (0)| 00:00:01 |
|* 65 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 1 | | 0 (0)| 00:00:01 |
|* 66 | INDEX UNIQUE SCAN | SYMMEDIATYPE_PK | 1 | 12 | 0 (0)| 00:00:01 |
| 67 | TABLE ACCESS BY INDEX ROWID | SYMPRODUCTSKU | 1 | 54 | 3 (0)| 00:00:01 |
|* 68 | INDEX RANGE SCAN | I_PSKU_MERCH_LOOKUP | 1 | | 2 (0)| 00:00:01 |
|* 69 | INDEX UNIQUE SCAN | SYMPCCOUNT_PK | 1 | 10 | 0 (0)| 00:00:01 |
| 70 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 1 | 43 | 1 (0)| 00:00:01 |
|* 71 | INDEX UNIQUE SCAN | SYMMETADATA_PK | 1 | | 0 (0)| 00:00:01 |
|* 72 | TABLE ACCESS BY INDEX ROWID | TPRODUCTSKU | 1 | 17 | 1 (0)| 00:00:01 |
|* 73 | INDEX UNIQUE SCAN | TPRODUCTSKU_PK | 1 | | 0 (0)| 00:00:01 |
|* 74 | TABLE ACCESS BY INDEX ROWID | TPRODUCTSKU | 1 | 50 | 1 (0)| 00:00:01 |
|* 75 | INDEX UNIQUE SCAN | TPRODUCTSKU_PK | 1 | | 0 (0)| 00:00:01 |
Non Prod (Fast) Plan:
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 383 | 28 (0)| 00:00:01 |
|* 1 | FILTER | | | | | |
| 2 | NESTED LOOPS | | 1 | 383 | 17 (0)| 00:00:01 |
| 3 | NESTED LOOPS OUTER | | 1 | 350 | 16 (0)| 00:00:01 |
| 4 | NESTED LOOPS | | 1 | 308 | 15 (0)| 00:00:01 |
| 5 | NESTED LOOPS | | 1 | 266 | 14 (0)| 00:00:01 |
| 6 | NESTED LOOPS OUTER | | 1 | 262 | 14 (0)| 00:00:01 |
| 7 | NESTED LOOPS | | 1 | 258 | 14 (0)| 00:00:01 |
| 8 | NESTED LOOPS | | 2 | 438 | 7 (0)| 00:00:01 |
| 9 | NESTED LOOPS | | 2 | 428 | 7 (0)| 00:00:01 |
| 10 | NESTED LOOPS | | 2 | 420 | 7 (0)| 00:00:01 |
| 11 | NESTED LOOPS | | 2 | 410 | 7 (0)| 00:00:01 |
| 12 | NESTED LOOPS | | 2 | 402 | 7 (0)| 00:00:01 |
| 13 | NESTED LOOPS | | 1 | 159 | 5 (0)| 00:00:01 |
| 14 | NESTED LOOPS | | 1 | 126 | 4 (0)| 00:00:01 |
| 15 | NESTED LOOPS | | 1 | 84 | 3 (0)| 00:00:01 |
| 16 | TABLE ACCESS BY INDEX ROWID| SYMMETADATA | 1 | 42 | 2 (0)| 00:00:01 |
|* 17 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 1 | | 1 (0)| 00:00:01 |
| 18 | TABLE ACCESS BY INDEX ROWID| SYMMETADATA | 1 | 42 | 1 (0)| 00:00:01 |
|* 19 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 1 | | 0 (0)| 00:00:01 |
| 20 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 1 | 42 | 1 (0)| 00:00:01 |
|* 21 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 1 | | 0 (0)| 00:00:01 |
| 22 | TABLE ACCESS BY INDEX ROWID | TPRODUCT | 1 | 33 | 1 (0)| 00:00:01 |
|* 23 | INDEX UNIQUE SCAN | TPRODUCT_UNIQUE | 1 | | 0 (0)| 00:00:01 |
| 24 | INLIST ITERATOR | | | | | |
| 25 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 2 | 84 | 2 (0)| 00:00:01 |
|* 26 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 2 | | 1 (0)| 00:00:01 |
|* 27 | INDEX UNIQUE SCAN | SYMUSERCOUNT_PK | 1 | 4 | 0 (0)| 00:00:01 |
|* 28 | INDEX UNIQUE SCAN | SYMSKUTYPE_PK | 1 | 5 | 0 (0)| 00:00:01 |
|* 29 | INDEX UNIQUE SCAN | SYMSKULANGUAGE_PK | 1 | 4 | 0 (0)| 00:00:01 |
|* 30 | INDEX UNIQUE SCAN | SYMVENDOR_PK | 1 | 5 | 0 (0)| 00:00:01 |
| 31 | TABLE ACCESS BY INDEX ROWID | SYMPRODUCTSKU | 1 | 39 | 4 (0)| 00:00:01 |
|* 32 | INDEX RANGE SCAN | I_PSKU_MERCH_LOOKUP | 1 | | 3 (0)| 00:00:01 |
|* 33 | INDEX UNIQUE SCAN | SYMPCCOUNT_PK | 1 | 4 | 0 (0)| 00:00:01 |
|* 34 | INDEX UNIQUE SCAN | SYMMEDIATYPE_PK | 1 | 4 | 0 (0)| 00:00:01 |
|* 35 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 1 | 42 | 1 (0)| 00:00:01 |
|* 36 | INDEX UNIQUE SCAN | SYMMETADATA_PK | 1 | | 0 (0)| 00:00:01 |
| 37 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 1 | 42 | 1 (0)| 00:00:01 |
|* 38 | INDEX UNIQUE SCAN | SYMMETADATA_PK | 1 | | 0 (0)| 00:00:01 |
|* 39 | TABLE ACCESS BY INDEX ROWID | TPRODUCTSKU | 1 | 33 | 1 (0)| 00:00:01 |
|* 40 | INDEX UNIQUE SCAN | TPRODUCTSKU_PK | 1 | | 0 (0)| 00:00:01 |
| 41 | SORT AGGREGATE | | 1 | 252 | | |
| 42 | NESTED LOOPS | | 1 | 252 | 11 (0)| 00:00:01 |
| 43 | NESTED LOOPS | | 1 | 240 | 10 (0)| 00:00:01 |
| 44 | NESTED LOOPS | | 1 | 205 | 7 (0)| 00:00:01 |
| 45 | NESTED LOOPS | | 1 | 200 | 7 (0)| 00:00:01 |
| 46 | NESTED LOOPS | | 1 | 196 | 7 (0)| 00:00:01 |
| 47 | NESTED LOOPS | | 1 | 191 | 7 (0)| 00:00:01 |
| 48 | NESTED LOOPS | | 1 | 187 | 7 (0)| 00:00:01 |
| 49 | NESTED LOOPS | | 1 | 183 | 7 (0)| 00:00:01 |
| 50 | NESTED LOOPS | | 1 | 150 | 6 (0)| 00:00:01 |
| 51 | NESTED LOOPS | | 1 | 120 | 5 (0)| 00:00:01 |
| 52 | NESTED LOOPS | | 1 | 90 | 4 (0)| 00:00:01 |
| 53 | NESTED LOOPS | | 1 | 60 | 3 (0)| 00:00:01 |
| 54 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 1 | 30 | 2 (0)| 00:00:01 |
|* 55 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 1 | | 1 (0)| 00:00:01 |
| 56 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 1 | 30 | 1 (0)| 00:00:01 |
|* 57 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 1 | | 0 (0)| 00:00:01 |
| 58 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 1 | 30 | 1 (0)| 00:00:01 |
|* 59 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 1 | | 0 (0)| 00:00:01 |
| 60 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 1 | 30 | 1 (0)| 00:00:01 |
|* 61 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 1 | | 0 (0)| 00:00:01 |
| 62 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 1 | 30 | 1 (0)| 00:00:01 |
|* 63 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 1 | | 0 (0)| 00:00:01 |
| 64 | TABLE ACCESS BY INDEX ROWID | TPRODUCT | 1 | 33 | 1 (0)| 00:00:01 |
|* 65 | INDEX UNIQUE SCAN | TPRODUCT_UNIQUE | 1 | | 0 (0)| 00:00:01 |
|* 66 | INDEX UNIQUE SCAN | SYMUSERCOUNT_PK | 1 | 4 | 0 (0)| 00:00:01 |
|* 67 | INDEX UNIQUE SCAN | SYMMEDIATYPE_PK | 1 | 4 | 0 (0)| 00:00:01 |
|* 68 | INDEX UNIQUE SCAN | SYMSKUTYPE_PK | 1 | 5 | 0 (0)| 00:00:01 |
|* 69 | INDEX UNIQUE SCAN | SYMSKULANGUAGE_PK | 1 | 4 | 0 (0)| 00:00:01 |
|* 70 | INDEX UNIQUE SCAN | SYMVENDOR_PK | 1 | 5 | 0 (0)| 00:00:01 |
| 71 | TABLE ACCESS BY INDEX ROWID | SYMPRODUCTSKU | 1 | 35 | 3 (0)| 00:00:01 |
|* 72 | INDEX RANGE SCAN | I_PSKU_MERCH_LOOKUP | 1 | | 2 (0)| 00:00:01 |
|* 73 | TABLE ACCESS BY INDEX ROWID | TPRODUCTSKU | 1 | 12 | 1 (0)| 00:00:01 |
|* 74 | INDEX UNIQUE SCAN | TPRODUCTSKU_PK | 1 | | 0 (0)| 00:00:01 |
Database version is 10.2.0.4. Can anyone help me understand what else to be looking for to make it work faster?

Please see the following threads for the ideal information required:
How to post a sql tuning request:
HOW TO: Post a SQL statement tuning request - template posting
When your query takes too long:
When your query takes too long ...

Similar Messages

Same query with different explain plans

Hi All,
I have one of the select query with different explain plans on two separate env, the query fetches the correct index on test env whereas on prod it's not fetching the same index.
The structure, indices, no. of rows are similar in CRMINFO table with up-to-date statistics.
Env Details :
OS - Sun Solaris 5.10
DB - 10.2.0.4
Init param:
Optimizer_mode = ALL_ROWS
optimizer_dynamic_sampling integer 5
optimizer_features_enable string 10.2.0.4
optimizer_index_caching integer 90
optimizer_index_cost_adj integer 30
Query :*
SELECT COUNT (*)
FROM CRMINFO
WHERE RETAILER = :1
AND STATUS = 20
AND EXC = :1
AND SUBNO IS NULL
Expain Plan (TST):
SELECT STATEMENT ALL_ROWSCost: 916 Bytes: 19 Cardinality: 1
3 SORT AGGREGATE Bytes: 19 Cardinality: 1
2 TABLE ACCESS BY INDEX ROWID TABLE TST.CRMINFO Cost: 916 Bytes: 16,663 Cardinality: 877
1 INDEX RANGE SCAN INDEX TST.CRMINFO_X1 Cost: 42 Cardinality: 12,549
Index (TST):
CRMINFO_X1(EXC, RETAILER, STATUS)
Explain Plan (PROD):
SELECT STATEMENT ALL_ROWSCost: 1,832 Bytes: 19 Cardinality: 1
3 SORT AGGREGATE Bytes: 19 Cardinality: 1
2 TABLE ACCESS BY INDEX ROWID TABLE PROD.CRMINFO Cost: 1,832 Bytes: 2,052 Cardinality: 108
1 INDEX RANGE SCAN INDEX PROD.CRMINFO_X2 Cost: 117 Cardinality: 42,519
Index (PROD):
CRMINFO_X2 (RETAILER)
How does Oracle calculates the cost and decides which index it should fetch ? Why it didn't choose the same index as of test env? How should i approach and which domains i need to dig-in to find the cause?
I did try playing with the above mentioned init parameters but it didn't help at all.
Thanks.
Regards,
~Pointer

Pointer wrote:
Hmm, my worry is how do i force oracle to grap the proper index on prod i.e (CRMINFO_X1). I certainly believe it's a bad approach on adding a hint in the select statement and to force oralce to fetch that index.Why do you believe that, the index you mention is the "proper" index versus what Oracle is choosing? Can you prove with hinting that the "proper" index results in a faster and more efficient execution plan? If it does, then the next place I would look at is the statistics for the tables and columns of interest. From here you could try and estimate why Oracle thinks the other index is better. Another option is to run a 10053 (CBO) trace and see why Oracle thinks it is better.
I would not support a hint in a production environment, except in the most extreme cases. Usually the CBO makes the right choice, but it only can if the statistics match the distribution of data.
Refreshing the data may help me simulating the issue on TST but it wouldn't help me to understand why on prod it uses CRMINFO_X2 instead of CRMINFO_X1 which has all the three columns in the Where clause of the query.It would help because it's a test environment and you wouldn't have to do any queries directly on your production system to achieve the same results.
>
A bad thought here :( , if i create a new index by changing the column positioning say like ( RETAILER, STATUS , EXC) instead of (EXC, RETAILER, STATUS) will oracle fetch it ? or would it help in reducing the cost and cardinatlity of the select query.It's not that easy. There is a lot that goes into the cost calculation, some of that is known (through the great work by Jonathan Lewis and Richard Foote), and some of that is purely internal to Oracle. If you are more interested in the internals Cost-Based Oracle Fundamentals by Jonathan Lewis is a great book.
HTH!

Query with same explain-plan but slower in one env

Hi there
I have a stored procedure which is executed from a web application. It contains a query (insert-select-from statement). When this stored procedure is called by the web application in PROD, it takes 13sec but it takes 19sec in TEST env. I checked the explain plan for this insert statement in both instances and it is same (see below). Actually, the cost is lower in TEST env.
ENV: Oracle 10gR2 EE, on ASM - RHEL 64bit
The TEST server is on a better/faster hardware and will become the new PROD in near future (faster and 16 CPUs vs 8 in PROD, high performance SAN, 132GB RAM vs 96GB in PROD, etc). The TEST database has exact same init parameter and version/patch level as current PROD. So the application is being tested against it at the moment.
Here are the explain-plans from both environments:
From PROD Server
Plan
INSERT STATEMENT ALL_ROWS Cost: 143 Bytes: 696 Cardinality: 3
18 SORT ORDER BY Cost: 143 Bytes: 696 Cardinality: 3
17 HASH UNIQUE Cost: 142 Bytes: 696 Cardinality: 3
16 WINDOW SORT Cost: 143 Bytes: 696 Cardinality: 3
15 HASH JOIN Cost: 141 Bytes: 696 Cardinality: 3
13 HASH JOIN Cost: 128 Bytes: 519 Cardinality: 3
11 TABLE ACCESS BY INDEX ROWID TABLE MKTG.SATDATAIMPORT Cost: 125 Bytes: 1,728 Cardinality: 12
10 NESTED LOOPS Cost: 125 Bytes: 1,992 Cardinality: 12
3 HASH JOIN Cost: 5 Bytes: 22 Cardinality: 1
1 TABLE ACCESS FULL TABLE MKTG.TMPG_CLICKS_HDGS Cost: 2 Bytes: 12 Cardinality: 1
2 TABLE ACCESS FULL TABLE MKTG.TMPG_CLICKS_DIRS Cost: 2 Bytes: 10 Cardinality: 1
9 BITMAP CONVERSION TO ROWIDS
8 BITMAP AND
5 BITMAP CONVERSION FROM ROWIDS
4 INDEX RANGE SCAN INDEX MKTG.SATDATAIMPORT_HEADINGNO Cost: 19 Cardinality: 4,920
7 BITMAP CONVERSION FROM ROWIDS
6 INDEX RANGE SCAN INDEX MKTG.SATDATAIMPORT_DIRNO Cost: 89 Cardinality: 4,920
12 TABLE ACCESS FULL TABLE MKTG.MONTHS12 Cost: 2 Bytes: 84 Cardinality: 12
14 TABLE ACCESS FULL TABLE MKTG.REF_WEST_CATEGORY Cost: 12 Bytes: 191,809 Cardinality: 3,251
From TEST Server
Plan
INSERT STATEMENT ALL_ROWS Cost: 107 Bytes: 232 Cardinality: 1
18 SORT ORDER BY Cost: 107 Bytes: 232 Cardinality: 1
17 HASH UNIQUE Cost: 106 Bytes: 232 Cardinality: 1
16 WINDOW SORT Cost: 107 Bytes: 232 Cardinality: 1
15 HASH JOIN Cost: 105 Bytes: 232 Cardinality: 1
13 HASH JOIN Cost: 93 Bytes: 173 Cardinality: 1
11 TABLE ACCESS BY INDEX ROWID TABLE MKTG.SATDATAIMPORT Cost: 89 Bytes: 864 Cardinality: 6
10 NESTED LOOPS Cost: 89 Bytes: 996 Cardinality: 6
3 HASH JOIN Cost: 7 Bytes: 22 Cardinality: 1
1 TABLE ACCESS FULL TABLE MKTG.TMPG_CLICKS_HDGS Cost: 3 Bytes: 12 Cardinality: 1
2 TABLE ACCESS FULL TABLE MKTG.TMPG_CLICKS_DIRS Cost: 3 Bytes: 10 Cardinality: 1
9 BITMAP CONVERSION TO ROWIDS
8 BITMAP AND
5 BITMAP CONVERSION FROM ROWIDS
4 INDEX RANGE SCAN INDEX MKTG.SATDATAIMPORT_HEADINGNO Cost: 9 Cardinality: 2,977
7 BITMAP CONVERSION FROM ROWIDS
6 INDEX RANGE SCAN INDEX MKTG.SATDATAIMPORT_DIRNO Cost: 59 Cardinality: 2,977
12 TABLE ACCESS FULL TABLE MKTG.MONTHS12 Cost: 3 Bytes: 84 Cardinality: 12
14 TABLE ACCESS FULL TABLE MKTG.REF_WEST_CATEGORY Cost: 12 Bytes: 191,868 Cardinality: 3,252
What else can I check to find out why the query is slower in TEST env?
Please advise.
Best regards

Here is some more info. The query is below:
select distinct dr.line_num
                 ,row_number() over (partition by di.HEADINGNO,di.DIRECTORYNO order by reportyear,to_number(di.monthno)) monthposition
                 ,di.SATID,di.REPORTYEAR,di.MONTHNO,di.MONTHEN,di.MONTHFR,di.HEADINGNO,hn.NAME_EN,hn.NAME_FR,di.DIRECTORYNO
                 ,di.SUPERDIRECTORYNO,di.PRINTDIRCODE,di.DIRECTORYNAME,round(to_number(di.IMPTTOTAL)) imptotal
                 ,round(to_number(di.IMPBEST)) impbest ,round(to_number(di.IMPTAVERAGE)) imptaverage
                 ,round(to_number(di.CLICKTOTAL)) clicktotal,round(to_number(di.CLICKBEST)) clickbest
                 ,round(to_number(di.CLICKAVERAGE)) clickaverage
                 ,round(avg(to_number(impttotal)) over(partition by di.HEADINGNO,di.DIRECTORYNO)) avgimp
           from satdataimport di,tmpg_clicks_hdgs hd,tmpg_clicks_dirs dr, months12 m12, ref_west_category hn
           where di.headingno   = hd.id
             and di.directoryno = dr.id
             and dr.line_num=hd.line_num
             and di.reportyear = m12.year
             and di.monthno     = m12.month
             and hn.CATEGORY_CODE = di.headingno
           order by di.headingno, di.directoryno,di.reportyear,to_number(di.monthno)
The largest table is "satdataimport" in the query has "12274818" rows. Rest of the tables are very small containing few rows to less than 4000 rows.
I have refreshed the statistics of the larger table but this did not help either. Even a simple query like "select count(*) from satdataimport" is taking 15sec in TEST while it takes 4Sec in PROD when I run it from TOAD.
The other strange thing is that when I run this stored procedure from TOAD, it takes 200 milli sec to complete. There is a logging table to which the stored procedure records the elapsed time taken by this INSERT statement.
Since this query is in a stored procedure being called from the web app, the QA team wants quicker response. Current PROD is faster.
The tables have same indexes, etc and contain identical data as that in PROD (were refreshed from PROD yesterday).
What else can I check?
Best regards

Multiple DB env with different explain plan

Hi,
I have DEV DB and QA DB , both located in USA. There is a table called Customer which contains the respective index , pk, constraints, etc which is available in
both the environments. Now In DEV DB we have Customer table with 1000 records, but in QA DB we have about 50000 records.
Now in DEV DB when i take a explain plan the columns are not going for a FULL table scan but in QA DB it is going for a full table scan? Why there is a discrepancies? Is it because of the number of records in QA is more than DEV? I hope that wont be a problem as Oracle CBO/RBO will optimize the query by itself for both the cases using the index, etc. If that is the case I am wondering what might me the problem. Whether we need to inform the Oracle using the hints? Please shed some light into this.
Thanks.

First of all it is a good idea to compare the execution plans from differnt environments. Not all developers do that. The cost or time can not be properly compared, but the plan itself yes. if the plan is different, then the behaviour of the query very likely also is different.
What you didn't show us was the query and the two different plans. Maybe in a broken down test version.
What is strange is that I would have expected a reversed behaviour. In the dev db you have only 1000 records. Usually the db will do a FULL table scan on this. Simply because the amount of data is so small that it is othen faster to read the table in one big chuck and then deal with it. The parameter db_multiblock_read_count plays a role in that. If it does instead an table access by index rowid then that is fine.
If you QA Db now uses a "full table scan" instead of the "table access by index rowid" that it is something to think about. Possible reasons can be: Not current statistics. For example do you have an automatic job that collects statistics? Maybe this job didn't run yet, after you imported the data? To use hints as a solution would be wrong. However you can use hints to see, if the performace of the query improves after using the hint. If it does, then the CBO didn't have good enough information. If it doesn't then the CBO already made the right decision.

Query needs tuning; Explain plan attached

DB version:10gR2
Currently, the below query is taking more than 28 secs to complete. The table stats are up-to-date.
Is there a way to rewrite/tune this query?
SELECT DISTINCT TASK_HDR.TASK_ID,
                 TASK_HDR.WHSE,
                 TASK_HDR.TASK_DESC,
                 TASK_HDR.INVN_TYPE,
                 TASK_HDR.INVN_NEED_TYPE,
                 TASK_HDR.DFLT_TASK_PRTY,
                 TASK_HDR.CURR_TASK_PRTY,
                 TASK_HDR.XPECTD_DURTN,
                 TASK_HDR.ACTL_DURTN,
                 TASK_HDR.ERLST_START_DATE_TIME,
                 TASK_HDR.LTST_START_DATE_TIME,
                 TASK_HDR.LTST_CMPL_DATE_TIME,
                 TASK_HDR.BEGIN_AREA,
                 TASK_HDR.BEGIN_ZONE,
                 TASK_HDR.BEGIN_AISLE,
                 TASK_HDR.END_AREA,
                 TASK_HDR.END_ZONE,
                 TASK_HDR.END_AISLE,
                 TASK_HDR.START_CURR_WORK_GRP,
                 TASK_HDR.START_CURR_WORK_AREA,
                 TASK_HDR.END_CURR_WORK_GRP,
                 TASK_HDR.END_CURR_WORK_AREA,
                 TASK_HDR.START_DEST_WORK_GRP,
                 TASK_HDR.START_DEST_WORK_AREA,
                 TASK_HDR.END_DEST_WORK_GRP,
                 TASK_HDR.END_DEST_WORK_AREA,
                 TASK_HDR.TASK_TYPE,
                 TASK_HDR.TASK_GENRTN_REF_CODE,
                 TASK_HDR.TASK_GENRTN_REF_NBR,
                 TASK_HDR.NEED_ID,
                 TASK_HDR.TASK_BATCH,
                 TASK_HDR.STAT_CODE,
                 TASK_HDR.CREATE_DATE_TIME,
                 TASK_HDR.MOD_DATE_TIME,
                 TASK_HDR.USER_ID,
                 TASK_HDR.RLS_DATE_TIME,
                 TASK_HDR.SKU_ID,
                 TASK_HDR.TASK_CMPL_REF_CODE,
                 TASK_HDR.TASK_CMPL_REF_NBR,
                 TASK_HDR.OWNER_USER_ID,
                 TASK_HDR.ONE_USER_PER_GRP,
                 TASK_HDR.NEXT_TASK_ID,
                 TASK_HDR.EXCEPTION_CODE,
                 TASK_HDR.CURR_LOCN_ID,
                 TASK_HDR.TASK_PARM_ID,
                 TASK_HDR.RULE_ID,
                 TASK_HDR.VOCOLLECT_ASSIGN_ID,
                 TASK_HDR.CURR_USER_ID,
                 TASK_HDR.MHE_FLAG,
                 TASK_HDR.PICK_TO_TOTE_FLAG,
                 TASK_HDR.MHE_ORD_STATE,
                 TASK_HDR.PRT_TASK_LIST_FLAG,
                 TASK_HDR.RPT_PRTR_REQSTR,
                 TASK_HDR.ORIG_TASK_ID
   FROM INVN_NEED_TYPE, TASK_DTL, TASK_HDR
    WHERE (TASK_HDR.TASK_ID = TASK_DTL.TASK_ID(+))
      AND TASK_HDR.WHSE = '01' AND TASK_HDR.STAT_CODE >= 99 AND
          TASK_HDR.INVN_NEED_TYPE = INVN_NEED_TYPE.INVN_NEED_TYPE AND
          INVN_NEED_TYPE.WHSE = TASK_HDR.WHSE AND
          (INVN_NEED_TYPE.CO = '88') AND (INVN_NEED_TYPE.DIV = '51') AND
          (TASK_DTL.PKT_CTRL_NBR IS NULL OR TASK_DTL.INVN_NEED_TYPE = 1) AND
          TASK_HDR.MOD_DATE_TIME <= sysdate-85
ORDER BY TASK_HDR.CREATE_DATE_TIME DESC
The explain plan:
PLAN_TABLE_OUTPUT
| Id | Operation                        | Name              | Rows | Bytes |TempSpc| Cost (%CPU)|
|   0 | SELECT STATEMENT                 |                   | 10032 | 1969K|       | 3143   (2)|
|   1 | SORT ORDER BY                   |                   | 10032 | 1969K| 4232K| 3143   (2)|
|   2 |   HASH UNIQUE                    |                   | 10032 | 1969K| 4232K| 2689   (2)|
|   3 |    FILTER                        |                   |       |       |       |            |
|   4 |     NESTED LOOPS OUTER           |                   | 10032 | 1969K|       | 2235   (1)|
|   5 |      NESTED LOOPS                |                   | 3226 |   570K|       |   284   (3)|
|   6 |       TABLE ACCESS BY INDEX ROWID| TASK_HDR          | 3412 |   559K|       |   282   (2)|
|   7 |        INDEX RANGE SCAN          | TASK_HDR_IND_3    | 9042 |       |       |     8 (13)|
|   8 |       INDEX UNIQUE SCAN          | PK_INVN_NEED_TYPE |     1 |    13 |       |     1   (0)|
|   9 |      TABLE ACCESS BY INDEX ROWID | TASK_DTL          |     3 |    60 |       |     1   (0)|
| 10 |       INDEX RANGE SCAN           | PK_TASK_DTL       |     3 |       |       |     1   (0)|
---------------------------------------------------------------------------------------------------

My apologies, yes, it is:
SELECT TASK_HDR.TASK_ID,
                 TASK_HDR.WHSE,
                 TASK_HDR.TASK_DESC,
                 TASK_HDR.INVN_TYPE,
                 TASK_HDR.INVN_NEED_TYPE,
                 TASK_HDR.DFLT_TASK_PRTY,
                 TASK_HDR.CURR_TASK_PRTY,
                 TASK_HDR.XPECTD_DURTN,
                 TASK_HDR.ACTL_DURTN,
                 TASK_HDR.ERLST_START_DATE_TIME,
                 TASK_HDR.LTST_START_DATE_TIME,
                 TASK_HDR.LTST_CMPL_DATE_TIME,
                 TASK_HDR.BEGIN_AREA,
                 TASK_HDR.BEGIN_ZONE,
                 TASK_HDR.BEGIN_AISLE,
                 TASK_HDR.END_AREA,
                 TASK_HDR.END_ZONE,
                 TASK_HDR.END_AISLE,
                 TASK_HDR.START_CURR_WORK_GRP,
                 TASK_HDR.START_CURR_WORK_AREA,
                 TASK_HDR.END_CURR_WORK_GRP,
                 TASK_HDR.END_CURR_WORK_AREA,
                 TASK_HDR.START_DEST_WORK_GRP,
                 TASK_HDR.START_DEST_WORK_AREA,
                 TASK_HDR.END_DEST_WORK_GRP,
                 TASK_HDR.END_DEST_WORK_AREA,
                 TASK_HDR.TASK_TYPE,
                 TASK_HDR.TASK_GENRTN_REF_CODE,
                 TASK_HDR.TASK_GENRTN_REF_NBR,
                 TASK_HDR.NEED_ID,
                 TASK_HDR.TASK_BATCH,
                 TASK_HDR.STAT_CODE,
                 TASK_HDR.CREATE_DATE_TIME,
                 TASK_HDR.MOD_DATE_TIME,
                 TASK_HDR.USER_ID,
                 TASK_HDR.RLS_DATE_TIME,
                 TASK_HDR.SKU_ID,
                 TASK_HDR.TASK_CMPL_REF_CODE,
                 TASK_HDR.TASK_CMPL_REF_NBR,
                 TASK_HDR.OWNER_USER_ID,
                 TASK_HDR.ONE_USER_PER_GRP,
                 TASK_HDR.NEXT_TASK_ID,
                 TASK_HDR.EXCEPTION_CODE,
                 TASK_HDR.CURR_LOCN_ID,
                 TASK_HDR.TASK_PARM_ID,
                 TASK_HDR.RULE_ID,
                 TASK_HDR.VOCOLLECT_ASSIGN_ID,
                 TASK_HDR.CURR_USER_ID,
                 TASK_HDR.MHE_FLAG,
                 TASK_HDR.PICK_TO_TOTE_FLAG,
                 TASK_HDR.MHE_ORD_STATE,
                 TASK_HDR.PRT_TASK_LIST_FLAG,
                 TASK_HDR.RPT_PRTR_REQSTR,
                 TASK_HDR.ORIG_TASK_ID
   FROM INVN_NEED_TYPE,TASK_HDR
    WHERE TASK_HDR.WHSE = '01' AND TASK_HDR.STAT_CODE >= 99 AND
          TASK_HDR.INVN_NEED_TYPE = INVN_NEED_TYPE.INVN_NEED_TYPE AND
          INVN_NEED_TYPE.WHSE = TASK_HDR.WHSE AND
          (INVN_NEED_TYPE.CO = '88') AND (INVN_NEED_TYPE.DIV = '51') AND
          TASK_HDR.MOD_DATE_TIME <= sysdate-85
     AND EXISTS (SELECT 1
                           FROM TASK_DTL
                         WHERE TASK_HDR.TASK_ID = TASK_DTL.TASK_ID
                            AND (TASK_DTL.PKT_CTRL_NBR IS NULL OR TASK_DTL.INVN_NEED_TYPE = 1))
ORDER BY TASK_HDR.CREATE_DATE_TIME DESCAlthough you have an OUTER JOIN on TASK_DTL.TASK_ID, this is converted to an INNER JOIN with (TASK_DTL.PKT_CTRL_NBR IS NULL OR TASK_DTL.INVN_NEED_TYPE = 1), which is the equivalent of the 'EXISTS' version above.
I haven't been able to test this.

Help with interpreting explain plan (dbms_xplan) output

Hi all,
I'm trying to get to grips with reading and interpreting the explain plan or dbms_xplan output, and so I hope someone can help with the output below.
So, with the explain shown below, does it mean that...
a) it starts with step 8 and sends all rows to the nested loop in step 5
b) it only sends (or thinks it sends) 1 row to step 5 from step 8
c) For each row supplied from step 5, there will be an index lookup at step 8 to access the table at step 6
d) Step 8 only gets (or think it gets) 1 row
If it does mean that only 1 row is expected by the optimizer, and yet the full table scan should return 150,000 records, and the table has up to date statistiucs, what else would cause the cardinality to be so far off?
If it doesn't mean it will return 1 row then what does it mean ?
| Id | Operation                           | Name                           | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT                    |                                |       |       |   945 (100)|          |
|   1 | SORT GROUP BY                      |                                |     1 |   283 |   945   (3)| 00:00:05 |
|* 2 |   FILTER                            |                                |       |       |            |          |
|   3 |    NESTED LOOPS                     |                                |       |       |            |          |
|   4 |     NESTED LOOPS                    |                                |     1 |   283 |   944   (3)| 00:00:05 |
|   5 |      NESTED LOOPS                   |                                |     1 |   108 |   929   (3)| 00:00:05 |
|* 6 |       MAT_VIEW ACCESS FULL          | DEMOGRAPHICS_MV                |     1 |    97 |   927   (3)| 00:00:05 |
|* 7 |       MAT_VIEW ACCESS BY INDEX ROWID| NAMES_MV                       |     1 |    11 |     2   (0)| 00:00:01 |
|* 8 |        INDEX RANGE SCAN             | ORG_MV_IDX1                    |     1 |       |     1   (0)| 00:00:01 |
|* 9 |      INDEX RANGE SCAN               | PAY_IDX8                       |   252 |       |     4   (0)| 00:00:01 |
|* 10 |     TABLE ACCESS BY INDEX ROWID     | PAY_ALL                        |     1 |   175 |    15   (0)| 00:00:01 |
Predicate Information (identified by operation id):
      8 - access("ORG_MV"."ORG_ID"="DEMO_MV"."ORG_ID")Many thanks for your help.

Thank you Hemant and rp0428,
I read through that white paper which was really useful.
I ran query using GATHER_PLAN_STATISTICS and go tthe Estimate and Actual rows - wow - it is a long way out!!
| Id | Operation                           | Name                           | Starts | E-Rows |E-Bytes| Cost (%CPU)| E-Time   | A-Rows |   A-Time   | Buffers | Reads | OMem | 1Mem | Used-Mem |
|   0 | SELECT STATEMENT                    |                                |      1 |        |       |   945 (100)|          |      0 |00:18:11.39 |    2552K|    361K|       |       |          |
|   1 | SORT GROUP BY                      |                                |      1 |      1 |   283 |   945   (3)| 00:00:05 |      0 |00:18:11.39 |    2552K|    361K| 1024 | 1024 |          |
|* 2 |   FILTER                            |                                |      1 |        |       |            |          |      0 |00:18:11.39 |    2552K|    361K|       |       |          |
|   3 |    NESTED LOOPS                     |                                |      1 |        |       |            |          |      0 |00:18:11.39 |    2552K|    361K|       |       |          |
|   4 |     NESTED LOOPS                    |                                |      1 |      1 |   283 |   944   (3)| 00:00:05 |     44M|00:04:59.03 |     598K| 63442 |       |       |          |
|   5 |      NESTED LOOPS                   |                                |      1 |      1 |   108 |   929   (3)| 00:00:05 |    109K|00:00:01.73 |    7807 |      7 |       |       |          |
|* 6 |       MAT_VIEW ACCESS FULL          | DEMOGRAPHICS_MV                |      1 |      1 |    97 |   927   (3)| 00:00:05 |    126K|00:00:00.26 |    5417 |      1 |       |       |          |
|* 7 |       MAT_VIEW ACCESS BY INDEX ROWID| NAMES_MV                       |    126K|      1 |    11 |     2   (0)| 00:00:01 |    109K|00:00:01.27 |    2390 |      6 |       |       |          |
|* 8 |        INDEX RANGE SCAN             | ORG_MV_IDX1                    |    126K|      1 |       |     1   (0)| 00:00:01 |    126K|00:00:00.69 |    2023 |      6 |       |       |          |
|* 9 |      INDEX RANGE SCAN               | PAY_IDX8                       |    109K|    252 |       |     4   (0)| 00:00:01 |     44M|00:04:03.07 |     590K| 63435 |       |       |          |
|* 10 |     TABLE ACCESS BY INDEX ROWID     | PAY_ALL                        |     44M|      1 |   175 |    15   (0)| 00:00:01 |      0 |00:13:09.85 |    1954K|    297K|       |       |          |
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------When I unravel the WHERE clause and remove the decode(nvl statements (which only evaluate the passed in parameters and provide default values where they are NULL) I get a much better plan and values
| Id | Operation                        | Name                           | Starts | E-Rows |E-Bytes| Cost (%CPU)| E-Time   | A-Rows |   A-Time   | Buffers | Reads | OMem | 1Mem | Used-Mem |
|   0 | SELECT STATEMENT                 |                                |      1 |        |       |   157K(100)|          |      0 |00:00:43.10 |     343K| 45190 |       |       |          |
|   1 | SORT GROUP BY                   |                                |      1 |      1 |   283 |   157K (1)| 00:13:47 |      0 |00:00:43.10 |     343K| 45190 | 1024 | 1024 |          |
|   2 |   NESTED LOOPS                   |                                |      1 |        |       |            |          |      0 |00:00:43.10 |     343K| 45190 |       |       |          |
|   3 |    NESTED LOOPS                  |                                |      1 |      1 |   283 |   157K (1)| 00:13:47 |      0 |00:00:43.10 |     343K| 45190 |       |       |          |
|* 4 |     HASH JOIN                    |                                |      1 |      1 |   272 |   157K (1)| 00:13:47 |      0 |00:00:43.10 |     343K| 45190 |   720K|   720K| 171K (0)|
|* 5 |      TABLE ACCESS BY INDEX ROWID | PAY_ALL                        |      1 |      2 |   350 |   156K (1)| 00:13:43 |      0 |00:00:43.10 |     343K| 45190 |       |       |          |
|* 6 |       INDEX RANGE SCAN           | PAY_IDX7                       |      1 |   3596K|       | 15565   (1)| 00:01:22 |   7251K|00:00:50.88 |   45190 | 45190 |       |       |          |
|* 7 |      MAT_VIEW ACCESS FULL        | DEMOGRAPHICS_MV                |      0 |    126K|    11M|   919   (2)| 00:00:05 |      0 |00:00:00.01 |       0 |      0 |       |       |          |
|* 8 |     INDEX RANGE SCAN             | ORG_MV_IDX1                    |      0 |      1 |       |     1   (0)| 00:00:01 |      0 |00:00:00.01 |       0 |      0 |       |       |          |
|* 9 |    MAT_VIEW ACCESS BY INDEX ROWID| NAMES_MV                       |      0 |      1 |    11 |     2   (0)| 00:00:01 |      0 |00:00:00.01 |       0 |      0 |       |       |          |
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Even though the result set is zero, the time to establish this came down from 35 minutes to 30 seconds and the plan has changed and is using a different index now!
Thanks for your help!

TUNNING A SQL QUERY AND UNSERSTAND EXPLAIN PLAN

I was trying my handing in tunning sql queries -
Though I have manged to reduce the cost lil ..creating some index, but have genarated a g8 interesting in tunning - Can some experts ( I know there are lots available :-) ) help me on the approch on "HOW TO TUNE A QUERY"
moreover I also would like to understand - how to debug a explain plan, - please help ...
Regards..

Hi,
Welcome to this forum...
I would suggest your to read first the official documentations :
- The concepts of an Oracle DBMS (this is important to know, because Oracle structures, processes, objects (etc) are the building blocks of your database)
- SQL reference guide
- PL/SQL reference guide
and then at a later stage the Performance and tuning guide:
You can start there:
http://download.oracle.com/docs/cd/B14117_01/nav/portal_1.htm
Once it's done maybe read the Performance and tuning guide:
http://download.oracle.com/docs/cd/B14117_01/server.101/b10752/toc.htm
(Chapter 19 explain ... how to interpret the explain plan ..)
I wish you good chance and be patient: I'm working with Oracle for more that 10 years and I'm still learning! ...
Rem: The Oracle website is full of interesting articles, and examples, just "search" your special points of interests ..

Query returns different Explain Plan

Hi,
I have two databases that are identical to each other. But I have a query that runs on both and returns different explain plans in both. It runs slower in one than other. How can I troubleshoot this further to get faster times in the slower database?
THanks,
Prachi

Query:
=====
SELECT sum(total_contacts), sum(email_partner_news), sum(email_tech_news),
sum(email_enduser_news), sum(email), sum(email_gmo), sum(gmo_nophone),
sum(email_gmo_noaddress), sum(email_gmo_address), sum(
email_gmo_nocertaddr), sum(email_gmo_certaddress), sum(
email_gmo_nophone_noaddr), sum(phone_number), sum(gmo_with_phone),
sum(phone_number_email_gmo_noaddr), sum(phone_number_email_gmo_nocert),
sum(phone_number_address), sum(phone_number_address_noemail), sum(
phone_address_email_nogmo), sum(phone_number_address_email), sum(
phone_number_certaddr), sum(phone_number_certaddr_noemail), sum(
phone_certaddr_email_nogmo), sum(phone_number_address_gmo), sum(
phone_certaddr_email_gmo), sum(address), sum(
address_nophone_number_nogmo), sum(address_certified), sum(
certaddr_nophone_nogmo), sum(address_email_nophone_gmo), sum(
certaddr_email_nophone_gmo), sum(phone_gmo), sum(smail_gmo), sum(fax_gmo
), sum(email_wcast), sum(email_inews), sum(email_salrt), sum(
phone_gmo_phone), sum(smail_gmo_address), sum(fax_gmo_fax)
FROM contact_values_vw_tc_2 cv, ((SELECT gcd_contact_id
FROM contact_values)
INTERSECT
((SELECT gcd_contact_id
FROM gcddata.contact_country s, gcd.country c,
segmentation_query_values v
WHERE s.country_id = c.country_id
AND c.region_id = v.query_value
AND v.selection_type = 'I'
AND v.query_id = 2088
AND v.query_sequence = 1)
INTERSECT
(SELECT gcd_contact_id
FROM gcddata.contact_country s, gcd.country c,
segmentation_query_values v
WHERE s.country_id = c.country_id
AND c.sub_region_id = v.query_value
AND v.selection_type = 'I'
AND v.query_id = 2088
AND v.query_sequence = 2)) ) sl
WHERE cv.gcd_contact_id = sl.gcd_contact_id
AND cv.country_id IN (SELECT cm.country_id
FROM segmentation_user_country_map cm
WHERE cm.user_name = 'E30590')
========================================
Execution Plan - FAST
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=32931 Card=1 Bytes=73)
1 0 SORT (AGGREGATE)
2 1 HASH JOIN (Cost=32931 Card=386388 Bytes=28206324)
3 2 VIEW (Cost=29617 Card=1142043 Bytes=14846559)
4 3 INTERSECTION
5 4 SORT (UNIQUE)
6 5 INDEX (FAST FULL SCAN) OF 'CONTACT_VALUES1_PK' (UNIQUE) (Cost=5 Card=1907737 Bytes=11446422)
7 4 INTERSECTION
8 7 SORT (UNIQUE)
9 8 HASH JOIN (Cost=655 Card=1998575 Bytes=57958675)
10 9 HASH JOIN (Cost=6 Card=110 Bytes=2200)
11 10 TABLE ACCESS (BY INDEX ROWID) OF 'SEGMENTATION_QUERY_VALUES' (Cost=3 Card=7 Bytes=91)
12 11 INDEX (RANGE SCAN) OF 'SEG_QUERY_VALUES_ PK' (UNIQUE) (Cost=2 Card=15)
13 10 TABLE ACCESS (FULL) OF 'COUNTRY' (Cost=2 Card=120 Bytes=840)
14 9 TABLE ACCESS (FULL) OF 'CONTACT_COUNTRY1' (Cost=643 Card=2199855 Bytes=19798695)
15 7 SORT (UNIQUE)
16 15 HASH JOIN (Cost=655 Card=1142043 Bytes=33119247)
17 16 HASH JOIN (Cost=6 Card=63 Bytes=1260)
18 17 TABLE ACCESS (BY INDEX ROWID) OF 'SEGMENTATION_QUERY_VALUES' (Cost=3 Card=7 Bytes=91)
19 18 INDEX (RANGE SCAN) OF 'SEG_QUERY_VALUES_PK' (UNIQUE) (Cost=2 Card=15)
20 17 TABLE ACCESS (FULL) OF 'COUNTRY' (Cost=2 Card=120 Bytes=840)
21 16 TABLE ACCESS (FULL) OF 'CONTACT_COUNTRY1' (Cost=643 Card=2199855 Bytes=19798695)
22 2 HASH JOIN (Cost=2174 Card=645445 Bytes=38726700)
23 22 SORT (UNIQUE)
24 23 TABLE ACCESS (FULL) OF 'SEGMENTATION_USER_COUNTRY_MAP' (Cost=5 Card=43 Bytes=473)
25 22 TABLE ACCESS (FULL) OF 'CONTACT_VALUES1' (Cost=2151 Card=1907737 Bytes=93479113)
=====================================================
Execution Plan -SLOW
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=8751 Card=1 Bytes=73 )
1 0 SORT (AGGREGATE)
2 1 HASH JOIN (SEMI) (Cost=8751 Card=14477 Bytes=1056821)
3 2 MERGE JOIN (Cost=8583 Card=89527 Bytes=5550674)
4 3 TABLE ACCESS (BY INDEX ROWID) OF 'CONTACT_VALUES1' ( Cost=826 Card=1852109 Bytes=90753341)
5 4 INDEX (FULL SCAN) OF 'CONTACT_VALUES1_PK' (UNIQUE) (Cost=26 Card=1852109)
6 3 SORT (JOIN) (Cost=7757 Card=89527 Bytes=1163851)
7 6 VIEW (Cost=7454 Card=89527 Bytes=1163851)
8 7 INTERSECTION
9 8 SORT (UNIQUE)
10 9 INDEX (FAST FULL SCAN) OF 'CONTACT_VALUES1_PK' (UNIQUE) (Cost=5 Card=1852109 Bytes=11112654)
11 8 INTERSECTION
12 11 SORT (UNIQUE)
13 12 HASH JOIN (Cost=640 Card=250676 Bytes=7269604)
14 13 HASH JOIN (Cost=6 Card=28 Bytes=560)
15 14 TABLE ACCESS (BY INDEX ROWID) OF 'SEGMENTATION_QUERY_VALUES' (Cost=3 Card=1 Bytes=13)
16 15 INDEX (RANGE SCAN) OF 'SEG_QUERY_VALUES_PK' (UNIQUE) (Cost=2 Card=2)
17 14 TABLE ACCESS (FULL) OF 'COUNTRY' (Cost =2 Card=120 Bytes=840)
18 13 TABLE ACCESS (FULL) OF 'CONTACT_COUNTRY1 ' (Cost=628 Card=2135370 Bytes=19218330)
19 11 SORT (UNIQUE)
20 19 HASH JOIN (Cost=640 Card=89527 Bytes=25962 83)
21 20 HASH JOIN (Cost=6 Card=10 Bytes=200)
22 21 TABLE ACCESS (BY INDEX ROWID) OF 'SEGMENTATION_QUERY_VALUES' (Cost=3 Card=1 Bytes=13)
23 22 INDEX (RANGE SCAN) OF 'SEG_QUERY_VALUES_PK' (UNIQUE) (Cost=2 Card=2)
24 21 TABLE ACCESS (FULL) OF 'COUNTRY' (Cost =2 Card=120 Bytes=840)
25 20 TABLE ACCESS (FULL) OF 'CONTACT_COUNTRY1 ' (Cost=628 Card=2135370 Bytes=19218330)
26 2 TABLE ACCESS (FULL) OF 'SEGMENTATION_USER_COUNTRY_MAP'
(Cost=5 Card=45 Bytes=495)

SQL Tuning- slow query on GL_BALANCES- Explain plan provided

Hi- I really need some help here.
The following SQL statement has been identified to perform poorly.
It currently takes from 2-3 minutes to execute. I see it is because GL_BALANCES has so many rows.
Is there any way around this? Explain and info below. Thanks gurus!
This is the SQL statement:
SELECT DISTINCT GLB.CODE_COMBINATION_ID CCID
FROM gl_balances GLB, gl_code_combinations GCC
WHERE GLB.ACTUAL_FLAG = 'A'
AND GLB.Last_Update_Date > to_date('11-JAN-2010','DD-MON-YYYY')
AND GLB.code_combination_id = GCC.code_combination_id
AND EXISTS (
              SELECT 1
              FROM fnd_flex_value_sets A, fnd_flex_values B
              WHERE A.flex_value_set_name = 'XXX_XXX'
              AND UPPER(B.ATTRIBUTE3) = 'APPORTIONMENT'
              AND A.flex_value_set_id = b.flex_value_set_id
              AND GCC.segment11 = b.flex_value
           );The version of the database is 11.1.0.7.
These are the parameters relevant to the optimizer:
NAME TYPE VALUE
optimizerautostats_job boolean FALSE
optimizerextended_cursor_sharing_r string NONE
el
optimizer_capture_sql_plan_baselines boolean FALSE
optimizer_dynamic_sampling integer 2
optimizer_features_enable string 11.1.0.7
optimizer_index_caching integer 0
optimizer_index_cost_adj integer 100
optimizer_mode string ALL_ROWS
optimizer_secure_view_merging boolean FALSE
optimizer_use_invisible_indexes boolean FALSE
NAME TYPE VALUE
optimizer_use_pending_statistics boolean FALSE
optimizer_use_sql_plan_baselines boolean TRUE
SQL> show parameter db_file_multi
NAME TYPE VALUE
db_file_multiblock_read_count integer 128
SQL> show parameter db_block_size
NAME TYPE VALUE
db_block_size integer 8192
SQL> show parameter cursor_sharing
NAME TYPE VALUE
optimizerextended_cursor_sharing_r string NONE
el
cursor_sharing string EXACT
select
2 sname
3 , pname
4 , pval1
5 , pval2
6 from
7 sys.aux_stats$;
SNAME PNAME PVAL1
PVAL2
SYSSTATS_INFO STATUS
COMPLETED
SYSSTATS_INFO DSTART
09-02-2006 14:35
SYSSTATS_INFO DSTOP
09-02-2006 14:35
SNAME PNAME PVAL1
PVAL2
SYSSTATS_INFO FLAGS 1
SYSSTATS_MAIN CPUSPEEDNW 451.262136
SYSSTATS_MAIN IOSEEKTIM 10
SNAME PNAME PVAL1
PVAL2
SYSSTATS_MAIN IOTFRSPEED 4096
SYSSTATS_MAIN SREADTIM
SYSSTATS_MAIN MREADTIM
SNAME PNAME PVAL1
PVAL2
SYSSTATS_MAIN CPUSPEED
SYSSTATS_MAIN MBRC
SYSSTATS_MAIN MAXTHR
SNAME PNAME PVAL1
PVAL2
SYSSTATS_MAIN SLAVETHR
13 rows selected.
SQL> explain plan for
2 SELECT DISTINCT GLB.CODE_COMBINATION_ID CCID
3 FROM gl_balances GLB, gl_code_combinations GCC
4 WHERE GLB.code_combination_id = GCC.code_combination_id
5 AND GLB.ACTUAL_FLAG = 'A'
6 AND GLB.Last_Update_Date > '11-JAN-2010'
7 AND EXISTS (SELECT 1
8 FROM fnd_flex_value_sets A, fnd_flex_values B
9 WHERE A.flex_value_set_id = b.flex_value_set_id
10 AND A.flex_value_set_name = 'XXX_XXX'
11 AND UPPER(B.ATTRIBUTE3) = 'APPORTIONMENT'
12 AND GCC.segment11 = b.flex_value);
Explained.
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 1839014065
| Id | Operation | Name | Rows | By
tes | Cost (%CPU)| Time |
PLAN_TABLE_OUTPUT
| 0 | SELECT STATEMENT | | 4102 |
296K| 955K (3)| 03:11:03 |
| 1 | HASH UNIQUE | | 4102 |
296K| 955K (3)| 03:11:03 |
|* 2 | HASH JOIN | | 4102 |
296K| 955K (3)| 03:11:03 |
| 3 | NESTED LOOPS | | |
| | |
PLAN_TABLE_OUTPUT
| 4 | NESTED LOOPS | | 23907 | 1
354K| 2598 (1)| 00:00:32 |
| 5 | NESTED LOOPS | | 1 |
45 | 5 (0)| 00:00:01 |
| 6 | TABLE ACCESS BY INDEX ROWID| FND_FLEX_VALUE_SETS | 1 |
28 | 2 (0)| 00:00:01 |
|* 7 | INDEX UNIQUE SCAN | FND_FLEX_VALUE_SETS_U2 | 1 |
PLAN_TABLE_OUTPUT
| 1 (0)| 00:00:01 |
|* 8 | TABLE ACCESS BY INDEX ROWID| FND_FLEX_VALUES | 1 |
17 | 3 (0)| 00:00:01 |
|* 9 | INDEX RANGE SCAN | FND_FLEX_VALUES_N2 | 53 |
| 1 (0)| 00:00:01 |
|* 10 | INDEX RANGE SCAN | GL_CODE_COMBINATIONS_N11 | 25427 |
| 106 (1)| 00:00:02 |
PLAN_TABLE_OUTPUT
| 11 | TABLE ACCESS BY INDEX ROWID | GL_CODE_COMBINATIONS | 18664 |
236K| 2593 (1)| 00:00:32 |
|* 12 | TABLE ACCESS FULL | GL_BALANCES | 1022K|
15M| 952K (3)| 03:10:32 |
Predicate Information (identified by operation id):
PLAN_TABLE_OUTPUT
2 - access("GLB"."CODE_COMBINATION_ID"="GCC"."CODE_COMBINATION_ID")
7 - access("A"."FLEX_VALUE_SET_NAME"='SSA_SGL')
8 - filter(UPPER("B"."ATTRIBUTE3")='APPORTIONMENT')
9 - access("A"."FLEX_VALUE_SET_ID"="B"."FLEX_VALUE_SET_ID")
10 - access("GCC"."SEGMENT11"="B"."FLEX_VALUE")
12 - filter("GLB"."LAST_UPDATE_DATE">TO_DATE(' 2010-01-11 00:00:00', 'syyyy-mm
-dd hh24:mi:ss') AND
"GLB"."ACTUAL_FLAG"='A')
30 rows selected.

As per the other replies, you've not really given enough information to go on - what are you trying to achieve, versions, etc.
On my old apps 11.5.8 system, the explain plan for your query uses GL_CODE_COMBINATIONS_U1 rather than a full scan of gl_code_combinations.
Check your stats are up to date (select table_name, num_rows, last_analyzed from dba_tables where ...)
See if you can also use period_name and/or period_set_name (or period_num) from GL_Periods rather than period_year (i.e. use P_YEAR to lookup the period_name/period_set_name/period_num from gl_periods). It might be faster to do per period and then consolidate for the whole year, as there are indexes on gl_balances for columns period_name, period_set_name, period_num.
regards, Ivan

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

Explain Plan Diff not available yet on Mac ?

Hi,
I followed the Online tutorial for the new Explain Plan Diff feature, however when I right-click the tab of the auto-trace no menu appears at all.
Am I doing something wrong or is this feature not yet available on the Mac version or has it been forgotten ?
I have this version:
Oracle SQL Developer 3.0.02
Version 3.0.02
Build MAIN-02.83
Copyright © 2005,2010 Oracle. All Rights Reserved.
IDE Version: 11.1.1.4.37.58.80
Product ID: oracle.sqldeveloper
Product Version: 11.1.2.02.83
jdk 1.6.0_22
thanks, Arjan

Although I don't have a native Mac or Linux environment to test this, the context menus for the various worksheet tabs (Query Results / Autotrace / Explain Plan) have problems. I tried the following using a fresh install of SQL Dev 3.0 EA2 (including JRE 1.6.0_11):
1) VNC between two Windows XP boxes. Context menus work fine.
2) VNC (RealVNC 4.1.3 or TightVNC 2.0.2 clients) from Windows XP to Linux (Xvnc 4.0). Context menus do not appear.
3) Tarantella (Sun Secure Global Desktop Native Client [4.31.953]) from Windows XP to Linux. Context menus do not appear.
Finally, I tried the SQL Dev 2.1.1.64.65 on the OTN Developer Days image (OEL 5) under Sun Virtual Box on my XP box. No context menus.

Able to execute a query in TOAD but can't ceate explain plan

Hi,
I can execute a query in TOAD which uses table from other schema. I have created the synonym and given the rights on it.
But when I try to create explain plan using TOAD: I get Ora-00942:Table or view does not exist.
Any suggestions..
Thanks..

user8941550 wrote:
But if I just try
Explain Plan for
select t.xml_msg_text
from xml_tbl t
THen this works.That will have to be executed as a script in TOAD, which essentially shells out to use SQL*Plus and capture the output, so it's not Toads in-built explain plan.
In another schema I can generate the plan.So that other schema has been set up with toads explain plan table.
In TOAD look in Database -> Administer -> Server Side Objects Wizard
and follow that through to create the necessary toad objects on the server.

Explain plan for running query

Hi everyone,
I come to know how to generate explain plan for a given query by giving
Explain plan for select * fro emp;
Consider a query running for 5 hrs in a session and i want to genrate explain plan for that current query in its 4th hour i dont know the sql as well
all the steps by step would be much apppreciated
like finding Current SQL then so on
Thanks
Shareef

912856 wrote:
Hi everyone,
I come to know how to generate explain plan for a given query by giving
Explain plan for select * fro emp;
Consider a query running for 5 hrs in a session and i want to genrate explain plan for that current query in its 4th hour i dont know the sql as well
all the steps by step would be much apppreciated
like finding Current SQL then so on
Thanks
ShareefYOu can also use dbms_xplain to generate plan used in v$sql. like for example
SQL>SELECT SQL_ID, CHILD_NUMBER FROM V$SQL WHERE SQL_TEXT LIKE 'select * from em%';
SQL_ID CHILD_NUMBER
6kd5fkqdjb8fu 0
SQL>SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('6kd5fkqdjb8fu',0,'ALLSTATS'));If you need the actual tuntime statistics used by sql statement then you need to put hint /*+ gather_plan_statistics */ in sql ststement, something like
select /*+ gather_plan_statistics */ * from emp;
and then generate the explain plan for this
Have a look
http://hoopercharles.wordpress.com/2010/03/01/dbms_xplan-format-parameters/
select * from table(dbms_xplan.display_cursor(null,null,'ALLSTATS LAST'));

Not Understanding the filter in Explain Plan - filter(NULL IS NOT NULL)

Hi All,
Request your help in understanding the below scenario. (I am not aware of teh application and table details. Just trying to help my friend)
SQL> conn
Enter user-name: [email protected]
Enter password:
Connected.
SQL> select * from v$version;
BANNER
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bi
PL/SQL Release 10.2.0.3.0 - Production
CORE    10.2.0.3.0      Production
TNS for Linux: Version 10.2.0.3.0 - Production
NLSRTL Version 10.2.0.3.0 - Production
--Checking the count in PO_LINES
SQL> select count(*) from po_lines;
COUNT(*)
         0
--PO_LINES is a synonym
SQL> select object_type,owner from dba_objects where object_name = 'PO_LINES';
OBJECT_TYPE         OWNER
SYNONYM             APPS
--The synonym is pointing to PO.PO_LINES_ALL
SQL> select * from user_synonyms where synonym_name = 'PO_LINES';
SYNONYM_NAME                   TABLE_OWNER                    TABLE_NAME                     DB_LINK
PO_LINES                       PO                             PO_LINES_ALL
--But when counting PO.PO_LINES_ALL I am getting different result
SQL> select count(*) c from po.po_lines_all;
         C
      8828
--Explain plan of teh original query is
SQL> explain plan for
2 select
3 * from po_lines;
Explained.
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
| Id | Operation          | Name         | Rows | Bytes | Cost (%CPU)|
|   0 | SELECT STATEMENT   |              |     1 |   252 |     0   (0)|
|* 1 | FILTER            |              |       |       |            |
|   2 |   TABLE ACCESS FULL| PO_LINES_ALL | 8796 | 2164K|   106   (4)|
Predicate Information (identified by operation id):
   1 - filter(NULL IS NOT NULL)
--Now the object PO.PO_LINES_ALL is TABLE, not an mview.
SQL> select object_type,owner from dba_objects where object_name = 'PO_LINES_ALL';
OBJECT_TYPE         OWNER
TABLE               POSeek your help in understanding what is happening here.
Thanks in Advance,
jeneesh

Next time, prefix with APPS. when you show us the explain plan:
SQL> explain plan for
2 select
3 * from apps.po_lines; -- added the prefix of owner.Just like you prefixed with PO. when you showed us the query on PO_LINES_ALL. It ensures that you are using the synonym which you showed us.
Btw. PO_LINES_ALL, could still be a VIEW given your overview of the situation.
Anyway a filter "NULL IS NOT NULL" is indicative that the optimizer performed something called semantic query optimization (SQO).
SQO is the process of deducing new predicates based upon a) existing predicates in your query (which there is none), b) added predicates to your query (eg. by a VPD policy function), and c) declared constraints on the tables invovled in your query.
A typical example of when a "NOT is NOT NULL" predicate will show up is when for instance in the EMP table there is a declared constraint on EMPNO like this:
check(EMPNO > 0)And your query would hold a predicate that is inconsistent with the constraint, for instance like this:
select *
from EMP
where EMPNO <= 0Oracle will deduce that EMPNO cannot be both greater than zero (constraint) as well as smaller than or equal to zero (your query predicate), and will transform the query into:
select *
from EMP
where EMPNO <= 0
and NULL is NOT NULLThus preventing accessing the EMP table all together, and immediately returning this query with no data found.
Edited by: Toon Koppelaars on Mar 15, 2010 7:17 AM

Reading explain plan

Hi
I need some help with explain plan...tried some documents but didnt get the clarity...here is the query...
explain plan for
select ename,dname,grade
from emp,dept,salgrade
where emp.deptno=dept.deptno
and emp.sal between salgrade.losal and salgrade.hisal;
and here is the explain plan for this query..
PLAN_TABLE_OUTPUT
| Id | Operation | Name | Rows | Bytes | Cost |
| 0 | SELECT STATEMENT | | | | |
| 1 | NESTED LOOPS | | | | |
| 2 | NESTED LOOPS | | | | |
| 3 | TABLE ACCESS FULL | SALGRADE | | | |
|* 4 | TABLE ACCESS FULL | EMP | | | |
| 5 | TABLE ACCESS BY INDEX ROWID| DEPT | | | |
|* 6 | INDEX UNIQUE SCAN | PK_DEPT | | | |
PLAN_TABLE_OUTPUT
Predicate Information (identified by operation id):
4 - filter("EMP"."SAL"<="SALGRADE"."HISAL" AND "EMP"."SAL">="SALGRADE"
."LOSAL")
6 - access("EMP"."DEPTNO"="DEPT"."DEPTNO")
Note: rule based optimization
21 rows selected.
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE
1 0 COLLECTION ITERATOR (PICKLER FETCH) OF 'DISPLAY'
[i suppose it will remove all the spaces....so sorry .... :-( ]
now i have some questions regarding this like...
1. wat does these * mean with 4 and 6
2. how we come to know that which part got executed first and others after that.....as we draw a tree to represent all the steps....
3. wat is this Predicate Information
4. wat info is given at the last titled "Execution Plan"
please help
thanks
Sidhu

Sidhu,
1. wat does these * mean with 4 and 6It means that predicates are applied during this step. You'll see that there is a 4 and a 6 in the predicate informatiion, to specify the actual predicates being applied. The star is to indicate the presence of a predicate.
2. how we come to know that which part got executed
first and others after that.....as we draw a tree to
represent all the steps....This example is taken from an AskTom thread. In this thread he described in great detail how such a tree should be read. I cannot do it better.
3. wat is this Predicate InformationThe filters that are applied to restrict the result set.
4. wat info is given at the last titled "Execution
Plan"You were probably autotracing the 'select * from table(dbms_xplan.display)' itself. So this section is not relevant.
Regards,
Rob.

Query with diff. explain plans

Similar Messages

Maybe you are looking for