Index is not using for this query

Question

I have this query and it doesn't use index. Can you put your suggestion please?
SELECT /*+ ORDERED USE_HASH(IC_GSMRELATION) USE_HASH(IC_UTRANCELL) USE_HASH(IC_SECTOR) USE_HASH(bt) */
/* cp */
bt.value value,
bt.tstamp tstamp,
ic_GsmRelation.instance_id instance_id
FROM
xr_scenario_tmp IC_GSMRELATION,
xr_scenario_tmp IC_UTRANCELL,
xr_scenario_tmp IC_SECTOR,
rg_busyhour_tmp bt
WHERE
bt.instance_id != -1
AND (IC_GSMRELATION.entity_id = 133)
AND (IC_GSMRELATION.parentinstance_id = ic_UtranCell.instance_id)
AND (IC_UTRANCELL.entity_id = 254)
AND (IC_UTRANCELL.parentinstance_id = ic_Sector.instance_id)
AND (IC_SECTOR.entity_id = 227)
AND (IC_SECTOR.parentinstance_id = bt.instance_id);
table : xr_scenario_tmp
entity_id          num
instance_id          num
parentinstance_id     num
localkey          varchar
indexes: 1. entity_id+instance_id
     2. entity_id+parentinstance_id
table : rg_busyhour_tmp
instance_id     notnull     num
tstamp          notnull     date
rank          notnumm     num
value               float
index: instance_id+tstamp+rank
thanks

Answer 1

user5797895 wrote:
Thanks for the update
1. I don't understand where to put {}. you meant in the forum page like below
Use the tag. Read the [FAQ|http://wiki.oracle.com/page/Oracle+Discussion+Forums+FAQ?t=anon] for more information. It's the link on the top right corner.
>
2. AROUND 8000 IN DEV MACHINE. BUT 1.5M IN PRODUCTION
It's a more or less useless exercise if you have that vast difference between the two systems. You need to test this thoroughly using a similar amount of data.
3.
Note: cpu costing is off, PLAN_TABLE' is old version
You need to re-create your PLAN_TABLE. That's the reason why important information is missing from your plans. It's the so called "Predicate Information" section below the execution plan and it requires the correct version of the plan table. Drop your current plan table and re-run in SQL*Plus on the server:
@?/rdbms/admin/utlxplan
to re-create the plan table.
Dynamic sampling doesn't alter the plan in any way no matter what sampling level I choose.
When I added Cardinality it switched from 1 full table scan and 2 index read
Can you post the statements with the hints included resp. just the first line including the hints used for the different attempts?
# WITH dbms_stats.gather_table_stats, without cardinality it uses indexes all the time.
How did you call DBMS_STATS.GATHER_TABLE_STATS, i.e. which parameter values where you using?
# After deleting the table stats performance improved back
All these different attempts are not really helpful if you don't say which of them was more effective than the other ones. That's why I'm asking for the "Predicate Information" section so that this information can be used to determine which of your tables might benefit from an indexed access path and which don't.
As already mentioned several times if you use SQL tracing as described in one of the links provided you could see which operation produces how many rows. This would allow to determine if it is efficient or not.
But given that you're doing all this with your test data it doesn't say much about the performance in your production environment.
4. whether GTT created with "ON COMMIT PRESERVE ROWS"?
YES - BUT DIFFERENT SESSIONS HAS DIFFERENT NUMBER OF ROWS
The question is, whether the number of rows differs significantly, if yes, then you shouldn't use the DBMS_STATS approach
5. neigher (48 sec. / 25 sec. run time) are sufficient, then what is the expected?
ACTUALLY I AM DOING IT IN DEVELOPMENT MACHINVE. IN PRODUCTION THE NUMBER OF ROWS ARE DIFFERENT. LAST TIME WHEN WE RELEASED THE
PATCH WITH THIS CODE, THE PERFORMANCE WAS BAD.
See 2., you need to have a suitable test environment. It's a more or less useless exercise if you only have a fraction of the actual amount of data.
Regards,
Randolf
Oracle related stuff blog:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/