Question

I’d like to ask about the buffer gets meaning. With the reduction of buffer gets then I can assume that I’ve reduced the I/O needed, but can I also say that it has something to do with the execution time too?
Mostly I found that with reduced buffer gets it has an impact with reduction execution time, but in a few case it showed that I have also a reduced execution time eventhough my buffer gets increase. Is that possible?
Thanks in advance!

PS : I’m using Oracle 11g RDBMS

Answer 1

A reduction in buffer gets generally but does not always correlate to a faster runtime. There is definitely a correlation but the correlation is not perfect.

A buffer get will take vastly different amounts of time depending on whether the database can simply pull the block from the SGA cache, whether it can be read from the file system cache, whether it can be read from the SAN cache, or whether it actually requires a physical read. And the time required to do a physical read is highly dependent on how your SAN is structured and whether it stores different blocks on faster or slower disks. In many modern SANs, you may have a small amount of solid state disk for the most frequently read blocks, some fast hard drives for commonly read blocks, and slower hard drives for the less commonly read blocks each with their own performance characteristics.

It is entirely possible that you could reduce the amount of logical I/O that your query does but change the nature of the I/O so that it is more likely to be cached. If, for example, you have a nested loop where you are constantly doing an index scan, it is relatively likely that a large portion of the index is going to get cached in the SGA relatively quickly meaning that most of the logical I/O you do on that index ends up being satisfied by relatively fast buffer gets that only have to grab the block from the SGA. An alternate plan that involves, say, doing a full table scan, might do less logical I/O but, since relatively few blocks from the table are likely to be cached, most of that I/O might require physical reads. It is entirely possible that, in this sort of situation, the query plan that does more logical I/O would complete more quickly.

In practice, though, it is relatively rare that a human is going to be able to accurately predict which buffer gets are likely to require physical reads and which will generally be serviced from cache. Your non-production environments almost certainly don’t have the same pattern of cache utilization that your production environments have since you’re not running the same sort of workload in those environments. Even on the production system, the set of blocks that is cached varies tremendously over the course of a day and human developers rarely have reason to know or understand those variations. So just because when you’re testing a query you find that it does more buffer gets but runs more quickly than an equivalent query, that may not indicate that you’ll see a similar pattern in production. Since the number of buffer gets is (more or less) equivalent across environments (assuming more or less equivalent data volumes), it is generally much easier in practice to focus on reducing logical I/O and let Oracle take care of the rest.

Additionally, queries wait on much more than just I/O. Queries wait on CPU, they wait on network events, they wait on locks and latches and other serialization devices. Buffer gets measures just I/O, it doesn’t attempt to account for any of those other types of waits. So you can also have situations where one plan does substantially less I/O but waits substantially longer on CPU or network or RAC cache fusion or some other event so that its execution time is much larger despite spending much less time waiting on I/O.