First, a little friendly advice. When communicating on blogs, Internet forums, and other places on the Internet where information is shared with people from many different countries with primary languages other than English, please refrain from using uncommon abbreviations for words. Text message abbreviations, such as “u”, do not translate well into languages other than English, making it difficult for non-native English readers to understand and assist with any problems that you share with the world through blogs and Internet forums.

Second, it appears that you have generated four execution plans, one of which has a calculated cost that is roughly 10 times higher than the calculated cost that appears in the other execution plans. The calculated cost is used by the optimizer when developing the execution plan. While the calculated cost is intended to indicate to the Oracle query optimizer the approximate amount of time required to execute a particular portion of the execution plan (see http://jonathanlewis.wordpress.com/2006/12/11/cost-is-time/ ), that calculated cost estimate may be miscalculated due to various factors including out of date object statistics, missing or inappropriate histograms, bind variable peeking / or not peeking, silly mistakes in queries (such as unnecessary implicit data type conversions, unnecessary using a function such as TRUNC on a column in a WHERE clause, etc.), inappropriate system (CPU) statistics, etc.

While it is important for the query optimizer to reasonably acurately calculate the cost of an execution plan, it makes little difference if the cost of a full table scan is 1, 63,295, or 1,000,000,000 if a full table scan is the only “legal” method to retrieve the data from the table due to missing indexes, inappropriate indexes (such as those with a high clustering factor that are not very selective), or indexes that cannot be used due to a mistake in the query (implicit data type conversion, using a function such as TRUNC on the indexed column, etc.).

The “Predicate Information” section of an execution plan (found in execution plans when generated with recent Oracle client versions and Oracle Database versions) may provide valuable information regarding mistakes in a particular query that resulted in an unexpected operation in an execution plan.

In short, do not tune by attempting to make a query’s calculated cost as low as possible. The calculated cost is only an estimate, and if that estimate does not reflect the actual resource utilization to perform an operation in an execution plan, the calculated cost is just a number that is meaningless for improving efficiency. Use actual timing (a 10046 trace is great for such timing), run time statistics, etc. rather than the calculated cost.

-------------------------------------------------------------------
| Id  | Operation          | Name         | Rows  | Bytes | Cost  |
-------------------------------------------------------------------
|   0 | SELECT STATEMENT   |              |     1 |   155 |  6509 |
|   1 |  NESTED LOOPS      |              |     1 |   155 |  6509 |
|   2 |   TABLE ACCESS FULL| TANCASE_INFO |     1 |   149 |  6508 |
|   3 |   INDEX UNIQUE SCAN| PK_CASE_ID   |     1 |     6 |     1 |
-------------------------------------------------------------------

-----------------------------------------------------------------
| Id  | Operation         | Name        | Rows  | Bytes | Cost  |
-----------------------------------------------------------------
|   0 | SELECT STATEMENT  |             |     2 |   302 | 63295 |
|   1 |  TABLE ACCESS FULL| TANWOB_EVNT |     2 |   302 | 63295 |
-----------------------------------------------------------------

------------------------------------------------------------
| Id  | Operation         | Name   | Rows  | Bytes | Cost  |
------------------------------------------------------------
|   0 | SELECT STATEMENT  |        |     1 |    56 |  2978 |
|   1 |  TABLE ACCESS FULL| TANWOB |     1 |    56 |  2978 |
------------------------------------------------------------

-------------------------------------------------------------
| Id  | Operation         | Name    | Rows  | Bytes | Cost  |
-------------------------------------------------------------
|   0 | SELECT STATEMENT  |         |     1 |    90 |  3988 |
|   1 |  TABLE ACCESS FULL| TANCASE |     1 |    90 |  3988 |
-------------------------------------------------------------

Can u please some one help me, to reduce the cost.

Regards
Ravindra

My intention was not to say ALWAYS IGNORE THE COST. But as I mentioned as a question in my earlier response, is looking at the cost right way to start the performance tuning process ? I believe not.

I do wonder about the un-named fan who posted the following on June 14, 2002:
“Comparing the same query using COST is perfect legitimate because that is what the COST is for. What we expect is the optimizer to permute all possible combinations and pick up the plan with the least cost. If you could rewrite the same SQL to get a cheaper cost theoretically it should be faster. If it is not I guess it is an optimizer bug. Also if the COST is not just based on logical reads but on the CPU, then comparing the SQL in the same instance is still legitimate.”

And then the follow-up by apparently the same un-named fan on June 27, 2002:
“Ok, let me rephrase this again. You can compare the same SQL when you are trying to tune that SQL. If you can tune the SQL to get a lower cost than whatever CBO comes up with, it should perform better (lets not get to the run time because it depends on the physical characteristics like file system, disk speed etc.) I’m not wishing CBO to behave like this but thats how CBO works.

Cost CANNOT be treated as a random number. Till 8i Cost is a metric based on the I/O (logical reads) and starting 9i there is an option to make the Cost based on CPU also along with I/O (calling the API DBMS_STATS.GATHER_SYSTEM_STATS)

The very fact COST is exposed is to give the user an idea about the unit of work or resource it is estimating to use for the SQL…

I’m not saying all the above after reading from a manual. I’ve been working on CBO for couple of years and I’m saying the above from my experience. I can also reiterate, if you can come up a tuned SQL where the COST is cheaper than the default CBO plan, then it is a CBO bug. It is not what I wish, it is how it is.”

One has to wonder what that un-named person had read, and possibly what else that person had authored based on their experience. Apparently, some of that information is still being taught or read some where.

From the first followup in the thread:
“When we get a query, we come up with lots of plans. Each step of the plan is assigned some relative cost. At the end, we apply a function to derive the total cost of that query for each plan. These costs (which are ONLY visible to the optimizer) can be compared as they are for the same exact SQL using the same exact environment.”

I think that it should be stated that the calculated cost is compared at *each* step of the execution plan, and that the lowest calculated cost at that stage of the plan is selected. The selection of the lowest cost-based decision at one step in a plan can cause later steps in the plan to generate higher calculated costs, such that the total cost output for the query could be significantly greater than if the cost-based optimizer selected a higher cost join or access path earlier in the execution plan. Thus, for queries with several row sources (tables, indexes, or previous join results), you probably should not compare the costs that are output with an execution plan when a different join order is used or when a different access path is selected.

Of course, the cost is time argument does make some sense (to me) at individual stages of an execution plan.

Unfortunately, those who understand what is the cost, what is CBO and what is behind CBO’s calculations are far less compared to those who don’t. Hence there is a risk of such statements easily being (incorrectly) translated as “Cost is the (only) “Holy Grail” to performance tuning in oracle”. Even if the forum post mentioned here, it should be noted that the 2 query plans have been generated by 2 queries that are not same. Now, would it be right to start the tuning process by comparing the costs (and trying to figure out how they are calculated) or start tuning process by identifying WHY does the query need to be hinted in the first place (if hinted query generates more attractive plan) ?
An old asktom thread comes to mind (and I agree with Tom):
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:313416745628

A decrease in the estimated cost probably means a decrease in the estimated execution time, and might mean a decrease in the actual execution time. I am reminded of the following blog article:
http://jonathanlewis.wordpress.com/2006/12/11/cost-is-time/

Timur, good point. By the way, I did not spent much time looking at the explain plans that are included in this blog article until you stated that the join order is exactly the same. I then thought that the plans were “interesting” since they do appear to be different on first glance.

“test the performance to see which execution plan is more efficient, rather than guessing.” Very true.

Does decrease in cost means decrease in elapsed time/execution time of the query?