I’ve a level 5 Statspack report from a real production 11.2.0.2 database with the following Top 5 Timed events section:
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 [...]![]()
I’ve been so busy lately, I just haven’t had any spare time to post. For now, the quick answer to the last quiz is that the second table was indeed an Index Organized Table (IOT). One of the nice benefits of an IOT is that when re-organised, unlike a Heap Table, all indexes remain valid, [...]![]()
OK, this quiz is a nice easy one, the lads at work got this without too much trouble. Normally, when you MOVE (re-org) a table, all the associated indexes become Unusable. As below: So the indexes are now all unusable .. However, I previously created another table called BOWIE that [...]![]()
As many have identified, the first thing to point out is that the two queries are not exactly equivalent. The BETWEEN clause is equivalent to a ‘>= and <=’ predicate, whereas the original query only had a ‘> and <’ predicate. The additional equal conditions at each end is significant. The selectivity of the original query is basically costed [...]![]()
I have a table that has 1M rows with dates that span 2000 days, all evenly distributed (so there are 500 rows per day for the mathematically challenged). All stats are 100% accurate and I have an index on the date column. OK, I now select 1 day’s worth of data: [...]![]()
Well done to everyone that got the correct answer Indeed, the subtle but significant difference between the two demos was that demo one created the table in a tablespace called USER_DATA with manual segment space management (with freelists/freelist groups set to 1), while demo two created the table in a tablespace called USER_DATA1 with automatic segment space management. [...]![]()
This one is a little different as it comes in the form of a demo (and about 1 minute to read) so you have to work a little I create table, index and sequence: I then create a little procedure that simply adds 100,000 rows to the table: I then [...]![]()
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 [...]![]()
Recent comments
17 weeks 4 days ago
27 weeks 2 days ago
29 weeks 8 hours ago
32 weeks 1 day ago
34 weeks 3 days ago
44 weeks 10 hours ago
45 weeks 4 days ago
46 weeks 4 days ago
46 weeks 5 days ago
49 weeks 3 days ago