Re: Db_block_checking (11.2)
From: Hans Forbrich <fuzzy.graybeard_at_gmail.com>
Date: Fri, 07 Nov 2014 07:22:59 -0700
Message-ID: <545CD5C3.7020306_at_gmail.com>
On 06/11/2014 5:08 PM, Hemant K Chitale wrote:
>
> What is the observed overhead of db_block_checking=TRUE (FULL) when
> running an UPDATE (1 to 3 columns) of almost all the rows of a table
> ? I see a 30% increase in CPU time.
>
> Sent from my smart phone.
> Hemant K Chitale
>
If, as Tom says in
https://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:1094433279412 , the checksum is calculated every time the block is written, and calculated every time it is read, and if the update causes blocks to be cleaned rapidly and unnecessarily (think "very poor Index Clustering Factor'") due to a relatively undersized SGA (relative to block cleanout requirements for the update operation), then it certainly could make sense that the overhead is dramatically high for the operation.
Date: Fri, 07 Nov 2014 07:22:59 -0700
Message-ID: <545CD5C3.7020306_at_gmail.com>
On 06/11/2014 5:08 PM, Hemant K Chitale wrote:
>
> What is the observed overhead of db_block_checking=TRUE (FULL) when
> running an UPDATE (1 to 3 columns) of almost all the rows of a table
> ? I see a 30% increase in CPU time.
>
> Sent from my smart phone.
> Hemant K Chitale
>
If, as Tom says in
https://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:1094433279412 , the checksum is calculated every time the block is written, and calculated every time it is read, and if the update causes blocks to be cleaned rapidly and unnecessarily (think "very poor Index Clustering Factor'") due to a relatively undersized SGA (relative to block cleanout requirements for the update operation), then it certainly could make sense that the overhead is dramatically high for the operation.
When you say "almost all rows", does that imply an index might be driving the selection or order or rows being updated?
/Hans
-- http://www.freelists.org/webpage/oracle-lReceived on Fri Nov 07 2014 - 15:22:59 CET