a) At what stage will DB_BLOCK_CHECKING be performed? Is it while reading the blocks into the cache or at some other stage?
b) Even without this paramater, Oracle is able to identify the corruption when the particular block is being requested--am I right? If so, what is the advantage of this parameter?
c) The Metalink doc says this parameter will prevent the corruption from being spread. How?
d) Without setting the CHECKSUM, how will this parameter work, as CHECKSUM only writes the value in the block header and this parameter is merely checking the value. Is my understanding correct?
a) Will the corruption be identified only for the modified blocks in the memory, or any additional work done like checking for corruption while reading blocks into memory, etc.?
b) Will this identify only physical memory corruption (like corruption in datafiles)?
1a) The blocks are checked when a block is written to disk by the DBWn process.
1b) Without this parameter, Oracle can determine that a block is corrupt, but only after the fact. This parameter can help detect corrupt blocks more quickly.
1c) By detecting block corruption earlier, you can stop it from spreading.
1d) DB_BLOCK_CHECKING verifies that the block is "consistent" with a block in memory. Since the block is checked when it is written, the copy of that block is still in the buffer cache. If the data in the block on disk matches the block in memory, then the check passes. No CHECKSUM information is needed here.
2a) There is no need to check for corruption of the block in memory, only corruption of the block on disk. The DB_BLOCK_CHECKSUM parameter forces Oracle to include some CHECKSUM information in the block's header as it is written to disk. Once that block is read from disk, the block's contents are compared to the CHECKSUM to verify that the block is still good.
2b) None of these methods identify corruption in memory. The only corruption that you should find in your blocks in memory are logical corruptions, which these two parameters do not address. These parameters only address physical corruptions of the data blocks as they exist on disk.
This was first published in July 2005