Re: _db_writer_verify_writes hidden parameter & db_block_checksum

From: K Gopalakrishnan <kaygopal_at_gmail.com>
Date: Thu, 22 Jan 2009 12:23:18 -0600
Message-ID: <3b0f44a10901221023w31962d4cg5d85cc158f88a52d_at_mail.gmail.com>



Rama,

I guess you are on 10.2 and your description is pretty accurate. Setting true forces dbwr to re-read every block (after write) to verify the writes are written as expected. But has a huge overhead esp. if you have a bigger cache and if _db_writer_verify_writes going to verify every byte in the block.

The functionality (of block write sanity checks) was available from 8i onwards in the form of an event (10360) where you can ask the dbwr to verify the header or complete block. When set at level 4 (huge overhead!) dbwr has to verify byte-byte and level 8 veifies the header and checksum (similar to db_block_checksum). The event was exposed as a parameter in 10.1 (_dbwr_tracing?) and changed to _db_writer_verify_writes in 10.2 and above.

Be warned this is going to debug only buffered writes. Unbuffered writes are not protected against these paremters and you are at the mercy of the I/O path between host to spindles :)

-Gopal

On Thu, Jan 22, 2009 at 9:28 AM, <rama.ari_at_accenture.com> wrote:
> Gurus
>
>
>
> We have block corruption in Oracle RAC ASM environment. We are evaluating to
> setup oracle parameters to debug/prevent block corruption when it happens
> next time. Did any one used _db_writer_verify_writes parameter? I was in
> impression that it helps to direct the DBWR to re-read every block after it
> writes it out to make sure the write operation did happen as planned. I
> didn't find much information in Metalink.
>
>
>
> We are also evaluating setting up DB_BLOCK_CHECKSUM parameter. I would
> really appreciate if you had any lesions learned with these parameters (like
> performance degradation, etc)
>
>
>
> Thanks,
>
> Rama Ari | Accenture
>
> Technology Consulting
>
> ( Mobile: +1 (610) 203-0661
>
>
>
> This message is for the designated recipient only and may contain
> privileged, proprietary, or otherwise private information. If you have
> received it in error, please notify the sender immediately and delete the
> original. Any other use of the email by you is prohibited.

--
http://www.freelists.org/webpage/oracle-l
Received on Thu Jan 22 2009 - 12:23:18 CST

Original text of this message