Comments on: Buffer States

By: Book Review: Oracle Database 11g Performance Tuning Recipes « Charles Hooper's Oracle Notes

Sat, 10 Sep 2011 21:13:45 +0000

[...] creates up to six (and potentially many more) consistent read versions of the objects’ blocks (reference)? The last two paragraphs of this recipe seem to indicate that it is the segments themselves [...]

By: Logical I/O – Evolution: Part 1 « Ukrainian Oracle User Group

Logical I/O – Evolution: Part 1 « Ukrainian Oracle User Group — Fri, 08 Jul 2011 08:58:23 +0000

[...] * The “clone” copies require each a buffer from the cache effectively reducing the number of different blocks that can be held in the buffer cache. They are also the reason why an object might require much more cache than its original segment size in order to stay completely in the cache. [...]

By: Reading Material On Order 2 « Charles Hooper's Oracle Notes

Reading Material On Order 2 « Charles Hooper's Oracle Notes — Sun, 29 May 2011 22:44:52 +0000

[...] up to six (and potentially many more) consistent read versions of the objects’ blocks (reference)? The last two paragraphs of this recipe seem to indicate that it is the segments themselves [...]

By: Jonathan Lewis

Jonathan Lewis — Sun, 20 Mar 2011 09:38:33 +0000

Naresh,

I think you’re probably right. I was trying to come up with something that just didn’t look like a small read-only look-up table (which probably wouldn’t need KEEP pool assignment anyway) and didn’t think the details through carefully. The table would also have to be subject to different update frequency as well.

By: Tony Sleight

Tony Sleight — Thu, 17 Mar 2011 07:12:21 +0000

Thanks for the response, we were contemplating using the keep cache to hold a table, plus a couple of indexes to try and ensure these commonly accessed structures were always in memory. It seems from your research that the indexes in particular would be subject to a great deal of cloning and will require up to, say, twice the amount of space the object occupies currently. I shall have to run a test to identify how many block clones are likely to be produced accessing the indexes.

By: buffer flush « Oracle Scratchpad

buffer flush « Oracle Scratchpad — Wed, 16 Mar 2011 20:31:40 +0000

[...] is part 2 of an article on the KEEP cache. If you haven’t got here from part one you should read that first for an explanation of the STATE and CUR columns of the [...]

By: Naresh Bhandare

Naresh Bhandare — Wed, 16 Mar 2011 05:22:58 +0000

“If, for example, it’s a product table with constant lookups, but most of the lookups are for a small fraction of the products the most of the table might end up with two copies of each block while a small part of the table might end up with six.”

Question – if the product table is purely a lookup table (meaning no – or very rare updates) – then it would not have any CR blocks. If so, why would most of the table end up with 2 copies of each block?

By: Jonathan Lewis

Jonathan Lewis — Tue, 15 Mar 2011 22:23:44 +0000

Tony,

It’s probably very hard to predict. It is dependent to some extent on concurrency, but also on the nature of data usage. If, for example, it’s a product table with constant lookups, but most of the lookups are for a small fraction of the products the most of the table might end up with two copies of each block while a small part of the table might end up with six.

On the other hand, if there’s a lot of update going on all over the table then nearly every block may end up with six copies (although that varies with version of Oracle and the way in which the update was applied.)

I think it’s probably one of these things where you make a reasonable guess and then check if you’re in the right ball-park.

By: Tony Sleight

Tony Sleight — Tue, 15 Mar 2011 07:24:57 +0000

That’s an interesting post. My question would be, therefore, in order to adequately size a keep cache, can you accurately predict the amount of block cloning that an object may be subject to? Is this a concurrency issue?