Thank you for your reply. What is the benefit of this processing?
You need to find an available buffer, link it into the appropriate hash buffer chain, do the actual cloning (memory copy), and potentially exchange the old buffer on the checkpoint queue with the new current buffer (as described in chapter 6, page 140) – i.e. quite some additional work. On top of it this makes the hash buffer chains longer (because there is an additional copy of the same data block, which might never be used again) and it requires additional space in the buffer cache.
On the plus side I only see that other sessions that need a CR copy with a target SCN prior to the modification can access the old buffer, rather than having to create a CR copy by themselves. Is this the entire justification for the “switch current to new buffer” mechanism or are there any additional benefits?

thank you
kind regards
Martin

I’ve just been re-reading these comments and realised I misunderstood what you were saying. It is just a simple error (which I’ve now added to the Errata) in the Note at the top of page 107. It should say “changes the touch count on that buffer to one.”

i) & ii) I had to go back and read some old test scripts to check – and they say that the tch is not set (i.e. starts at zero) in 8i and 9i for tables less than 2% of the cache size, and that the blocks were loaded to the midpoint.

iiI) There is a bitmapped FLAGS column on the buffer header, and bit 19 is named “only_sequential_read”. This is set if the table was subject to a full tablescan. I have always assumed that this is what stopped subsequent buffer accesses from incrementing the tch.

iv) good question – it got a lot more complicated in recent versions – I suspect in the older versions when we said “dropped to the end of the LRU” we should have been saying “transferred to the repl_aux”. Have you read the investigation into “small” tables I did a couple of years ago ? http://jonathanlewis.wordpress.com/2011/03/24/small-tables/

Thanks for the reference.

I don’t think there’s a lot to be said about this mechanism.

Basically a session may clone a CUR buffer before modifying it. The previous CUR copy is switched to CR as this takes place. The easiest way to see this is create a table with a few hundred block then update a few rows in the table by tablescan; each time you do the update you’ll see that the blocks you’ve updated are cloned before the update is applied.

There is also the detail that the examination is attempted only if Oracle thinks that it is likely to be completed in a short time. For example when accessing an undo block to find an undo record, evey detail about where that record will be is fixed and there’s no chance Oracle will have to do the equivalent of something like a block cleanout to find the right version of the record.

Essentially, it probably comes down to a trade-off between the time it takes to create, attach and subsequently release a pin, compared to the time it will probably take to locate and extract the correct piece of information from the block.

I have some questions regarding the “Tablescans” section at the end of chapter 5.

When you describe the 8i and 9i strategy for “small tables”, you say the reads during scans of small tables were treated just as other reads but the touch count was not incremented when reading the blocks (nor during subsequent visits). This leads me to the following questions:
i) Is a newly read buffer linked at the midpoint into REPL_MAIN (i.e. at the location pointed to by cold_hd) as with other reads?
ii) In the “LRU/TCH” section starting on page 104 you don’t mention that the touch count is incremented for blocks that are (normally) read into the cache and linked at the midpoint into REPL_MAIN. Rather the touch count is set to 1 for these blocks. So what does it mean when you say that the touch count is not incremented for blocks read during a full scan of a small table – is the touch count set to 0?
iii) How does Oracle ensure that the touch count of blocks read during a full scan of a small table is not incremented during subsequent visits? Is there a flag on the buffer preventing such increments or is it maybe the touch count value 0 that indicates the block was read in by a full scan of a small table (see my guess in question ii).

vi) When you write “…the table was larger than the 2 percent limit, then the buffers used to read the table were immediately dropped to the end of the LRU list..”, does “end of the LRU list” mean REPL_AUX in this context, or the LRU end of REPL_MAIN?

thank you
kind regards
Martin

I found the note on top of page 115 a bit short and didn’t fully understand what it was saying. When browsing Internet to find some clarification I came across the following blog that Jonathan has written and which helped me to fully understand the note. I just post the link here in the hope it may be useful to other readers.
http://www.jlcomp.demon.co.uk/buffer_handles.html

kind regards
Martin

On page 115 you mention that Oracle does “switch current to new buffer” and you mention this mechanism again on page 116. Could you please briefly sketch what this mechanism is about or give a link where it is documented?

thanks a lot
kind regards
Martin

When reading your comment on consistent gets – examination on page 114, two questions came into my mind. I have a hypothesis on the answer and I’d appreciate if you could confirm my hypothesis or tell me why I am wrong.
i) What qualifies a logical read to be done at “half-price”, i.e. with only one latch get and without pinning the buffer?
ii) How does Oracle ensure there is no concurrent modification of the buffer while it is being read with a “half-price” logical IO, i.e. not protected by a pin? Concurrent modification of the buffer while it is being read might provide the reader with an inconsistent view of the buffer content (it might see only part of the modifications made to the buffer).

I believe the answer to the two questions is as follows, but I haven’t verified it with any tests:
When Oracle expects that inspection of the buffer content can be completed within a short time, it does this inspection under protection of the cache buffers chains latch protecting the hash chain the buffer is currently linked on. I.e. after finding the buffer and while holding the cache buffers chains latch, Oracle checks that no exclusive pin is attached to the buffer. If this check succeeds, Oracle will inspect the content of the buffer (while still holding the cache buffers chains latch) and release the cache buffers chains latch, once the inspection of the buffer content is completed.
A separate code path must exist to handle the case where the buffer is pinned exclusively and thus may be subject to ongoing modifications – it doesn’t seem unreasonable to me to assume that Oracle will fall back to the ordinary logical IO in this case, ie. attach a shared pin to the waiters list of the buffer and wait for the exclusive pin to be released.

thank you for reviewing this statement
kind regards
Martin