• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 533
  • Last Modified:

Join optimization

How could I optimize this select?
select narusenigvd.narusenikod
from vlak, trasa, narusenigvd
where
vlak.dojezd >= to_date('01.03.2000 00:00','DD.MM.YYYY HH24:MI') and
vlak.denjizdy <= to_date('02.03.2000 00:00','DD.MM.YYYY HH24:MI') and
vlak.idvlak = trasa.idvlak and
trasa.idtrasa = narusenigvd.idtrasa;

Every attribute have his own index.

Here is plan of the select:
SELECT STATEMENT   Cost: 7152                                                  
  HASH JOIN                                                                    
    TABLE ACCESS FULL NARUSENIGVD                                              
    NESTED LOOPS                                                                
      TABLE ACCESS FULL VLAK                                                    
      TABLE ACCESS BY INDEX ROWID TRASA                                        
        INDEX RANGE SCAN TRASA_VLAK NON-UNIQUE                                  

Why there is full access to tables 'natusenigvd' and 'vlak'?
0
knill
Asked:
knill
1 Solution
 
rkogelheCommented:
Knill,

Sometimes the optimizer is just ornery and one has to ritually sacrifice old oracle cds to get it to do what you want.

I suspect in this case that the vlak scans are because oracle has decided that the date ranges -might- hit >20% of the rows regardless. From a human perspective it sure looks like we're only talking about a day here, but the oo thinks it might have to look at half the data.

One suggestion is to create histograms on the date columns, another is to add criteria to the date conditions to limit to "between" conditions. You probably know if

vlak.dojezd >= to_date('01.03.2000 00:00','DD.MM.YYYY HH24:MI') and
vlak.dojezd <= to_date('02.03.2000 00:00','DD.MM.YYYY HH24:MI') and
vlak.denjizdy >= to_date('01.03.2000 00:00','DD.MM.YYYY HH24:MI') and
vlak.denjizdy <= to_date('02.03.2000 00:00','DD.MM.YYYY HH24:MI')  

is also a valid condition...

The narusenigvd problem is probably caused by the full on vlak. It probably suspects it will need all the values in the narusenigvd table, in which case a hash is faster. It may also think that the table is relatively small.

If this doesn't help, consider posting the main optimizer statistics for the tables and join columns.

Regards,

Ryan
0
 
knillAuthor Commented:
I added the conditions and cost is naw 201.
Thank you.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Cloud Class® Course: CompTIA Cloud+

The CompTIA Cloud+ Basic training course will teach you about cloud concepts and models, data storage, networking, and network infrastructure.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now