Performance tuning SELECTs: Can I force a TRUE db read every time?

Question

Good day everyone!
I've been programming in ABAP for almost 6 years now, and I'd like to begin learning more about performance tuning with respect to database performance.
More specifically, I'm testing some things in a particular SELECT in a report program we have that is timing out in the foreground because of the SELECT.  When I first run the program, the SELECT goes against the database, as we all know.  Subsequent runs, however, use the buffered data, so the response is a lot quicker and doesn't really reflect that first, initial database read.
Am I correct in assuming that I should be testing my various approaches and collecting performance runtimes against that initial, "true" database read?  If that's the case, is there any way I can force the system to actually read the database instead of the buffered data?  For those experienced with this kind of performance analysis and tuning, what's the best approach for someone very new to this area such as myself?
Thank you,
Dave

Answer 1

Hi Dave and Rob,
Just my two cents (and yes, I know this is already answered, but..).
I think you might be confusing 2 things: one is SAP buffering, and another one is caching at other levels (database, operating system, etc).
From what I understood Rob was talking mainly about SAP buffering. In that context it is true that if there is a first execution that loads the buffers (for example, some not so small fully buffered tables) then that is an atypical execution, and should be discarded. In real life you will never have execution times like those, except maybe on the very first execution on a monday morning.
Another thing is database caching. If you execute a report twice with exactly the same parameters then you might not be actually making physical reads in the second execution. This second execution will be very fast, but that will not be simulating real life: no user wants a report to be fast the second time you execute it with exactly the same parameters.
To avoid this in Oracle you can empty the so-called SGA, but that is not so useful and it will probably not get you closer to what happens in the real life.
So what to do? In doubt, measure it several times, with different parameters, and probably exclude the extreme values.
Regards,
Rui Dantas