Thanks for your reply.

Oracle’s cardinality = 15458
Oracle’s number of rows input = 309157
So Oracle’s selectivity = 15458 / 309157 = 0.05000049

Oracle has used the standard 5% for “column > unknown value” in this case.

However, cardinality estimate is off. My column is not null column with FBI on it (upper(column)) and no popular values.

Predicate is “col like :bindvar||’%'”. Bind value is within range.

    NewDensity:0.000015, OldDensity:0.000239 BktCnt:254, PopBktCnt:0, PopValCnt:0, NDV:67072
  Column (#41): SYS_NC00041$(
    AvgLen: 50 NDV: 67072 Nulls: 0 Density: 0.000015
    Histogram: HtBal  #Bkts: 254  UncompBkts: 254  EndPtVals: 255
    Card: Original: 309157.000000  Rounded: 15458  Computed: 15457.85  Non Adjusted: 15457.85

Cardinality = 0.000015 * 309157 = 4.637355 vs 15458 (computed by CBO)

Not sure what type of math I should do for a unbounded range…

Will try to figure out by going through your book. But, do you by any chance think this is a bug?

Appreciate your contribution to Oracle community,
Thanks!

Thanks for your time and Thanks for the comments too.

There’s lot of predicates on the given table and not particularly using any index and doing a full table scan. To add more, the query in the question is having problem only on monday after a table re-org (ofcourse stats has been gathered after rebuild) and rest of the days its back to normal. No change in plans and nothing, hence trying to cornering how the cost has been derived. Will further dig more.

I must say, I have been learning a lot with your blog and your nice book “CBO – fundamentals”, Thank you…

Regards
Suresh

It can take some time to work these things out, and it’s not a particularly interesting or educational task; so I only do it when I’m being paid to do it or puzzled by an example that’s appeared in a forum.

In your example there are two things that would make it harder to do: (a) every column has a histogram – so you might have to look at the histogram data in great detail, and (b) you haven’t told me what the predicates are that the optimizer will be evaluating at this point – and not that they may NOT be exactly the predicates you wrote in your initial query.

Would you able to help me in understanding the cardinality from the following output, how was 1642 derived?

SINGLE TABLE ACCESS PATH
  Single Table Cardinality Estimation for TRADE[T]
  Column (#2):
    NewDensity:0.000001, OldDensity:0.000001 BktCnt:5402, PopBktCnt:5402, PopValCnt:4, NDV:4
  Column (#105):
    NewDensity:0.000001, OldDensity:0.000001 BktCnt:5402, PopBktCnt:5402, PopValCnt:2, NDV:2
  Column (#55):
    NewDensity:0.000002, OldDensity:0.000002 BktCnt:2835, PopBktCnt:2835, PopValCnt:2, NDV:2
  Column (#1):
    NewDensity:0.000002, OldDensity:0.000002 BktCnt:254, PopBktCnt:0, PopValCnt:0, NDV:443488
  Column (#72):
    NewDensity:0.000001, OldDensity:0.000001 BktCnt:5402, PopBktCnt:5402, PopValCnt:2, NDV:4
  Column (#6):
    NewDensity:0.001419, OldDensity:0.002012 BktCnt:254, PopBktCnt:10, PopValCnt:5, NDV:682
  Column (#159):
    NewDensity:0.000003, OldDensity:0.000038 BktCnt:254, PopBktCnt:2, PopValCnt:1, NDV:310528
  Column (#16):
    NewDensity:0.000002, OldDensity:0.000005 BktCnt:254, PopBktCnt:10, PopValCnt:1, NDV:426496
  Column (#157):
    NewDensity:0.000001, OldDensity:0.000001 BktCnt:5402, PopBktCnt:5402, PopValCnt:3, NDV:4
  Column (#155):
    NewDensity:0.000215, OldDensity:0.001799 BktCnt:254, PopBktCnt:81, PopValCnt:13, NDV:3175
  Column (#4):
    NewDensity:0.000001, OldDensity:0.000001 BktCnt:5178, PopBktCnt:5178, PopValCnt:6, NDV:7
  ColGroup (#1, Index) IDX_TRD_DVP_FEX
    Col#: 1 2 5 8 53 60 73 105 108    CorStregth: -1.00
  ColGroup (#2, Index) IDXTRDTAX
    Col#: 1 2 55 68 72 105 135    CorStregth: 52038.16
  ColGroup (#8, Index) IDX_TRADE_FX
    Col#: 1 2 5 8 105 108    CorStregth: -1.00
  ColGroup (#5, Index) IDX$$_4B290002
    Col#: 2 6 154 155 156    CorStregth: 2298053781278.98
  ColGroup (#7, Index) FEXIGNOREEXCEPTION_712A0001
    Col#: 2 5 8 105 108    CorStregth: -1.00
  ColGroup (#6, Index) IDX_TRADE_COMM
    Col#: 2 4 5 153    CorStregth: -1.00
  ColGroup (#9, Index) IDX$$_50990001
    Col#: 6 7 12    CorStregth: -1.00
  ColGroup (#10, Index) TRADE_UK1
    Col#: 1 6 46    CorStregth: -1.00
  ColGroup (#3, Index) IDX$$_173D0004
    Col#: 6 159    CorStregth: 575.99
  ColGroup (#4, Index) IDX$$_4B2C0004
    Col#: 16 157    CorStregth: 4.00
  ColGroup Usage:: PredCnt: 4  Matches Full:  Partial:
  Table: TRADE  Alias: T
    Card: Original: 471074.000000  Rounded: 1642  Computed: 1641.93  Non Adjusted: 1641.93
  Access Path: TableScan
    Cost:  12436.31  Resp: 12436.31  Degree: 0
      Cost_io: 12338.00  Cost_cpu: 2113927982
      Resp_io: 12338.00  Resp_cpu: 2113927982

Thanks so much for explaining .I do have your book – cost based oracle -fundamentals, but I could not find the discussion on cost of unique index access ,but I do see some sort of discussion on it in chapter 11 . (nested loops).
Yes the blevel of the unique index which is a PK is 1 . you are absolutely correct .

Kindly point out where in the cost based oracle -fundamentals, I could see more details on this.
I have a hard copy and I might have skipped that section inadvertantely.

Regards.
Ajeet

I think this is an example covered in my book “Cost Based Oracle – Fundamentals”, but I can’t be completely certain since I don’t have all the information about your tables and indexes in front of me. The basic points, however, are this:

a) the orders_pk index looks like it might be the index on a primary key column
b) for index-only access on unique indexes the optimizer subtracts 1 from the normal index-only cost
c) for index access by nested loop the optimizeir subtracts 1 from the expected cost

I suspect from this that your index has a blevel of 1: so the cost of “select o_orderkey from orders where o_orderkey = {constant}” has a cost of 1, and the cost of accessing just the order key in the nested loop is zero.

What could be the possible reason of COST = 0 for unique index scan operation of the following query and plan. I am not able to understand the reason.
Could you please help.

sql_id=52a0skswvaqvk.
Current SQL statement for this session:
explain plan for select
count(*)
from
	orders,
        lineitem
where
	o_orderkey = l_orderkey
 
============
Plan Table
============
---------------------------------------------+-----------------------------------+
| Id  | Operation               | Name       | Rows  | Bytes | Cost  | Time      |
---------------------------------------------+-----------------------------------+
| 0   | SELECT STATEMENT        |            |       |       |   343 |           |
| 1   |  SORT AGGREGATE         |            |     1 |    10 |       |           |
| 2   |   NESTED LOOPS          |            |  583K | 5830K |   343 |  00:00:05 |
| 3   |    INDEX FAST FULL SCAN | PK_LINEITEM|  586K | 2932K |   294 |  00:00:05 |
| 4   |    INDEX UNIQUE SCAN    | PK_ORDERS  |     1 |     5 |     0 |           |
---------------------------------------------+-----------------------------------+
Predicate Information:
----------------------
4 - access("O_ORDERKEY"="L_ORDERKEY")
 
Content of other_xml column
===========================
  db_version     : 10.2.0.1
  parse_schema   : EMUDSS
  plan_hash      : 2594599139
  Outline Data:
  /*+
    BEGIN_OUTLINE_DATA
      IGNORE_OPTIM_EMBEDDED_HINTS
      OPTIMIZER_FEATURES_ENABLE('10.2.0.1')
      ALL_ROWS
      OUTLINE_LEAF(@"SEL$1")
      INDEX_FFS(@"SEL$1" "LINEITEM"@"SEL$1"("LINEITEM"."L_ORDERKEY" "LINEITEM"."L_LINENUMBER"))
      INDEX(@"SEL$1" "ORDERS"@"SEL$1" ("ORDERS"."O_ORDERKEY"))
      LEADING(@"SEL$1" "LINEITEM"@"SEL$1" "ORDERS"@"SEL$1")
      USE_NL(@"SEL$1" "ORDERS"@"SEL$1")
    END_OUTLINE_DATA
  */