Hi,Or that there may indeed be no benefits in most environments
Some claim that the increased human management
components of watching multiple buffers is too
cumbersome, and that the benefits are not great
engough to warrant the new blocksize.
Me, I use scripts to manage the monitoring ofHi Don
multiple data buffers, so that I can have larger
blocksizes, but you need to run a careful test to see
if your specific database sees any improvements in
throughput. In my experience, the results can range
from negative (the new blocksize decreases
throughput), up to over 20%, it depends on many many
I had resisted the temptation to respond, but Hermant makes a good point - I don't necessarily agree with the point, but it is a good point. I don't want to drag this thread too far off topic, but I think that it is headed in that direction anyway. I was an Oracle novice at one time, as I am sure most in this group will also admit for themselves. I recall several years ago, shortly after reading "Oracle Performance Tuning 101", of trying to improve database performance by reviewing the initialization parameters, redo log configuration, and general server configuration. One of the initialization parameters that I investigated was LOG_BUFFER, which at the time on one of the production databases was set to 262,144 bytes (256KB). A Google search found several pages with information related to this parameter, and one of the first pages found by Google showed wait events from a Statspack report, that according to the website, indicated a problem with the LOG_BUFFER parameter, which was configured at 512KB.informativelittle spat was quite amusing and at times
True ! I wonder how many forum users (novices) have
been confused and put off
by the "war of words" that JL and RF have with DB.