Comments on: Predicate Problems

By: Timur Akhmadeev

Timur Akhmadeev — Fri, 12 Nov 2010 20:04:06 +0000

Just a heads up on a problem one might encounter while trying to get plan with predicates: if you have "_cursor_plan_unparse_enable" parameter set to false (for ex., Oracle Support asked you to do this to workaround a bug), you may not see predicates section. This was mentioned in this thread on SQL.ru.

By: Filter “Bug” « Oracle Scratchpad

Filter “Bug” « Oracle Scratchpad — Tue, 31 Aug 2010 19:02:20 +0000

[...] Lewis @ 7:01 pm UTC Aug 31,2010 Here’s an example to remind you how important it is to look at the “Predicate Information” supplied with an execution plan. Here are two execution plans that look very similar in shape [...]

By: Jonathan Lewis

Jonathan Lewis — Mon, 12 Jul 2010 20:25:33 +0000

Padders,

Thanks for that note. I can’t think why I didn’t check the oraus.msg file myself – it’s always a good place to look if you can’t find anything suggestive in the full parameter list.

By: Padders

Padders — Mon, 12 Jul 2010 14:37:24 +0000

Just a note to say event 10195 “CBO don’t use check constraints for transitive predicates” seems helpful in scratch tests, pending buy-in from our DBAs.

By: Jonathan Lewis

Jonathan Lewis — Fri, 09 Jul 2010 13:34:51 +0000

Padders,
No workaround that I know of. (Other than upgrading).

You might try adjusting the query_rewrite_enabled parameter – but that’s just a shot in the dark because it has had some unexpected side-effects in the past that have nothing (apparently) to do with query rewrite.

By: Padders

Padders — Fri, 09 Jul 2010 09:37:42 +0000

Sorry for late comment, we are hitting issues with this in 9.2.0.6, please can you confirm if any workarounds are known.

By: Old plan_table « Oracle Scratchpad

Old plan_table « Oracle Scratchpad — Mon, 25 Jan 2010 08:29:09 +0000

[...] lost count of the number of times I’ve told people that the predicate section of an execution plan is vital to understanding what’s really going on, and it’s usually the predicate section [...]

By: Vivek

Vivek — Wed, 24 Dec 2008 13:05:02 +0000

Hi All,

For me…it worked too in 10.2.0.1 Windows Machine.

Regards
Vivek

By: Dilip Patel

Dilip Patel — Fri, 19 Dec 2008 13:00:49 +0000

Jonathan, Richardo. I have tested this 9.2.0.7 and 10.2.0.3. It behaves exactly as Jonathan wrote on blog. 9.2.0.7 [sourcecode] ---------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost | ---------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 10 | 10 | | 1 | SORT AGGREGATE | | 1 | 10 | | |* 2 | TABLE ACCESS BY INDEX ROWID| T1 | 5 | 50 | 10 | |* 3 | INDEX RANGE SCAN | T1_PK | 99 | | 2 | ---------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 2 - filter("T1"."N1"+"T1"."N2">=0) 3 - access("T1"."ID"<100) [/sourcecode] 10.2.0.3 [sourcecode] --------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | --------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 4 | 2 (0)| 00:00:01 | | 1 | SORT AGGREGATE | | 1 | 4 | | | |* 2 | INDEX RANGE SCAN| T1_PK | 99 | 396 | 2 (0)| 00:00:01 | --------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 2 - access("ID"<100) [/sourcecode]

By: Jonathan Lewis

Jonathan Lewis — Fri, 05 Dec 2008 10:11:52 +0000

Ricardo,
I’ve just re-run this on 10.2.0.1, cutting and pasting from the blog. It behaves the way I said.

Can you check that your version really is 10.2.0.l – and if it has any patches, or any of the less common (optimizer) parameters set.