This behaviour can be controlled with the no_invalidate option/parameter when you collect statistics.

LikeLike

]]>Just wondering if we collect stats during runtime on a table, will the same effect takes place when the query will be launched the second time.

Let say, if I see a query is slow and during runtime, I execute the stats for that table XXXX. After the stats collection is finished, do you think that the same query will be parsed again and the execution plan will change.

Pardon me, if you think this is not the correct place to ask the question.

LikeLike

]]>like to ask if you don’t mind. I was interested to find out how you center yourself and clear your

head prior to writing. I’ve had a tough time clearing my mind in getting my

ideas out. I truly do take pleasure in writing however it just seems

like the first 10 to 15 minutes are generally wasted just trying to figure out how

to begin. Any suggestions or tips? Appreciate it!

LikeLike

]]>You only need to access a branch block at each level they exist. So for an index with a HEIGHT of 3, that’s just the root branch block and an intermediate branch block. The number of branch blocks at each level is therefore of trivial consequence.

Being able to reduce the number of leaf blocks is where it can possibly matter (which of course in turn results in few necessary branch blocks).

LikeLike

]]>That’s correct and the next topic I’ll cover.

LikeLike

]]>Can you explain the following in detail

“during a typical index range scan, only one branch block is accessed for each level index branches exist. Unless we can reduce the number of branch blocks required at a specific level to just one branch block thereby reducing the height/blevel of an index (an extremely rare edge case)”

Do you mean that each access to a leaf block will need to access only one branch block regardless of the number of branch blocks present?

We can only see improvement if we reduce the blevel to 2 i.e there is no branch block ?

Thanks

LikeLike

]]>LikeLike

]]>LikeLike

]]>First, just need to be clear with some definitions. Don’t confuse index “entries” with “indexes”. There are a total of 10M index entries in this one index.

Regarding question 1), all index entries must be ordered within an index. It’s not possible and it would make no sense for an index to have index entries that are not logically ordered (just think how an index at the back of a book is always alphabetically ordered and think how how it would be use use the index if it wasn’t).

As such, then yes all index entries with the same indexed value would all be stored together within the leaf blocks. It’s possible to 1% of the index entries to use more than 1% of the index structure (if for example, the index entries are larger than average, if there’s more free space than usual in that part of the index, etc.), but the CBO can only assume even distribution of index values across leaf blocks (the issue with averages) and so the costings reflect this.

Regarding question 2), selectivity is basically the percentage of expected resultset. If you have 100 distinct values and assuming an even distribution of rows across those values (for each specific value, you get the same % of rows returned), then the selectivity is 1/100 or 1% of data. This is represented as 0.01 as this is use to multiply the total rows in order to get the expect cardinality. So total expected rows would by 10M x 0.01 = 100,000 rows.

Hope this makes sense.

LikeLike

]]>First of all thanks much for putting together this concept.

I have few doubts regarding mentioned example:

1) when you say:

” We also need to read approximately 1% of all the index leaf blocks in order to access all the index entries of interest. So that’s 20,000 (leaf blocks) x 0.01 = 200 leaf blocks in total. ”

I understand there are 20,000 x 500 = 10000000 indexes present.

But when you say we need to access approx. 1% of all index leaf blocks then mathematically you saying i.e. 20000 x .01 = 200 leaf blocks which will have 100000 (200 x 500).

Now my question here is, as per above calculations does that means indexes regarding value ‘ABCDE’ are accomodated right next to each other to support the fact that in 200 leaf blocks we will meet corresponding indexes of all ‘ABCDE’ rows i.e. 1,00,000 occurences of ‘ABCDE’ ??

Isn’t there a possibility that there might be a need of 250 leaf blocks for reading all concerned indexes ??

2) When you say:

” So the Clustering Factor is a crucial variable in how costly it would be to read the table via the index. The actual table access costs therefore are simply calculated as being the selectivity of the query (0.01 in our case) multiplied by the Clustering Factor of the associated index.

In this example, the Clustering Factor is indeed appalling with a value of 10,000,000 and the table access costs are therefore calculated as 0.01 x 10,000,000 = 100,000. ”

My question here is :

How the selectivity for 10 million rows with 100 as cardinality value is coming to .01 ?

I understand it should be .001 (cardinality / No of Rows x 100) =

(100 / 10000000 x 100) = .001

Please let me know your thoughts !!

Appreciating your contribution to spreading the knowledge.

Thanks,

Krishna

LikeLike

]]>LikeLike

]]>LikeLike

]]>LikeLike

]]>LikeLike

]]>LikeLike

]]>