Beth - Well, you can get ahead of the curve and report back to the rest of
us. Since you mentioned both parameters, I'm assuming that you are
considering turning DB_BLOCK_CHECKSUM=true and leaving
DB_BLOCK_CHECKING=false.
Igor - Thanks for pointing out that the DB_BLOCK_CHECKSUM parameter is
turned on by default in 9i
I guess my initial reaction was that of the crusty old DBA. I just
get suspicious of something that will help me prevent a problem that I'm not
experiencing. I've got bitten a few times on that one. I pasted the
documentation in below in case anyone wants to see what these two parameters
do.
Dennis Williams
DBA
Lifetouch, Inc.
[EMAIL PROTECTED]
>From the Oracle 9i Documentation:
DB_BLOCK_CHECKSUM (default is true in 9i, false in 8i) determines whether
DBWn and the direct loader will calculate a checksum (a number calculated
from all the bytes stored in the block) and store it in the cache header of
every data block when writing it to disk. Checksums are verified when a
block is read-only if this parameter is true and the last write of the block
stored a checksum. In addition, Oracle gives every log block a checksum
before writing it to the current log.
If this parameter is set to false, DBWn calculates checksums only for the
SYSTEM tablespace, but not for user tablespaces.
Checksums allow Oracle to detect corruption caused by underlying disks,
storage systems, or I/O systems. Turning on this feature typically causes
only an additional 1% to 2% overhead. Therefore, Oracle Corporation
recommends that you set DB_BLOCK_CHECKSUM to true.
DB_BLOCK_CHECKING (default value is false) controls whether Oracle performs
block checking for data blocks. When this parameter is set to true, Oracle
performs block checking for all data blocks. When it is set to false, Oracle
does not perform block checking for blocks in the user tablespaces. However,
block checking for the SYSTEM tablespace is always turned on.
Oracle checks a block by going through the data on the block, making sure it
is self-consistent. Block checking can often prevent memory and data
corruption. Block checking typically causes 1% to 10% overhead, depending on
workload. The more updates or inserts in a workload, the more expensive it
is to turn on block checking. You should set DB_BLOCK_CHECKING to true if
the performance overhead is acceptable.
-----Original Message-----
Sent: Monday, April 22, 2002 3:25 PM
To: Multiple recipients of list ORACLE-L
Thanks Dennis. Its a paranoid Monday question. Actually I came across
an Oracle document which suggested that they always be enabled. I was
skeptical so decided to ask the real experts instead :-)
-----Original Message-----
Sent: Monday, April 22, 2002 4:03 PM
To: Multiple recipients of list ORACLE-L
Beth - Are you asking because you are experiencing a corruption problem,
or because you're having a paranoid Monday? ;-) I believe the overhead
is enough that you wouldn't turn them on "just because". But if you are
experiencing occasional corruption, you could tolerate quite a bit of
overhead. Dennis Williams
DBA
Lifetouch, Inc.
[EMAIL PROTECTED]
-----Original Message-----
Sent: Monday, April 22, 2002 2:20 PM
To: Multiple recipients of list ORACLE-L
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
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: DENNIS WILLIAMS
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (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.com
--
Author: Seefelt, Beth
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (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.com
--
Author: DENNIS WILLIAMS
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (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).
