If you have reasonably accurate statistics on the indexes I have some code that reports indexes that are larger than expected. Since it’s fairly cheap to run I’d be inclined to use it to discover problem indexes on a system I didn’t know, then think about why those indexes (a) exist and (b) are badly behaved.

I’ve been to many sites which have redundant indexes on tables because there has been no strategic analysis of how the table has to be queried – and sometimes this has resulted in many similar indexes with large numbers of columns.

Your thoughts about Indexes leaf nodes split? and how to capture
indexes with a lot of columns in their definitions that grow even more rapidly than the table they index?

Thanks,

Lu

1: I can’t remember now why I chose to say 32KB rather than 40KB – but I’d guess it’s because it looks as if the extent size has been set deliberately low and 32KB is a more likely value for a computer-literate person to choose than 40KB (powers of two are prettier). Your comment does raise the question though: if the block size is 4KB and the extent size = 32KB (which is 8 blocks), does Oracle alternate bumping the high water mark by 5 then 3, or does it always bump by 5 even if it means pausing to add an extent for the final 2 blocks, or is there a special boundary case when the number of blocks left in the extent after a bump is less than 5. (Easy to test a few cases, of course, but probably not worth the effort any more).

2A: Yes, one round-trip is one user call, and a user would be a parse, execute, or fetch. (Possibly a commit would be counted as an execute – it might be worth checking that – bearing in mind there are two code paths for the commit.) Just to avoid any risk of confusion, it’s worth mentioning that the converse is not true: a parse, execute or fetch need not be a user call, as it may have occurred within a pl/sql block which has been instigated by a user’s “execute” call.

2B: Bear in mind my comment starts with “perhaps” – I was only making a tentative suggestion. In fact it was an oversight on my part (now corrected) that made me omit deletes. (I note that you’ve highlighted “single” in both cases – the reason why I suggested single row, in case you were wondering, is that the redo size per execution was very small.

1: You said: HW and ST enqueues. The highwater mark jumps every five blocks: given the ratio of ST to HW enqueues (roughly 1 to 2), we might have a very large, and growing, object with an extent size of about 32KB.
Q1: ST/HW=1/2, so the size of one extent equals to the size allocated from two HWM jump, and one HWM jump is of size 5*4K=20K, so two HWM jump is of size 40K. Looks like the extent is of size 40K.

2:This one session did roughly 605,000 roundtrips – which accounts for a very large fraction of the 258.4 “user calls” in the Load Profile, and since we also had 244 Executes in the load profile, perhaps this one session was busy doing single row inserts or single row updates for the duration.
Q2A: Do you mean one roundtrip is one “user calls”? In my memory, user call is either of parse, fetch, exec or commit.
Q2B: How are you sure it was doing ***single*** row inserts or ***single*** row updates? How are you sure it was not doing delete operation.

Thanks,
Daniel