RE: delayed block cleanout (?) for active tx

Alberto

        I remember conducting similar tests. While creating a CR copy of the block, undo records are applied to rollback the changes, so that a specific version of the block can be created. Applying undo records generates redo.

        Rerunning the query has a different environment i.e. different SCN requirements and this rollback need to be performed again. [ I haven't tested this in 10g and I vaguely remember somebody saying that there is an improvement in this area].

        All statitics you see are due to this rollback. 'db block changes' is incremented while applying undo records to the blocks too.

Thanks
Riyaj Shamsudeen
ERP financials DBA, New AT&T

-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Alberto Dell'Era Sent: Thursday, June 21, 2007 10:57 AM
To: Oracle-L
Subject: Re: delayed block cleanout (?) for active tx

On 6/21/07, *snipped name* wrote:
> The CR copy of the block should only be made if it's not available.
If the CR
> copy created initially is still available, the second one should not
have been
> created, right?

But the second one has to be consistent to a different (more recent) point in time (higher scn), hence it has to inspect the current block to check whether any modification has been performed in the meanwhile (the active tx could have committed, even). Then, it may reuse the same CR copy perhaps.

I've just re-checked everything and even after N selects, the generated redo size comes out as exactly 157612 every time.

BTW The reason I'm performing this quest is that I have an application that is generating excessive redo, and the only (apparent) change is that one critical tx is taking much more time - and other sessions are selecting the modified block.

-- 
Alberto Dell'Era
"the more you know, the faster you go"
--
http://www.freelists.org/webpage/oracle-l


--
http://www.freelists.org/webpage/oracle-l