Comments on: dbms_xplan – again

By: Mything 2 « Oracle Scratchpad

Mything 2 « Oracle Scratchpad — Fri, 24 Jun 2011 17:53:08 +0000

[...] it doesn’t – and there’s a clue about why not in the “Predicate Information”. To create this plan the optimizer would have to duplicate an existing predicate (c1 = 5) so that [...]

By: Join Surprise « Oracle Scratchpad

Join Surprise « Oracle Scratchpad — Wed, 15 Dec 2010 20:56:36 +0000

[...] of the plan is much lower as a consequence.. You’ll also notice that the predicate sections (always check the predicate section) are a little different – the order of evaluation has been [...]

By: Buffer Sorts – 2 « Oracle Scratchpad

Buffer Sorts – 2 « Oracle Scratchpad — Fri, 07 May 2010 08:50:32 +0000

[...] The owner of the query is going to be using dbms_xplan, checking the estimated cardinalities and predicates, to check why Oracle came up with a Cartesian [...]

By: Cursor Sharing 3 « Oracle Scratchpad

Cursor Sharing 3 « Oracle Scratchpad — Mon, 03 May 2010 20:58:35 +0000

[...] first response, of course, should be to tell me off for not showing the complete execution plan. Always genreate and look at the predicate sections which, in this case, also shows some [...]

By: Predicate (again) « Oracle Scratchpad

Predicate (again) « Oracle Scratchpad — Thu, 15 Apr 2010 18:18:37 +0000

[...] Lewis @ 6:17 pm UTC Apr 15,2010 I often make a fuss about making sure that people include the predicate section when looking at execution plans. Here’s another example demonstrating why it can be so [...]

By: Ignoring Hints – 2 « Oracle Scratchpad

Ignoring Hints – 2 « Oracle Scratchpad — Thu, 11 Feb 2010 19:29:56 +0000

[...] Have you spotted the critical clue ? It’s in the predicate sections. [...]

By: Predicate Problems « Oracle Scratchpad

Predicate Problems « Oracle Scratchpad — Fri, 26 Jun 2009 13:33:59 +0000

[...] — Jonathan Lewis @ 8:47 pm UTC Dec 3,2008 Whenever you look at an execution plan, you must look at the predicate section (introduced in 9i) before you start trying to work out what’s gone wrong. Here’s an example [...]

By: Trouble-shooting « Oracle Scratchpad

Trouble-shooting « Oracle Scratchpad — Mon, 14 Jan 2008 13:32:58 +0000

[...] so we are a little deprived of clues. The execution plan should always be a proper report from dbms_xplan, showing the access_predicates and filter_predicates. In this case, we may find that (for reasons [...]

By: Ganesh

Ganesh — Mon, 08 Oct 2007 19:29:46 +0000

Thanks.

Ganesh

By: Jonathan Lewis

Jonathan Lewis — Fri, 05 Oct 2007 09:10:44 +0000

Ganesh, I see Jeff Kemp has supplied the answer. The position of rows in a table is not predicatable, and any time you want an ordered output, you must be able to supply an "order by" clause. I'd go one step further than Jeff, possibly: [sourcecode language="sql"] create table jpl_plan as select 'Some Label Text' tag, rownum rn, plan_table_output plan_line from table(dbms_xplan.display_cursor('9tz4qu4rj9rdp')) where rownum = 0 ; [/sourcecode] This happens to use a particular cursor that I know is in memory to give me the table structure. Then I can use Jeff's "insert as select" with a piece of text to label every plan as I create it: [sourcecode language="sql"] insert into jpl_plan select 'LABEL1', rn, plan_table_output from ... commit; select plan_table_output from jpl_plan where tag = 'LABEL1' order by rn ; [/sourcecode]