I’m sorry, I don’t do query tuning on the blog. It’s not a very good use of the limited amount of time I have for the Oracle community.

A general strategy you need to consider: Look at the list of tables, and the list of join conditions between tables.

Think about which table would return the smallest amount of data if you used the available predicates on that table.

Decide which table should be the next table, based on how the data size would change if you joined to it, and the join mechanism you would probably want to use to get there. Repeat for each table in turn.

As you move from table to table, an important general strategy is to try to keep the volume of the result set as small a possible.

For a more detailed strategy, Dan Tow’s book on SQL Tuning is probably the best option.

thanks for the time. I am sorry , I should have send you the complete execution plan, the plan was showing a full table acess as the first step , then a buffer sort and then a Merge join cartesian.
After trying different things it was corrected by creating a index so that the full table scan was avoided which removed the buffer sort and the also removed the Merge join cartesian.

thanks

Sorry I missed your question back in 2007. I’ve just added a note to the end of the article which probably answers your question. In 9i there is a multiplication involved that should not be there.

Himanshu,
There isn’t enough information in your question for me to give a sensible answer. I don’t think you are doing a merge join cartesian, though, if your first step is a buffer sort.

I also have a situation where the buffer is returning 284395648 rows , and in the TKPROF output it is the first step. Any idea how it can be avoided as it takes around 20 minutes for the query to execute.

thanks