Re: CR Block copies, always 6 in 10.2.0.3?
Date: Tue, 25 Mar 2008 09:08:33 +0100
This was introduced in Oracle7 (_db_block_max_cr_dba). The problem was that certain blocks like segment headers were getting so many CR cpies (I have seen cases with 700+). This would result in high contention on the cache buffer chains latch, as all the CR copies had to be scanned to find the SCURRENT or XCURRENT copy (high CPU usage). So things were slowing down quite bit. This parameter was introduced and the first default value was 42 (as advised by Roger Bamford to Zait (I believe)). Later that was brought down to 12 and now it is 6.
But occasionally you will see a larger number of CR copies. For example when there is 60 processes updating a table with a NL operation (SAP, for example). One of the tests as I remember is that the buffer is not busy ('is not pinned'), then it will check the number of CR copies. If a CR copy is pinned it is not counted. So that is probably why you can speak of a soft limit.
Op 3/25/08 5:10 AM, K Gopalakrishnan <kaygopal_at_gmail.com> schreef:
> Alex, > > This is just a soft limit. You can infinitely create cloned buffers in > your buffer cache and we don't limit that. This limit is enforced only > under certain conditions and memory pressure is one among them. Check > my other post for some more detials. > > -Gopal > > > > > On Sun, Mar 23, 2008 at 5:10 PM, amonte <ax.mount_at_gmail.com> wrote:
>> Hi all
>> I read from somewhere, I think the wait interface book where it states that
>> the number of clone copies of data block is governed by _DB_BLOCK_MAX_CR_DBA
>> which is set to 6. If there will be more than 6 copies then Oracle will wait
>> for the buffer, this is what I dont get, wait?
>> So I fired up 7 sessions and see what kind of wait is this! I updated the
>> same table (EMP from scott tiger), 14 rows in same data block and each
>> session updates a row, then each session fires a query agaisnt EMP. I
>> noticed that the number of CR is never more than 6 despite having 7 updates
>> concurrently and I dont see what is really going on. Does this mean whenever
>> the 7th CR block is being cloned one of 6 previous CR is being overwritten
>> or "destroyed"?
>> I did the test in 10.2.0.3.
> Received on Tue Mar 25 2008 - 03:08:33 CDT