Comments on: Testing Autotrace

By: Analytic Agony « Oracle Scratchpad

Analytic Agony « Oracle Scratchpad — Mon, 07 Sep 2009 18:23:07 +0000

[...] I’ve turned on some tracing and enabled autotrace. Apart from the extended sql_trace (event 10046 at level 8 ) I’ve also enabled a trace on [...]

By: Norman Dunbar

Norman Dunbar — Fri, 04 Sep 2009 07:13:30 +0000

Hi Jonathan,

I’m puzzled (as ever!) by the fact that an explain plan is generated from the Optimiser generating the plan from a parse of a statement. Why, or how, can the actual execution plan differ from the one ‘prepared’ by the optimiser?

Surely the optimiser has worked out the best execution plan and that’s what *should* be run, but if not, who or what decided on running a different plan that the optimiser didn’t work out?

Thanks.

Cheers,
Norman.

By: Kyle Hailey

Kyle Hailey — Thu, 03 Sep 2009 16:24:42 +0000

It’s clear that the explain plan can vary between the live plan and the explain plan when the analyzing (a DBA for example) session is different from the running session (a user for example) but I was trying to think if an explain plan could be different from the live plan in the same session – all the parameters,settings, grants, schema would be the same so why would the plans differ? There is one reason that you mentioned in CBOF p54 is that EXPLAIN PLAN doesn’t do bind variable peaking and it could also get bind variable data types wrong leading to the wrong plan.

Now I’m curious why AUTOTRACE does all the sampling of data and such instead of just reading the execution stats from v$sql_plan_statistics_all. The stats in $sql_plan_statistics_all are empty unless something like _rowsource_execution_statistics=true, but that would be easy for autotrace to do and this has been possible since 9i.

Kyle Hailey

By: Jonathan Lewis

Jonathan Lewis — Thu, 03 Sep 2009 13:01:59 +0000

Kyle,

That’s correct.

In fact, worst case scenario, you can even be fooled when you run the SQL yourself and check the trace or v$sql_plan. It’s always possible that you (the trouble-shooter) have a different environment from the typical end-user, and it may be an environment change that results in a different execution plan. (e.g. national character set, case insensitive sorting, session level settings for optimizer parameters).

By: Kyle Hailey

Kyle Hailey — Wed, 02 Sep 2009 21:38:52 +0000

Hey Jonathan,

Following up on Adam’s comments and tests, if I understand correctly, AUTOTRACE never prints out the live plan but always a plan from the EXPLAIN PLAN command as opposed to V$SQL_PLAN.

The only way to get the live plan is to TRACE or use v$sql_plan?

Best
Kyle

By: Mirjana

Mirjana — Wed, 31 Oct 2007 15:08:49 +0000

Excellent post!

By: Jonathan Lewis

Jonathan Lewis — Sun, 08 Apr 2007 17:17:30 +0000

prichard,
You can’t – it’s one of the really irritating defects of dbms_xplan.display(). You have to judge it by eye, which isn’t easy for a plan longer than a dozen lines or so.

By: prichard

prichard — Sun, 08 Apr 2007 16:32:53 +0000

How do I get autotrace to show me the parent Id column in 10gr2?

By: Jonathan Lewis

Jonathan Lewis — Sun, 08 Apr 2007 16:03:16 +0000

Prichard, The format of the autotrace output changed from 10.1 to 10.2 - that's partly why I tried to label every autotrace output in the book with the version it came from. Autotrace in 10.2 uses a call to the dbms_xplan.display() function. You will probably find, by the way, that some of the execution plans in the examples change when you run the test cases on 10.2 - there were a lot of changes to the optimizer in that version.

By: prichard

prichard — Sun, 08 Apr 2007 15:05:18 +0000

I am currently going through your CBO Fundamentals book and have set up a test 10gr2 database for going through the examples in your book.

I want to know how to get autotrace to display an execution plan as shown in your book –

Execution Plan (10.1.0.4 autotrace)
———————————————————-
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=4 Card=200 Bytes=20600)
1 0 TABLE ACCESS (FULL) OF ‘T1′ (TABLE) (Cost=4 Card=200 Bytes=20600)

But all I get to see is this –

Execution Plan
———————————————————-
Plan hash value: 3617692013

———————————————————-
| Id | Operation | Name | Rows | Bytes | Cost |
———————————————————-
| 0 | SELECT STATEMENT | | 200 | 20600 | 4 |
|* 1 | TABLE ACCESS FULL| T1 | 200 | 20600 | 4 |
———————————————————-