Re: CR Block copies, always 6 in 10.2.0.3?

From: amonte <ax.mount@xxxxxxxxx>
To: "조동욱" <ukja.dion@xxxxxxxxx>
Date: Mon, 24 Mar 2008 12:56:45 +0100

ok so the 6 doesnt seem the limit, I just check a 2 node RAC database (
10.2.0.2) on Solaris and shows this:

select file#, block#, status, count(*)
from v$bh
group by file#, block#, status
having count(*) > 6
order by 1,2, 4

returns 115 rows where some blocks has as large as 18 CR copies so the
theory stated by the book doesnt seem real...

Alex



On Mon, Mar 24, 2008 at 12:15 PM, 조동욱 <ukja.dion@xxxxxxxxx> wrote:

> 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?
>
> Can you point us to the original doc?
> I've never heard that consistent read is blocked and being waited by any
> reason.
> (One exception is that buffer lock contention which is caused by physical
> read - read by other session wait event)
>
> As you observed it right, cr blocks are recycled by age.
> The olest one is replaced by new cr block.
> You can verify it using x$bh view.
>
>
> Dion Cho
>
> PS)
> "I read somewhere..." kind of thing seems not to be a good habit.
> You'd better leave a link to original doc or make the replayable test case
> yourself.
>
>
>

References:
- CR Block copies, always 6 in 10.2.0.3?
  - From: amonte
- Re: CR Block copies, always 6 in 10.2.0.3?
  - From: 조동욱

Re: CR Block copies, always 6 in 10.2.0.3?

Other related posts: