Based on the excellent comments in the Quiz post, we have some clever cookies out there I guess the first thing to point out is that based in the basic scenario provided, the index shouldn’t ordinarily be continually growing in this fashion. Although the index values are monotonically increasing, the deletions are leaving behind fully emptied leaf blocks which [...]![]()
I received an email recently that had a nice example of what can potentially go wrong with an index. Let’s first create a simple table with a unique index and populate it with 200,000 rows (following demo run on 11.2.0.1): So far, everything is as expected. With have an index with 200,000 rows that currently has [...]![]()
Excellent !! This quiz created quite a bit of debate and it was nice to sit back and read some interesting discussions. The Clustering Factor is basically the measurement of how well aligned the data in the underlining table is in relation to the index and is the number of table related I/Os required to read the entire table via a [...]![]()
In the same article and book where the erroneous claims regarding the BLKS_GETS_PER_ACCESS were made, we also find the following recommendation: “Another rebuild condition would be cases where deleted leaf nodes comprise more than 20% of the index nodes“. This is a very common claim however no matter how often it might be [...]![]()
A recent question on the database OTN forum and a previous request by Charles Hooper that I cover some basic indexing concepts for newbie’s who might be confused by “dubious” information out there in internet land has prompted me to discuss the BLKS_GETS_PER_ACCESS metric, available in INDEX_STATS after an analyze validate structure operation. The OTN [...]![]()
Recent comments
17 weeks 3 days ago
27 weeks 2 days ago
29 weeks 1 hour ago
32 weeks 1 day ago
34 weeks 3 days ago
44 weeks 3 hours ago
45 weeks 3 days ago
46 weeks 4 days ago
46 weeks 5 days ago
49 weeks 3 days ago