Title: DB_BLOCK_CHECKING and DB_BLOCK_CHECKSUM
DB_BLOCK_CHECKSUM = no overhead worth mentioning
DB_BLOCK_CHECKING = equivalent to 10210 (check data block integrity), 10211 (check index block integrity), and 10212 (check cluster integrity) events
 
The former (DB_BLOCK_CHECKSUM) is useful if you suspect that something might be corrupting a database block while it is residing on disk.  The checksum is calculated by the writing process (i.e. DBWR) upon write to datafile and re-calculated/verified by server processes upon read.  It will raise an ORA-01578 error upon read...
 
The latter (DB_BLOCK_CHECKING) is intended to cause additional integrity checks while the database block resides in a buffer in the SGA, so it could be useful if you believe that there is some form of memory corruption involving the Buffer Cache.  Other events for checking for possible memory corruption include 10235 ("check memory manager internal structures") and 10049 ("Use the OS memory protection (if available) to protect library cache memory heaps that are pinned.")...
 
There is an undocumented parameter ("_db_always_check_system_ts") which defaults to TRUE, causing the constant DB_BLOCK_CHECKING in the SYSTEM tablespace, from v8.1.6 onwards.  This caused some problems for those upgrading from v8.0.x and v8.1.5 to v8.1.6 when any kind of corruption exists in the SYSTEM tablespace, because a bug introduced late in 7.3.x (or early 8.0.x?) causes corruption in SYSTEM.  Note #96117.1 on MetaLink has more info on this.
 
----- Original Message -----
Sent: Monday, April 22, 2002 1:19 PM
Subject: DB_BLOCK_CHECKING and DB_BLOCK_CHECKSUM


Hi everybody,

I'm soliciting opinions on whether or not its a good practice to enable DB_BLOCK_CHECKING and DB_BLOCK_CHECKSUM.  How much overhead is associated?

TIA,

Beth

Reply via email to