Re: CR Block copies, always 6 in 10.2.0.3?

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.

Anjo.

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:

--
http://www.freelists.org/webpage/oracle-l