Re: why aren't ORA-1555 errors MORE frequent?

"Richard Kuhler" <noone_at_nowhere.com> wrote in message news:BidD9.23210$%k2.7662316_at_twister.socal.rr.com...
> Actually, the hypothesis was that if the blocks before cleanout must be
> written to rollback/undo then "ORA-1650 Unable to extend rollback
> segment" or similar could result from a SELECT. Indeed, the cleanout
> scenario for ORA-1555 is even more difficult to produce.
>
> Richard

Hi again Richard,

Just a couple of points.

1. The SCN updated in the header during the block cleanout is not written at the time of the transaction (if it's a big transaction and it couldn't be performed at the time of the commit).
2. As the clean out select does not constitute a transaction as such, it will quite happily overwrite previous cleanout changes previously recorded in the RBS (hence the demo not working as expected).
3. I read somewhere (or I dreamed I read somewhere) that a count(*) doesn't actually perform a cleanout, or doesn't anymore. Again, another reason why your demo won't work. Proving things can be tricky sometimes ;)

I must admit that I've always been somewhat dubious of undo being generated during cleanout but I remember long ago a demo that showed this. I remember somewhat more recently on a 8.1.7 database, dropping the rollback segment currently being used by a query performing delayed block cleanout. Let's say the query didn't like it and subsequently just died. This should be relatively easy to re-emulate.

Regardless, so long as you understand that by Oracle performing a delayed block cleanout and being unsuccessful in determining the actual SCN of the initial transaction, a snapshot too old can be generated and so long as you understand that it's not the actual SCN that's important, just that the SCN is no later than that required by the consistent read snapshot (your initial question), you will understand the most important 'bits' of this tricky subject.

My God, I hope all that makes some kinda sense !!

Cheers

Richard Received on Fri Nov 22 2002 - 00:30:35 CST