Re: fast commit

Thank You Jonathan.

Syed

• Original Message ----- To: "Multiple recipients of list ORACLE-L" <ORACLE-L_at_fatcity.com> Sent: Thursday, January 22, 2004 1:29 PM

> Note in-line
>
> Regards
>
> Jonathan Lewis
> http://www.jlcomp.demon.co.uk
>
> The educated person is not the person
> who can answer the questions, but the
> person who can question the answers -- T. Schick Jr
>
>
> Next public appearance2:
> March 2004 Hotsos Symposium - Keynote
> March 2004 Charlotte NC - OUG Tutorial
> April 2004 Iceland
>
>
> One-day tutorials:
> http://www.jlcomp.demon.co.uk/tutorial.html
>
>
> Three-day seminar:
> see http://www.jlcomp.demon.co.uk/seminar.html
> ____UK___February
>
>
> The Co-operative Oracle Users' FAQ
> http://www.jlcomp.demon.co.uk/faq/ind_faq.html
>
>
> ----- Original Message -----
> To: "Multiple recipients of list ORACLE-L" <ORACLE-L_at_fatcity.com>
> Sent: Thursday, January 22, 2004 6:29 AM
>
>
> Hi list,
>
> 1)Why fast commit generate no redo ?
>
> It's called a fast commit BECAUSE it doesn't generate redo
> (except for a tiny bit that describes the change to the transaction
> table entry in the segment header block that marked the transaction
> as active).
>
> It doesn't need to generate redo because it's going to leave
> (most of) the lock and change information on the blocks that
> have been changed, and let some other visiter to the blocks
> clean up the mess.
>
> 2)Is delayed cleanout generate redo?
>
> Delayed "block cleanout" - where a later operation simply READS
> a messy block and cleans it up (by referring back to the transaction
> table to get the necessary commit details) will generate redo.
>
> Delayed-logging "block cleanout" - which occurs when the first
> transactions cleans out a few of the blocks it has dirtied but
> does not log the cleanout - is effectively not going to generate
> redo, as the next transaction to MODIFY the date will generate
> some undo which looks as if it started from a clean block, rather
> than the partly dirty block that is really there - so the cleanout is
> effectively free.
>
> 3)In a block dump even after transactions commit why it shows lock 1 in
ITL?
>
> Because Oracle doesn't clean the block out properly, it will either
> not revisit it at all (1), or just revisit the ITL and a couple of header
> bytes (2).
>
>
> Thanks in advance.
> Syed
>
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> --
> Author: Jonathan Lewis
> INET: jonathan_at_jlcomp.demon.co.uk
>
> Fat City Network Services -- 858-538-5051 http://www.fatcity.com
> San Diego, California -- Mailing list and web hosting services
> ---------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Sultan Syed
  INET: ssyed_at_fine.ae

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).