Comments on: Fair Comparison

By: Jonathan Lewis

Jonathan Lewis — Mon, 30 Aug 2010 14:22:02 +0000

Flado,

Nice idea. It gets around the problem of the optimizer optimizing out redundant joins and column projections and getting different plans from the execution you’d see in production.

With the PL/SQL optimizer constantly getting smarter, though, it would be interesting to see if PL/SQL eventually notices that you’re not using data from the cursor inside the loop and starts rewriting the cursor statement.

By: Flado

Flado — Mon, 30 Aug 2010 14:03:09 +0000

Stew,
Yeah, re-working the script to use SYSTIMESTAMP, better interval formatting, and BULK COLLECT has been on my list for some time. On the other hand, a precision of 0.01 seconds is more than enough for the types of queries I test, the formatting works “as is” for elapsed times of 1 day or less, and nowadays PL/SQL does the array fetches for me, so…
It is by no means a clean experimental set-up, but it is nevertheless able to detect significant network throughput problems (or latency problems, if you do the AUTOTRACE TRACEONLY with a low array size), and that’s the only purpose I use it for.

By: Stew Ashton

Stew Ashton — Mon, 30 Aug 2010 12:25:15 +0000

Flado,

Good idea. In addition to timing, this is a good way to run the query to completion in other tools than SQL*Plus. I do this a lot in SQL Developer so I can run dbms_xplan.display_cursor afterwards. I know there are equivalents to display_cursor in SQL Developer, but they can’t be pasted easily into blog comments / asktom questions :)

Just a detail: Jonathan mentioned using different array sizes. With your method, the array size will be either 1 (in 9i or before) or 100 (in 10g or later).

By: Flado

Flado — Mon, 30 Aug 2010 07:34:17 +0000

I also found it useful to compare the elapsed time I get using "autotrace traceonly" to the elapsed time reported by my testview.sql script (below). The script gives me pure database time (first row and last row), and the comparison to "autotrace traceonly" yields the network transfer time. It might be nitpicking, but I think it's always worth pointing out that "last row" timing includes the time needed to check that there are no more rows to return. Here's the script. It's pretty old (8i), which explains the 'manual' interval formatting. The only argument is the name of a file containing the query under test. "@&viewname" *must* be on a line by itself, with no leading whitespace. [sourcecode] define viewname=&1 set serverout on size 100000 set timi on declare i integer:=0; stt number; rsp number; begin stt:=dbms_utility.get_time; for bz in ( @&viewname ) loop if rsp is null then rsp:=dbms_utility.get_time-stt; end if; i:=i+1; end loop; stt:=dbms_utility.get_time-stt; dbms_output.put_line(substr('Count: '||i,1,255)); dbms_output.put_line('Elapsed: '|| to_char(trunc(sysdate)+trunc(stt/100)/3600/24,'HH24:MI:SS')||'.'|| ltrim(to_char(mod(stt,100),'00')) ); dbms_output.put_line('First row: '|| to_char(trunc(sysdate)+trunc(rsp/100)/3600/24,'HH24:MI:SS')||'.'|| ltrim(to_char(mod(rsp,100),'00')) ); end; / [/sourcecode]