And thanks for replaying to my mail.

Antonio

Remember that the index is on trunc(last_update_date) – so the virtual column value is a constant for 24 hours. Since each index entry (non-unique index, remember) is then (column_value, rowid), the order in which we update the old value could affect the rows in an order that allowed earlier rowids to be updated after later rowids, filling in gaps in the index leaf blocks for the current date.

Nice presentation

“However, rather than take the worst case scenario, let’s take the best (and least likely) scenario – assume that by the end of the
day there have been lots of 50/50 block splits, but a lot of back-fill has taken place (because of a random order of updates) and
every block just happens to get very close to 100% full.”

since the column last_update_date always reflect to the future date when the update happen,
how will it back-fill

could you please explain?

Thanks

I was hit by the same bug during my demonstrations in the “Oracle Closed World” event. But restarting the database solved it.

Then it appeared on a client-site pre-production system. I decided to do a metalink search (advanced, all words, for “OERI” and “15264″ – the OERI search is for the Oracle Internal Error tag – and found bug 8227243 dating back to Feb 2009.

We weren’t able to try all the workarounds (like restarting the database), so in the end we renamed the table and indexes as a temporary measure so that we could build a new copy.

The owner of the table later managed to bypass the problem somehow. I think he moved the table, dropped all constraints on the table, and then found he could drop the indexes and table – but he doesn’t know which bit of this activity was key to working around the issue, so another “Req’d Info Not Avail” report to Oracle.

I think you’re probably thinking of Chapter 5 of Cost Based Oracle – Fundamentals (the chapter that can be downloaded as a free pdf file from Apress) where I suggest that we could “hi-jack” the sys_op_countchg() function used by Oracle to calculate the clustering_factor of an index.

You’re probably correct to suggest that I could have made some comments about the function being undocumented and that my suggestion to trace the gather_index_stats() call should be repeated on every upgrade of Oracle to ensure that the mechanism was still appropriate.

In fact, as Richard Foote points out in one of the comments to his postings on Oracle Open World 2009, this may be particularly significant in some future (12+) version of Oracle because the Optimizer Group is looking at better ways of calculating the clustering_factor (and may, apparently, do something that looks remarkably similar to the suggestion I voiced in the book).

Possible, but we may never know.

But it’s possible that by asking him to state the source of his doubt I encouraged him to read the text more carefully and note that he was confusing the actions of the “commit” with the actions of the “commit cleanout” and answer his own question.

You don’t actually have to do the manual allocation of extents, by the way. Apart from the special case of the first 1MB of space allocated under system managed extents, Oracle will round-robin extents through the available data files.

To increase the visibility of the effect, you could even try using freelist management instead of the default 11g ASSM (automatic segment space management). (No need to post the results, though).

A quick search on MetaLink shows precious little (practically nothing) about sys_op_countchg() – so, is it wise to promote its usage? Is it something that looks good, but could go nasty in a next release/patchset?

But I think he’s confusing redo associated with the transaction slot following a Commit, and non-redo associated with a commit cleanout.