“CR Cloning” – to see the correct version of a block (as at a point in time), Oracle may have to copy it then apply undo records to take the copy back in time.

When you see the statistic “consistent gets”, some will be “no work – consistent read gets” which means that this action was not necessary, but if you see some “data blocks consistent reads – undo records applied” you know that some blocks have been cloned to create the appropriate version. (The statistic “transaction tables consistent reads – undo records applied” is a more exotic example of the same thing).

Please help to elaborate more on CR Cloning, Thanks.

Nice explanation.

Hence the read/fill/write.

Even if DBWR happened to write two Oracle blocks that fitted into one 8KB file system block, the file system code would probably still see this as two separate events, and go through the cycle twice (although it would find the file system block cached when it started to write the second Oracle block).

Just got a link of a posting by Steve Adams on this same subject. As you mentioned, even Steve says the same that this mismatch in block sizes can cause “Free Buffer Waits”. In his posting, he says that this is caused as DBWR writes Partial Blocks. I am of the opinion that since DBWR writes in Batch and not single blocks, how can this cause a performance issue.

In your posting above, you said that “Oracle block write has to turn into a read/fill/write on a 8kb file system page”. Would appreciate, if you can elaborate on this read/fill/write concept.

Thanks

traditionally a high value for “free buffer waits” is an indication that the database writer is unable to clear dirty blocks fast enough. In the case of a 4KB db block size with an 8KB filesystem block size (and assuming you really are using the file system cache), an Oracle block write has to turn into a read/fill/write on an 8KB file system page. This will slow down your writes and could result in your “free buffer waits”.

Before rebuilding your system, however, I would check the following:
* is there any excess I/O (read or write) that could be eliminated (e.g. by tuning SQL)
* could you switch critical file systems to using direct I/O (which may have a different name on HP-UX).
* would introducing multiple (or extra) database writers help – which could be relevant if the I/O subsystem is not overloaded, and the problem is simply one of Oracle I/Os getting delayed in their queue.

If you are running 9i, and felt you really had to go to an 8KB block size, you could try to work out where most of your I/O was taking place and move the critical data into tablespaces with an 8KB block size, rather than rebuilding the whole database. On the plus side, you could do the change over a period of time; on the minus side you have to think carefully about how you split the memory between the default (4KB) cache and the 8KB cache.

Does a mismatch in the File System Block Size and DB Block Size cause Free Buffer Waits. We all know that the db_block_size should be a multiple of os block size.

A typical scenario is that the file system block size is 8kb and db block size is 4kb. It is on HP Unix. The database suffers with huge Free Buffer Waits. The HP engineer suggests that the db block size should be either equal to or multiple to File System block size and this means, recreation of the database.

My query is “can this cause free buffer waits” ?

Would appreciate your reply on this.