| Follow up by mail | Click here |
| Subject: | Verifing thoughts on FULL TABLE scan |
| Author: | Tim Boles, United States |
| Date: | Sep 22, 2009, 345 days ago |
| Os info: | Linux RedHat 5 |
| Oracle info: | 10.2.0.5 |
| Message: | The developers have come to me requesting help on a query that is taking exceptionally long (well more than a minute) to run. This is above their requirements and they want to know how to make it work better. Looking at the query I find that they have thrown in a function within their WHERE clause. I believe that this is the problem. I am trying to figure out the best way to approach this...which I think is probably creating a view to accomplish the same task as the function.
They are using Java to dynamically create this SQL and the number of times USER_HITS_ON_SR is called within ORs can be more than 1. This is really ugly code in my humble opinion but I am looking for hints on how to make it more elegant. Thanks for your input. Regards Tim Boles |
| Goto: | Reply - Top of page |
| Subject: | Re: Verifing thoughts on FULL TABLE scan |
| Author: | Philip Wisse, Netherlands |
| Date: | Sep 22, 2009, 345 days ago |
| Score: |    |
| Message: | Hi Tim,
The technique is to create a snapshot (materialized view) as follows:
And then the function can be rewritten to use this MV. Only you have to somehow refresh your mv now and then. Regards, Philip |
| Your rating?: | This reply is Good Excellent |
| Goto: | Reply - Top of page |
| Subject: | Re: Verifing thoughts on FULL TABLE scan |
| Author: | Tim Boles, United States |
| Date: | Sep 22, 2009, 345 days ago |
| Message: | That is an interesting approach. I will have to check on how often those tables are getting updated. Thanks for your input....I will definitely look into it.
Regards Tim Boles |
| Your rating?: | This reply is Good Excellent |
| Goto: | Reply - Top of page |
| Subject: | Re: Verifing thoughts on FULL TABLE scan |
| Author: | Philip Wisse, Netherlands |
| Date: | Sep 22, 2009, 345 days ago |
| Message: | Hi Tim,
First let me catch up on the create table scripts:
|
| Your rating?: | This reply is Good Excellent |
| Goto: | Reply - Top of page |
| Subject: | Re: Verifing thoughts on FULL TABLE scan |
| Author: | Philip Wisse, Netherlands |
| Date: | Sep 22, 2009, 345 days ago |
| Message: | Hello again,
Next same technique on the distinct statement:
Now the statement becomes:
As you can see now an index is missing on the created_on column:
So that's about it. |
| Your rating?: | This reply is Good Excellent |
| Goto: | Reply - Top of page |
| Subject: | Re: Verifing thoughts on FULL TABLE scan |
| Author: | Philip Wisse, Netherlands |
| Date: | Sep 22, 2009, 345 days ago |
| Score: |    |
| Message: | An exception needs to be added in the function when no data found |
| Your rating?: | This reply is Good Excellent |
| Goto: | Reply - Top of page |
| Subject: | Re: Verifing thoughts on FULL TABLE scan |
| Author: | Tim Boles, United States |
| Date: | Sep 22, 2009, 345 days ago |
| Message: | Philip,
Thanks for your input. I will take a hard look at it tomorrow and do some testing to see how the explain plan and timing looks. I really appreciate your effort and words of advice. Regards Tim |
| Your rating?: | This reply is Good Excellent |
| Goto: | Reply - Top of page |
| Subject: | Re: Verifing thoughts on FULL TABLE scan |
| Author: | Philip Wisse, Netherlands |
| Date: | Sep 23, 2009, 344 days ago |
| Message: | Hi Tim,
It's getting better all the time. It could be a textbook example. If all underlying tables have 1) primary keys and 2) snapshot logs and 3) the distinct is recoded as 'group by' then on both snapshots the refresh method can be set to 'on commit'. This will cost some performance on dml operations, but it will resolve the refresh (and consistancy) problem. |
| Your rating?: | This reply is Good Excellent |
| Goto: | Reply - Top of page |