Re: delayed logging block cleanout -- Any other comments?
- From: "Diego Cutrone" <diegocutrone@xxxxxxxxxxxx>
- To: <oracle-l@xxxxxxxxxxxxx>
- Date: Thu, 27 May 2004 10:10:24 -0700
Has anybody tested this in an Oracle 7/8.0 database?
I have tested this yesterday and found incompatible results according to
Steve's comments:
"If delayed_logging_block_cleanouts is TRUE, which is the
default in 7.3 and 8.0, the logging of this redo is delayed until another
change is made to the current buffer. The cleanout itself does not mark the
buffer as dirty or log the redo for its changes. The next change to the
buffer marks the buffer as dirty and logs redo for the cleanout as well as
its own changes.
" (from http://www.ixora.com.au/q+a/cr.htm)
In an Oracle 7.3.4 instance (d_b_c_o = TRUE) , whenever I execute a query
against some table with uncleaned blocks, they get clean out !!
(I can even see redo being generated by the session execting the query in
v$sesstat.)
I had performed the same test a couple of years ago against another O7
instance and it worked out just like Steve says above, I don't know what I'm
doing wrong now... , may this behavior be influenced by a port specific
issue? (different OS or something like that?..)
Any ideas?
Thanks
Diego.
----- Original Message -----
From: "Diego Cutrone" <diegocutrone@xxxxxxxxxxxx>
To: <oracle-l@xxxxxxxxxxxxx>
Sent: Wednesday, May 26, 2004 6:35 PM
Subject: Re: delayed logging block cleanout
> Hi Jared,
>
> From the link you pointed me out (Steve Adams response):
>
> "
> Delayed block cleanout is performed by the next reader of the block, even
if
> it is just a query. The block is read into the cache as a current mode
block
> and cleaned out. If a query is being performed, a consistent read mode
clone
> of the block is made using another block buffer, and if necessary rolled
> back to the snapshot SCN for the query. The consistent read mode buffer is
> used to satisfy the query. However, any changes are made to the current
mode
> buffer.
>
> Because block cleanout actually makes changes to the current mode buffer,
it
> must generate redo. If delayed_logging_block_cleanouts is TRUE, which is
the
> default in 7.3 and 8.0, the logging of this redo is delayed until another
> change is made to the current buffer. The cleanout itself does not mark
the
> buffer as dirty or log the redo for its changes. The next change to the
> buffer marks the buffer as dirty and logs redo for the cleanout as well as
> its own changes.
>
> If the parameter is FALSE, the cleanout logs its own redo and marks the
> buffer as dirty, even if the block was only being used for a query.
Because
> the buffer is dirty, DBWn must write the cleaned out block back to disk.
> This increases DBWn's workload, but prevents the cleanout from having to
be
> repeated by later queries.
>
> "
>
> Jared, maybe I'm getting it wrong, but I remember I having tested this
once
> in an Oracle 7 instance and I got the results Steve remarks here (same
thing
> I've said in my previous email).
> In Oracle 7 (the default behavior) not only the logging is delayed but the
> whole block clean out is delayed until another *transaction* takes place
in
> the same block.
> Now, if a *query* is executed (instead of a transaction), this query would
> have to clean out the blocks but (as Steve says) these cleaned blocks are
> *not* written to disk, so another query would have to do the same clean
out
> until a transaction takes place in that block and cleans it out
definitely.
>
> This is *not* what I've seen in the tests against a 7 and 8.0 database I
> have performed today. If you check it out, the block got completely
cleaned
> when I executed a query (the default behavior in Oracle 8i)
>
> Thanks for answering
> Diego.
>
>
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Other related posts:
