Subject:  Init.ora Parameter "DELAYED_LOGGING_BLOCK_CLEANOUTS" Reference Note 
Creation Date:  18-SEP-1997 

Parameter: DELAYED_LOGGING_BLOCK_CLEANOUTS
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 Versions:		7.3, 8.0.X
 Obsoleted:             8.1 - Oracle8i behaviour is the same as if this
                              parameter is set to TRUE
 Parameter type:        boolean
 Parameter class:       static
 Default value:         TRUE
 Range of values:       TRUE/FALSE
 OK to change:          yes
 Multiple instances:    need not be identical
 Related:

Description:
        This parameter turns on or off the delayed block cleanout feature, 
        which reduces pinging in an Oracle Parallel Server.
        Keeping this feature set to TRUE sets a fast path, not logging block 
        cleanout at commit time.
        Logging the block cleanout occurs at the time of a subsequent change 
        to the block.
        This generally improves Oracle Parallel Server performance, 
        particularly if block pings are a problem.
        
        When Oracle commits a transaction, each block that the transaction 
        changed is not immediately marked with the commit time.
        This is done later, upon demand--when the block is read or updated.
        This is called <block cleanout>.
        
        When block cleanout is done during an update to a current block, the 
        cleanout changes and the redo records are piggybacked with those of 
        the update.
        In previous releases, when block cleanout was needed during a read to 
        a current block, extra cleanout redo records were generated and the 
        block was dirtied.
        This has been changed.
        
        As of release 7.3, when a transaction commits, all blocks changed by 
        the transaction are cleaned out immediately (if they are in the
	buffer cache) - see below.
        This cleanout performed at commit time is a "fast version" which does 
        not generate redo log records (<delayed logging>) and does not repin 
        the block. Most blocks will be cleaned out in this way, with the 
        exception of blocks changed by long running transactions.
        
        During queries, therefore, the data block's transaction information is 
        normally up-to-date and the frequency of needing block cleanout is 
        much reduced. Regular block cleanouts are still needed when querying 
        a block where the transactions are still truly active, or when querying
        a block which was not cleaned out during commit.

Note: 	In long-running transactions, block cleanouts will not be performed
	during the transaction. If the transaction is not long running, block
	cleanout will be performed and the block cleanout is logged at the 
	change of block.

Note:   As of Oracle Server release 7.3, performing a SELECT COUNT (*) no 
        longer does a block cleanout if this feature is in use.
        
        During changes (INSERT, DELETE, UPDATE), the cleanout redo log records 
        are generated and piggyback with the redo of the changes.
        

From:     JYCALECA.FR:
~~~~~~~~~~~~~~~~~~~~~~

Every time a transaction changes a data block, a "block entry state object" 
has to be added to the commit list of the transaction. The information stored 
in an entry of this list is mainly : 
        - ITL# of the Transaction in the block 
        - Pointer of buffer descriptor (BH) of the block in the cache 
 
These block entries are grouped by 20 : the allocation unit is 20. So if a 
transaction changes only one block and commits, a chunk of 20 entries will be 
allocated even if only 1 entry will be filled.  During the life of a 
transaction, if the first group of 20 entries have been used, another chunk 
of 20 entries is allocated, and so on.  
Once the number of entries used by the transaction reaches 10% of the 
<Parameter:DB_BLOCK_BUFFERS> subsequent blocks changed by the transaction will 
not be recorded in the list (hence no fast cleanout on these blocks)
 
At COMMIT this list is followed to point directly to the buffer and to try to 
"fast clean" the corresponding block. 
  Each try, the <statistic:Total_number_commit_cleanout_calls> is incremented. 
  If successful <Statistic:Commit_cleanout_number_succesfully_completed>
  is incremented.  
If for a chunk of 20 entries, 3 failures have occurred, this chunk is 
skipped and the next chunk of the transaction (if it exists) is processed. 

 
Fast cleanout of a block can fail due to several reasons, such as : 

 The state of the buffer is not CURRENT and EXCLUSIF 

 The buffer is logically <flushed> (<free>) 

 The mode of the buffer is not compatible with the EXCLUSIVE mode  
 (OPS) there is a ping on the block or writes are temporarly suspended 
  <Statistic:Commit_cleanout_failure_write_disabled> is incremented 
 The related file is in Hot backup and the buffer is not yet marked Dirty 
   <Statistic:Commit_cleanout_failure_hot_backup_in_progress> is incremented 

 The buffer is currently being written by  DBWR 
   <Statistic:Commit_cleanout_failure_buffer_being_written> is incremented 
 The entry points to another buffer. One of the following checks fail : 
 The block type must be a data block,  
 The Itl# must point to the current transaction 
 The Tx in the ITL must not be already marked as committed(C) or 
   DL-cleanout(U)  
 <Statistic:Commit_cleanout_failure_callback_failure> is incremented 

Articles:
     Overview of Init.Ora Parameter Reference notes    [NOTE:68462.1]