Oracle Optimizer Mode Choose / Rule

Hello,
we have a strange behavior with Oracle 9.2
We have a application doing
SELECT to_char(COLUMNNAME)
FROM
VIEW WHERE ROWNUM = 1
This statement needs 75 seconds executed on the server within the application.
call count cpu elapsed disk query current rows
Parse 68 0.01 0.02 1 108 0 0
Execute 136 0.14 0.14 0 0 0 0
Fetch 68 68.74 75.64 119587 181628 2 68
total 272 68.89 75.81 119588 181736 2 68
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 25
Rows Row Source Operation
1 COUNT STOPKEY
1 HASH JOIN
524213 TABLE ACCESS FULL TABLEA
6 INDEX FAST FULL SCAN INDEX (object id 7026)
Optimizer mode is CHOOSE and we have generated Statistics.
When we switch to RULE the SQL will perform within millseconds
call count cpu elapsed disk query current rows
Parse 68 0.01 0.00 0 2 0 0
Execute 68 0.00 0.00 0 0 0 0
Fetch 68 0.01 0.05 68 476 0 68
total 204 0.02 0.05 68 478 0 68
Misses in library cache during parse: 1
Optimizer goal: RULE
Parsing user id: 25
Rows Row Source Operation
1 COUNT STOPKEY
1 NESTED LOOPS
1 TABLE ACCESS FULL TABLEA
1 INDEX UNIQUE SCAN INDEX (object id 7026)
Even when executing this statement within SQLPLUS on the server it takes 1 second (even too long but not 70 seconds).
Has anybody a hint where to look ?? I´m really confused.
Kind Regards,
Klaus

Optimizer mode choose with statistics effectively means ALL_ROWS. So I suspect that this probably is the reason why Oracle uses full scans and hash joins. On the other hand rownum = 1 should give the optimizer info that you only need 1 row back. So probably try with either optimizer_mode = first_rows_1 or hint first_rows(1) and see what happens.
Gints Plivna
http://www.gplivna.eu

Similar Messages

Optimizer mode in oracle 10g

what is the difference between setting optimizer mode in oracle 10g
optimizer_mode=choose
optimizer_mode=all_rows

user446367 wrote:
what i have to set for the below parameters . any idea ?
optimizer_index_caching
optimizer_index_cost_adjIn general you would leave them set at the default value in 10g (and probably, in most earlier versions, for most cases as well). Even if you were to change them, asking for specific values on an internet forum is rather asking for trouble, it's not dissimilar to asking "what should I set for the parameter processes?" A reasonable value will be application dependent.
The first parameter reduces the cost of some types of indexed access by assuming that only the specified percentage of index i/o actually results in a physical I/O and therefore only that percentage of the io cost is taken into account. By contrast all tablescan access and the other types of indexed access are assumed to be uncached and therefore need costing.
The second parameter just arbitrarily scales indexed access path costings.
You could argue, and some have, that you could calculate a cache hit ratio for index blocks in much the same way as you can calculate a cache hit ratio generally and then set the first parameter to this value. The standout problems with this approach are
1) It applies to all matching statements and objects not just your problem ones.
2) It doesn't necessarily even apply to your problem statements.
3) It doesn't have anything to do with query duration per se, just efficiency of one particular access path.
4) People tend to choose to round costs down and make the likelihood of two plans getting the same cost and being chosen on a tiebreaker basis higher.
The second parameter just asks you how much you like the idea of indexes generally. If you are going to change it pick a family members age or something - it'll make you smile every time you see it.
Niall Litchfield
http://www.orawin.info/

Partitioning on Oracle 8.0.6 (rule base vs. cost base)

At my current engagement, we are using Oracle Financials 11.0.3 on Oracle 8.0.5 which uses rule-based optimizer. However, it is been planned to upgrade the database from Oracle 8.0.5 to Oracle 8.0.6 as well as implement Oracle partitioning. With this in mind, we are concerned about possible performance issues that the implementation of partitioning may cause since RBO does not recognize it.
We agree that the RBO will see a non-partitioned table the same as a partitioned. In this scenario where you gain the most is with backup/recoverability and general maintenance of the partitioned table.
Nevertheless, we have a few questions:
When implementing partitions, will the optimizer choose to go with Cost base vs. Rule base for these partitioned tables?
Is it possible that the optimizer might get confused with this?
If this change form RBO to CBO does occur, the application could potential perform poorly because of the way it has been written.
Please provide any feedback.
thanks in advance.

If the CBO is invoked when accessing these tables, you may run into problems.
- You'll have to analyze your tables & ensure that the statistics are kept up to date.
- It's possible that any SQL statements which invoke the CBO rather than the RBO will have different performance characteristics. The SYSTEM data dictionary tables, for example, must use the RBO or their performance suffers dramatically. Most of the time, the CBO beats the RBO, but applications which have been heavily tuned with the RBO may have problems with the CBO.
- Check your init.ora to see what optimizer mode you're in. If you're set to CHOOSE, the CBO will be invoked whenever statistics are available on the table(s) involved. If you choose RULE, you'll only invoke the CBO when the RBO encounters situations it doesn't have rules for.
Justin

Set optimizer mode for someone else possible?

I know that I can use the sys.dbms_system package to set tracing on for another session but cannot figure how to change their optimizer mode - if it's possible at all.
I have tried this -
exec sys.dbms_system.set_bool_param_in_session(20,176,'optimizer_mode=choose',TRUE);
PL/SQL procedure successfully completed.
SQL> show parameter opt
NAME TYPE VALUE
object_cache_optimal_size integer 102400
optimizer_features_enable string 8.1.7
optimizer_index_caching integer 0
optimizer_index_cost_adj integer 100
optimizer_max_permutations integer 80000
optimizer_mode string RULE
optimizer_percent_parallel integer 0
Tried the 'set_int_param_in_session' but 'choose' is not an integer.
Thanks in advance for any help.

Hi,
in design center, select "configure" in the context menu of a mapping. Under table operators, select a table and set the extraction hint.
Regards,
Carsten.

About optimizer mode

Hi,
How to change the optimizer mode from ALL_ROWS
Thanks

Whether we do not know the OP's Oracle version, we can assume it is not 8i or 9i. Do you realize the link you provided is very old. Still speaking about RULE optimizer, "analyze table" command (both becoming obsolete then depracted) without telling anything about more modern database such as 10g+. Moreover there're some rule of thumbs which can mislead query tuning.
Much better to refer to the Oracle document that Pierre linked to in first place.
And why not ask to the OP, why he/she wants to modify the optimizer from ALL_ROWS to what value with what expected results, based on what analyzes...
Nicolas.

Optimizer mode confusion

Hello experts,
When we set optimizer mode to first_rows_100 or first_rows etc. The fetch rows doesn't change. I am trying to understand the differences between first_rows and all_rows. It gives preference to index scan against full table scan, even the index scan is no good. And also prefers nested loop over hash join. HOWEVER, except all these, please correct me if I am wrong, I do understand that first_nows_100 only fetch 100 rows regardless default fecth row, am I wrong? What do you think about the following example in terms of CONSISTENT GETS????
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> alter system flush shared_pool;
Sistem dei■tirildi.
SQL> set autotrace traceonly
SQL> select * from my_test where id < 181000;
31000 sat²rlar² seildi.
Y³r³tme Plan²
Plan hash value: 1615681525
| Id | Operation         | Name    | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |         | 31001 |   605K|    53   (2)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| MY_TEST | 31001 |   605K|    53   (2)| 00:00:01 |
Predicate Information (identified by operation id):
   1 - filter("ID"<181000)
¦statistikler
        454 recursive calls
          0 db block gets
       2323 consistent gets
         93 physical reads
        116 redo size
     843244 bytes sent via SQL*Net to client
      23245 bytes received via SQL*Net from client
       2068 SQL*Net roundtrips to/from client
          6 sorts (memory)
          0 sorts (disk)
      31000 rows processed
SQL> select * from my_test where id < 181000;
31000 sat²rlar² seildi.
Y³r³tme Plan²
Plan hash value: 1615681525
| Id | Operation         | Name    | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |         | 31001 |   605K|    53   (2)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| MY_TEST | 31001 |   605K|    53   (2)| 00:00:01 |
Predicate Information (identified by operation id):
   1 - filter("ID"<181000)
¦statistikler
          0 recursive calls
          0 db block gets
       2235 consistent gets
          0 physical reads
          0 redo size
     843244 bytes sent via SQL*Net to client
      23245 bytes received via SQL*Net from client
       2068 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
      31000 rows processed
SQL> alter session set optimizer_mode = FIRST_ROWS_100;
Oturum dei■tirildi.
SQL> select * from my_test where id < 181000;
31000 sat²rlar² seildi.
Y³r³tme Plan²
Plan hash value: 509756919
| Id | Operation                   | Name         | Rows | Bytes | Cost (%CPU)
| Time     |
|   0 | SELECT STATEMENT            |              |   100 | 2000 |     4   (0)
| 00:00:01 |
|   1 | TABLE ACCESS BY INDEX ROWID| MY_TEST      |   100 | 2000 |     4   (0)
| 00:00:01 |
|* 2 |   INDEX RANGE SCAN          | SYS_C0011105 |       |       |     2   (0)
| 00:00:01 |
Predicate Information (identified by operation id):
   2 - access("ID"<181000)
¦statistikler
          1 recursive calls
          0 db block gets
       4402 consistent gets
          0 physical reads
          0 redo size
    1159430 bytes sent via SQL*Net to client
      23245 bytes received via SQL*Net from client
       2068 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
      31000 rows processed
Thanks in adnvance.

the first_rows(n) hint is only about costing and instructs the optimizer to find a plan that returns the first n rows as fast as possible - though this approach may increase the total execution time for the query. This could be useful for applications that need only the top results most the time. Consider the following example:
drop table t;
create table t (
    col1 not null
, col2
as
select mod(rownum, 100) col1
     , lpad('*', 50, '*') col2
from dual
connect by level <= 100000;
exec dbms_stats.gather_table_stats(user, 'T')
create index t_idx on t(col1);
explain plan for
select *
from t
where col1 = 1
order by col1;
select * from table(dbms_xplan.display);
| Id | Operation         | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |      | 1000 | 54000 |   423   (0)| 00:00:03 |
|* 1 | TABLE ACCESS FULL| T    | 1000 | 54000 |   423   (0)| 00:00:03 |
Predicate Information (identified by operation id):
   1 - filter("COL1"=1)
explain plan for
select /*+ first_rows(10) */
from t
where col1 = 1
order by col1;
select * from table(dbms_xplan.display);
| Id | Operation                   | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT            |       |    10 |   540 |    10   (0)| 00:00:01 |
|   1 | TABLE ACCESS BY INDEX ROWID| T     |    10 |   540 |    10   (0)| 00:00:01 |
|* 2 |   INDEX RANGE SCAN          | T_IDX |       |       |     1   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - access("COL1"=1)
Obiously the hint changes the costing massively - and for the given query the top 10 results could indeed be returned faster by the index scan (though the difference would be small for this small example).
The details of the costing are not that simple and they are described in Randolf Geist's presentation http://www.sqltools-plusplus.org:7676/media/FIRST_ROWS_n%20presentation%20UKOUG%202009.pdf (titled: Everything you wanted to know about first_rows_n but were afraid to ask).

EXPORT 와 OPTIMIZER MODE

제품 : ORACLE SERVER
작성날짜 : 2002-04-08
EXPORT 와 OPTIMIZER MODE 관계
=============================
PURPOSE
다음은 EXPORT와 OPTIMIZER MODE의 관계에 대해 알아본다.
Explanation
EXPORT시 5 분 걸리던 작업이 init.ora 에 optimizer_mode=first_rows 로
하면 20 시간이 걸리는 현상이 발생된다.
이는 BUG# 391656 이었으며 optimizer_mode 를 first_rows 로 설정후
export시 rows=n 으로 주어도 export time이 굉장히 오래 걸린다는 내용으로
event 10046을 setting후 각 statement path 를 check 해보니 optimezer 가
CDEF$ 와 COL$ table 을 fulle scan 하는 것으로 나타 났다.
이들 table 은 EXU7COLU view 에 의해 실행되고 , 만일 DB 에 constraint가
많고 table comment 가 많다면 많은 시간이 걸려서 이러한 결과가 나타난다.
이 경우는 CDEF$ 와 COL$를 analyze 한다 하더라도 별 도움이 안되고
optimizer_mode=first_rows 를 사용하지 말아야 한다는 것이다.
V7.1.6 에서의 임시 workaround 로
CREATE OR REPLACE view exu7grnu AS
SELECT * from exu7grn WHERE grantorid = UID AND creatorid+0 = UID
CREATE OR REPLACE view exu7cgru AS
SELECT * from exu7cgr WHERE grantorid = UID AND creatorid+0 = UID
CREATE OR REPLACE view exu7spsu(obj#, line, source) AS
SELECT s.obj#, s.line, s.source
FROM sys.source$ s, sys.obj$ o
WHERE s.obj# = o.obj# and o.owner#+0 = UID
처럼 view 를 create 하는 방법이 있다.
Reference Ducuments
--------------------

Jim,
Export does run in a background process. There are actually at least 3 processes running.
1. You have the client, which is where you run your expdp/impdp command.
2. You have the MCP processes which is a Data Pump process
3. You have a WORKER processes (or more if you use parallel) that are Data Pump processes.
I always use LINUX, but I think it works the same for Windows. Once you have the job running, you can type a CTL-C and you will get to an IMPDP> or EXPDP> prompt. This allows you to do other commands. One is to exit the client process. You can also stop the job or kill the job. Try it and type HELP at one of those prompts.
At this same prompt, you can type STATUS will will give you some idea on what is being worked on.
Some of the reasons you would want to attach to a job is
1. You previously exited and want to reattach to change something.
2. You left it running while you were in the office and now you are home and want to see the status. (you can have multiple clients attached to the same data pump job.
3. Your job stopped for some reason (power outage, failure, etc.) and you want to restart it.
Hope this helps.
Dean

(OT) Incompatible Apache Mod-Rewrite Rules

The following Apache mod-rewrite rule works:
RewriteRule ^About/([a-zA-Z0-9_/-]+)/?$
About/index.php?bout=$1 [L]
It displays URL's like mysite/About/Webmaster and
mysite/About/Search.
I've finally figured out how to apply a mod-rewrite rule to
my site's
home page...
RewriteRule ^/?([-a-zA-Z0-9_/]+)/?$ /index.php?home=$1 [L]
It displays URL's like mysite/Arizona and mysite/Africa.
But when I combine them...
RewriteRule ^/?([-a-zA-Z0-9_/]+)/?$ /index.php?home=$1 [L]
RewriteRule ^About/([a-zA-Z0-9_/-]+)/?$
About/index.php?bout=$1 [L]
The first rewrite rule appears to knock the second rule out
of action.
Does anyone know how to modify either rewrite rule to make
them compatible?
Thanks.

On 4/26/06 8:52 AM, "David Blomstrom" wrote:
> The following Apache mod-rewrite rule works:
>
> RewriteRule ^About/([a-zA-Z0-9_/-]+)/?$
About/index.php?bout=$1 [L]
>
> It displays URL's like mysite/About/Webmaster and
mysite/About/Search.
>
> I've finally figured out how to apply a mod-rewrite rule
to my site's
> home page...
>
> RewriteRule ^/?([-a-zA-Z0-9_/]+)/?$ /index.php?home=$1
[L]
>
> It displays URL's like mysite/Arizona and mysite/Africa.
>
> But when I combine them...
>
> RewriteRule ^/?([-a-zA-Z0-9_/]+)/?$ /index.php?home=$1
[L]
> RewriteRule ^About/([a-zA-Z0-9_/-]+)/?$
About/index.php?bout=$1 [L]
>
> The first rewrite rule appears to knock the second rule
out of action.
> Does anyone know how to modify either rewrite rule to
make them compatible?
>
> Thanks.
I'm not an expert on mod_rewrite, but you might be able to
get what you want
simply by reversing the order of the rules:
RewriteRule ^About/([a-zA-Z0-9_/-]+)/?$
About/index.php?bout=$1 [L]
RewriteRule ^/?([-a-zA-Z0-9_/]+)/?$ /index.php?home=$1 [L]
In theory, that should redirect your /About pages, and the
[L] tells Apache
not to parse any more rewrite rules, so the first rule (which
looks like it
simply redirects *everything*) wouldn't come into play.
There's something about times when Apache still parses
rewrite rules even
after the [L] flag, though, so that might not work. Why don't
you see if
that works, and if it doesn't, we can look at it further.
Sonjay

Set optimizer mode for mapping

How can i set the optimizer mode(for example, "all_rows") explicitly for a mapping?
~Prabha

Hi,
in design center, select "configure" in the context menu of a mapping. Under table operators, select a table and set the extraction hint.
Regards,
Carsten.

How to get the Optimizer Mode

How can I get the optimizer mode from the database? I've tried by querying the table V$PARAMETER but I get "table or view does not exist" even if verifying in ALL_OBJECTS I see that it's indicated as Owner PUBLIC. Could you help me? Thanks

SQL> connect hr/hr
Connected.
SQL> SHOW PARAMETER OPTIMIZER_MODE
ORA-00942: table or view does not exist
SQL> connect sys/girish as sysdba
Connected.
SQL> SHOW PARAMETER OPTIMIZER_MODE
NAME TYPE VALUE
optimizer_mode string ALL_ROWSGirish Sharma

Which column first filter by oracle optimizer

Can somebody help in understand which column first filter by oracle optimizer in below example and why?
select * from emp where ENAME ='FORD'
AND SAL=3000 ;

Hi,
Look at the EXPLAIN PLAN.
Other things being equal, if there are more distinct values of ename than of sal, then it's probably checking for 'FORD' first.
For example, say the table has 100,000 rows, and there are 10,000 distinct enames, and 100 distinct sals, both ename and sal are indexed, but there is no combined index.
If you search by sal first, that means you'll expect around 1,000 rows from the index search, and then you'll have to test each of those 1,000 rows for the right ename.
If you search by ename, first, that means you'll expect around 10 rows from the index search, and you'll only have to test each of those 10 rows for the right sal.
The order in which the conditions were written will matter.
Edited by: Frank Kulash on Apr 2, 2012 7:54 AM

Optimizer Mode - Rule or Choose

Is it ok to use
Alter session set optimizer_mode=RULE?
in Oracle9i and Oracle10g?
thanks.

New book on physical database design, discussing how to design indexes, range and hash partitioning, materialized views, storage layout, RAID, warehouse design and more. The book covers Oracle and several other major databases. Lots of diagrams and examples. An excellent text for people who design and administer databases.
Available on Amazon and most other book sellers.
Physical Database Design: The Database Professional's Guide to Exploiting Indexes, Views, Storage, and More
by Sam S. Lightstone, Toby J. Teorey, Tom Nadeau
Paperback, 448 pages, publication date: MAR-2007
ISBN-13: 978-0-12-369389-1
ISBN-10: 0-12-369389-6
Series: The Morgan Kaufmann Series in Data Management Systems
Link on Amazon:
http://www.amazon.com/Physical-Database-Design-professionals-exploiting/dp/0123693896
Link on the publisher's web site:
http://www.elsevier.com/wps/find/bookdescription.cws_home/710637/description#description
Comments on the book can be sent to: [email protected]

Optimizer Mode

The database wizards are kicking my tables into cost based
mode. We run our queries in rule mode. When I use the DB
Servlet Wizard or the Info Bus Data Form Wizard, any tables
I use get "analyzed" which kicks any queries into cost based
mode because our DB is set for "choose".
Any ideas how to keep it from analyzing my tables?
thanks,
bl
null

Probably not. Is it just the plan order that's changed or has the cost changed too? More importantly does either version of the query take significantly longer to execute?
Incidentally, OPTIMIZER=CHOOSE does not mean the database always uses the CBO. It means it chooses. If none of the tables in the statement has statistics it uses the RBO. If one of the tables in the statement has statistics it uses the CBO. Note that if there are tables that don't have statistics, the database estimates (ie guesses) them, which can lead to some wildly inaccurate plans. This is why we should analyze whole schemas and not individual tables.
If you want to always use the CBO you should chnage the init.ora parameter to OPTIMIZER=COST
rgds, APC

Oracle 11g with OPTIMIZER_MODE=RULE go faster!!

I recently migrated Oracle 9.2.0.8 to Oracle 11g but the querys doesn't work as I hope.
The same query takes 3:20 min aprox using optimizer_mode=ALL_ROWS and 0:20 using optimizer_mode=RULE or using RULE hint.
The query in CBO makes a cartesian product between the indexes of the table.
This is one query and the "autrotrace on" log on Oracle 11g:
SELECT /*+ NO_INDEX (PK0004111303310) */MIN(BASE.ID_SCHED_TASK)+1 I
FROM M4RJS_SCHED_TASKS BASE
WHERE NOT EXISTS
(SELECT BASE2.ID_SCHED_TASK
FROM M4RJS_SCHED_TASKS BASE2
WHERE BASE2.ID_SCHED_TASK>BASE.ID_SCHED_TASK
AND BASE2.ID_SCHED_TASK<BASE.ID_SCHED_TASK+2)
ORDER BY 1 ASC
Execution Plan
Plan hash value: 3937517195
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 14 | | 328 (2)| 00:00:04 |
| 1 | SORT AGGREGATE | | 1 | 14 | | | |
| 2 | MERGE JOIN ANTI | | 495 | 6930 | | 328 (2)| 00:00:04 |
| 3 | INDEX FULL SCAN | PK0004111303310 | 49487 | 338K| | 119 (1)| 00:00:02 |
|* 4 | FILTER | | | | | | |
|* 5 | SORT JOIN | | 49487 | 338K| 1576K| 209 (2)| 00:00:03 |
| 6 | INDEX FAST FULL SCAN| PK0004111303310 | 49487 | 338K| | 33 (0)| 00:00:01 |
Predicate Information (identified by operation id):
4 - filter("BASE2"."ID_SCHED_TASK"<"BASE"."ID_SCHED_TASK"+2)
5 - access("BASE2"."ID_SCHED_TASK">"BASE"."ID_SCHED_TASK")
filter("BASE2"."ID_SCHED_TASK">"BASE"."ID_SCHED_TASK")
Statistics
1 recursive calls
0 db block gets
242 consistent gets
8 physical reads
0 redo size
519 bytes sent via SQL*Net to client
524 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
1 rows processed
Thanks to all !

Sorry Mschnatt, I posted the wrong query, i was testing with HINTS, the correct query is your posted query.
1* I analyzed the tables and the result is the same:
This is the query and "autorace on" log using OPTIMIZER_MODE=RULE on Oracle 11g:
SQL> R
1 SELECT MIN(BASE.ID_SCHED_TASK)+1 I
2 FROM M4RJS_SCHED_TASKS BASE
3 WHERE NOT EXISTS
4 (SELECT BASE2.ID_SCHED_TASK
5 FROM M4RJS_SCHED_TASKS BASE2
6 WHERE BASE2.ID_SCHED_TASK>BASE.ID_SCHED_TASK
7 AND BASE2.ID_SCHED_TASK<BASE.ID_SCHED_TASK+2)
8* ORDER BY 1 ASC
I
2
Elapsed: 00:00:00.33
Execution Plan
Plan hash value: 795265574
| Id | Operation | Name |
| 0 | SELECT STATEMENT | |
| 1 | SORT AGGREGATE | |
|* 2 | FILTER | |
| 3 | TABLE ACCESS FULL | M4RJS_SCHED_TASKS |
|* 4 | INDEX RANGE SCAN | PK0004111303310 |
Predicate Information (identified by operation id):
2 - filter( NOT EXISTS (SELECT 0 FROM "M4RJS_SCHED_TASKS" "BASE2"
WHERE "BASE2"."ID_SCHED_TASK"<:B1+2 AND "BASE2"."ID_SCHED_TASK">:B2))
4 - access("BASE2"."ID_SCHED_TASK">:B1 AND
"BASE2"."ID_SCHED_TASK"<:B2+2)
Note
- rule based optimizer used (consider using cbo)
Statistics
0 recursive calls
0 db block gets
101509 consistent gets
0 physical reads
0 redo size
519 bytes sent via SQL*Net to client
524 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
This is the query and "autorace on" log using OPTIMIZER_MODE=ALL_ROWA on Oracle 11g:
Elapsed: 00:03:14.78
Execution Plan
Plan hash value: 3937517195
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 12 | | 317 (2)| 00:00:04 |
| 1 | SORT AGGREGATE | | 1 | 12 | | | |
| 2 | MERGE JOIN ANTI | | 495 | 5940 | | 317 (2)| 00:00:04 |
| 3 | INDEX FULL SCAN | PK0004111303310 | 49487 | 289K| | 119 (1)| 00:00:02 |
|* 4 | FILTER | | | | | | |
|* 5 | SORT JOIN | | 49487 | 289K| 1176K| 198 (3)| 00:00:03 |
| 6 | INDEX FAST FULL SCAN| PK0004111303310 | 49487 | 289K| | 33 (0)| 00:00:01 |
Predicate Information (identified by operation id):
4 - filter("BASE2"."ID_SCHED_TASK"<"BASE"."ID_SCHED_TASK"+2)
5 - access("BASE2"."ID_SCHED_TASK">"BASE"."ID_SCHED_TASK")
filter("BASE2"."ID_SCHED_TASK">"BASE"."ID_SCHED_TASK")
Statistics
0 recursive calls
0 db block gets
242 consistent gets
0 physical reads
0 redo size
519 bytes sent via SQL*Net to client
524 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
1 rows processed
3* This is an example query, the problem persist in other bigger queries.
Thanks for you help

Preformance problem - Oracle does not choose the Materialized view

Hi,
Version 10204
I have the following Materialized view :
CREATE MATERIALIZED VIEW CRM.MV2_TUDWH_CRM_1201
TABLESPACE DW_LARGE
NOCACHE
NOLOGGING
COMPRESS
PARALLEL ( DEGREE DEFAULT INSTANCES DEFAULT )
BUILD IMMEDIATE
REFRESH COMPLETE ON DEMAND
WITH PRIMARY KEY
ENABLE QUERY REWRITE        <<<<<<<======
AS
SELECT DISTINCT CRM.CI_CUST_INFO.NAP_INT_CUST_NUM
FROM (   CRM.CI_CUST_INFO
        LEFT OUTER JOIN
           CRM.CM_CASE_DIM
        ON (CRM.CI_CUST_INFO.BO_ID = CRM.CM_CASE_DIM.BO_ID_CUST));When running the following statment , the MV is used as you can see from 10053 trace file:
Current SQL statement for this session:
EXPLAIN PLAN FOR
SELECT DISTINCT CRM.CI_CUST_INFO.NAP_INT_CUST_NUM
FROM (   CRM.CI_CUST_INFO
        LEFT OUTER JOIN
           CRM.CM_CASE_DIM
        ON (CRM.CI_CUST_INFO.BO_ID = CRM.CM_CASE_DIM.BO_ID_CUST))
============
Plan Table
============
----------------------------------------------------------------+-----------------------------------+-------------------------+
| Id | Operation                           | Name              | Rows | Bytes | Cost | Time      | TQ |IN-OUT|PQ Distrib |
----------------------------------------------------------------+-----------------------------------+-------------------------+
| 0   | SELECT STATEMENT                    |                   |       |       |    64 |           |      |      |           |
| 1   | PX COORDINATOR                     |                   |       |       |       |           |      |      |           |
| 2   |   PX SEND QC (RANDOM)               | :TQ10001          | 4694K |   28M |    64 | 00:00:01 |:Q1001| P->S |QC (RANDOM)|
| 3   |    HASH UNIQUE                      |                   | 4694K |   28M |    64 | 00:00:01 |:Q1001| PCWP |           |
| 4   |     PX RECEIVE                      |                   | 4694K |   28M |    48 | 00:00:01 |:Q1001| PCWP |           |
| 5   |      PX SEND HASH                   | :TQ10000          | 4694K |   28M |    48 | 00:00:01 |:Q1000| P->P |HASH       |
| 6   |       PX BLOCK ITERATOR             |                   | 4694K |   28M |    48 | 00:00:01 |:Q1000| PCWC |           |
| 7   |        MAT_VIEW REWRITE ACCESS FULL | MV2_TUDWH_CRM_1201| 4694K |   28M |    48 | 00:00:01 |:Q1000| PCWP |           |
----------------------------------------------------------------+-----------------------------------+-------------------------+
Predicate Information:
7 - access(:Z>=:Z AND :Z<=:Z)
Content of other_xml column
===========================
db_version     : 10.2.0.4
parse_schema   : SYS
plan_hash      : 4066877073
Outline Data:
/*+
    BEGIN_OUTLINE_DATA
      IGNORE_OPTIM_EMBEDDED_HINTS
      OPTIMIZER_FEATURES_ENABLE('10.2.0.4')
      OPT_PARAM('optimizer_dynamic_sampling' 3)
      OPT_PARAM('star_transformation_enabled' 'true')
      ALL_ROWS
      OUTLINE_LEAF(@"SEL$C0C89B4D")
      REWRITE(@"SEL$9E43CB6E" "MV2_TUDWH_CRM_1201")
      OUTLINE(@"SEL$9E43CB6E")
      MERGE(@"SEL$58A6D7F6")
      OUTLINE(@"SEL$3")
      OUTLINE(@"SEL$58A6D7F6")
      MERGE(@"SEL$1")
      OUTLINE(@"SEL$2")
      OUTLINE(@"SEL$1")
      FULL(@"SEL$C0C89B4D" "MV2_TUDWH_CRM_1201"@"SEL$030DBFD9")
    END_OUTLINE_DATA
                        But when running more complex statment - the MV does not even considered by the optimizer as an option , and does not exists in the 10053 trace file:
Current SQL statement for this session:
EXPLAIN PLAN FOR
SELECT CRM.CI_CUST_INFO.NAP_INT_CUST_NUM
    FROM (   CRM.CI_CUST_INFO
          LEFT OUTER JOIN
             CRM.CM_CASE_DIM
          ON (CRM.CI_CUST_INFO.BO_ID = CRM.CM_CASE_DIM.BO_ID_CUST))
   WHERE (CRM.CM_CASE_DIM.FIRST_PROVIDER_GRP_ID IN
             ('2565', '2611', '1190', '2610', '2612')
          AND (CRM.CM_CASE_DIM.ROW_ADDED_DTTM >= (SYSDATE - 60)))
ORDER BY CRM.CI_CUST_INFO.NAP_INT_CUST_NUM
============
Plan Table
============
--------------------------------------------------+-----------------------------------+-------------------------+---------------+
| Id | Operation                   | Name        | Rows | Bytes | Cost | Time      | TQ |IN-OUT|PQ Distrib | Pstart| Pstop |
--------------------------------------------------+-----------------------------------+-------------------------+---------------+
| 0   | SELECT STATEMENT            |             |       |       |   13K |           |      |      |           |       |       |
| 1   | PX COORDINATOR             |             |       |       |       |           |      |      |           |       |       |
| 2   |   PX SEND QC (ORDER)        | :TQ10002    |     1 |    56 |   13K | 00:01:26 |:Q1002| P->S |QC (ORDER) |       |       |
| 3   |    SORT ORDER BY            |             |     1 |    56 |   13K | 00:01:26 |:Q1002| PCWP |           |       |       |
| 4   |     PX RECEIVE              |             |     1 |    56 |   13K | 00:01:26 |:Q1002| PCWP |           |       |       |
| 5   |      PX SEND RANGE          | :TQ10001    |     1 |    56 |   13K | 00:01:26 |:Q1001| P->P |RANGE      |       |       |
| 6   |       HASH JOIN             |             |     1 |    56 |   13K | 00:01:26 |:Q1001| PCWP |           |       |       |
| 7   |        PX RECEIVE           |             |     1 |    31 |   11K | 00:01:12 |:Q1001| PCWP |           |       |       |
| 8   |         PX SEND BROADCAST   | :TQ10000    |     1 |    31 |   11K | 00:01:12 |:Q1000| P->P |BROADCAST |       |       |
| 9   |          PX BLOCK ITERATOR |             |     1 |    31 |   11K | 00:01:12 |:Q1000| PCWC |           | 1     | 8     |
| 10 |           TABLE ACCESS FULL | CM_CASE_DIM |     1 |    31 |   11K | 00:01:12 |:Q1000| PCWP |           | 1     | 8     |
| 11 |        PX BLOCK ITERATOR    |             | 4694K | 115M | 2121 | 00:00:14 |:Q1001| PCWC |           | 1     | 6     |
| 12 |         TABLE ACCESS FULL   | CI_CUST_INFO| 4694K | 115M | 2121 | 00:00:14 |:Q1001| PCWP |           | 1     | 6     |
--------------------------------------------------+-----------------------------------+-------------------------+---------------+
Predicate Information:
6 - access("CI_CUST_INFO"."BO_ID"="CM_CASE_DIM"."BO_ID_CUST")
10 - access(:Z>=:Z AND :Z<=:Z)
10 - filter((INTERNAL_FUNCTION("CM_CASE_DIM"."FIRST_PROVIDER_GRP_ID") AND "CM_CASE_DIM"."ROW_ADDED_DTTM">=SYSDATE@!-60))
12 - access(:Z>=:Z AND :Z<=:Z)Can one suggested a reason why the optimized did not choose the m.v ?
After all as you can see the only change is adding more predicate to the statment , e.g:
WHERE (CRM.CM_CASE_DIM.FIRST_PROVIDER_GRP_ID IN
('2565', '2611', '1190', '2610', '2612')
AND (CRM.CM_CASE_DIM.ROW_ADDED_DTTM >= (SYSDATE - 60)))
ORDER BY CRM.CI_CUST_INFO.NAP_INT_CUST_NUM
Thanks

Hello Bob,
Thanks for your replay.
I just recreacted the MV and this time i REMOVED the DISTINCT and ADD two columns :
CREATE MATERIALIZED VIEW CRM.MV2_TUDWH_CRM_1201
TABLESPACE DW_LARGE
NOCACHE
NOLOGGING
COMPRESS
NOPARALLEL
BUILD IMMEDIATE
REFRESH COMPLETE ON DEMAND
WITH PRIMARY KEY
ENABLE QUERY REWRITE
AS
SELECT CRM.CI_CUST_INFO.NAP_INT_CUST_NUM,
       CRM.CM_CASE_DIM.FIRST_PROVIDER_GRP_ID,
       CRM.CM_CASE_DIM.ROW_ADDED_DTTM
FROM (   CRM.CI_CUST_INFO
        LEFT OUTER JOIN
           CRM.CM_CASE_DIM
        ON (CRM.CI_CUST_INFO.BO_ID = CRM.CM_CASE_DIM.BO_ID_CUST));I rerun the first sql statment that in my first post.
What happen now is as followed :
- Optimizer choose to use MV , ONLY if i remove the DISTICT from the select statment.
- If add the DISTINCT to the select statment , oracle choose a diffrent plan.
Why ?
sql_id=ffr3mkc6z8rsv.
Current SQL statement for this session:
EXPLAIN PLAN FOR
SELECT DISTINCT CRM.CI_CUST_INFO.NAP_INT_CUST_NUM
FROM (   CRM.CI_CUST_INFO
        LEFT OUTER JOIN
           CRM.CM_CASE_DIM
        ON (CRM.CI_CUST_INFO.BO_ID = CRM.CM_CASE_DIM.BO_ID_CUST))
============
Plan Table
============
---------------------------------------------------------+-----------------------------------+-------------------------+---------------+
| Id | Operation                      | Name            | Rows | Bytes | Cost | Time      | TQ |IN-OUT|PQ Distrib | Pstart| Pstop |
---------------------------------------------------------+-----------------------------------+-------------------------+---------------+
| 0   | SELECT STATEMENT               |                 |       |       |   12K |           |      |      |           |       |       |
| 1   | PX COORDINATOR                |                 |       |       |       |           |      |      |           |       |       |
| 2   |   PX SEND QC (RANDOM)          | :TQ10003        | 4691K | 197M |   12K | 00:01:19 |:Q1003| P->S |QC (RANDOM)|       |       |
| 3   |    HASH UNIQUE                 |                 | 4691K | 197M |   12K | 00:01:19 |:Q1003| PCWP |           |       |       |
| 4   |     PX RECEIVE                 |                 |   24M | 1030M |   12K | 00:01:18 |:Q1003| PCWP |           |       |       |
| 5   |      PX SEND HASH              | :TQ10002        |   24M | 1030M |   12K | 00:01:18 |:Q1002| P->P |HASH       |       |       |
| 6   |       HASH JOIN OUTER          |                 |   24M | 1030M |   12K | 00:01:18 |:Q1002| PCWP |           |       |       |
| 7   |        PX RECEIVE              |                 | 4694K | 115M | 2121 | 00:00:14 |:Q1002| PCWP |           |       |       |
| 8   |         PX SEND HASH           | :TQ10001        | 4694K | 115M | 2121 | 00:00:14 |:Q1001| P->P |HASH       |       |       |
| 9   |          PX BLOCK ITERATOR     |                 | 4694K | 115M | 2121 | 00:00:14 |:Q1001| PCWC |           | 1     | 6     |
| 10 |           TABLE ACCESS FULL    | CI_CUST_INFO    | 4694K | 115M | 2121 | 00:00:14 |:Q1001| PCWP |           | 1     | 6     |
| 11 |        BUFFER SORT             |                 |       |       |       |           |:Q1002| PCWC |           |       |       |
| 12 |         PX RECEIVE             |                 |   24M | 431M |   10K | 00:01:05 |:Q1002| PCWP |           |       |       |
| 13 |          PX SEND HASH          | :TQ10000        |   24M | 431M |   10K | 00:01:05 |      | S->P |HASH       |       |       |
| 14 |           INDEX FAST FULL SCAN | CM_CASE_DIM_IX_3|   24M | 431M |   10K | 00:01:05 |      |      |           |       |       |
---------------------------------------------------------+-----------------------------------+-------------------------+---------------+
Predicate Information:
6 - access("CI_CUST_INFO"."BO_ID"="CM_CASE_DIM"."BO_ID_CUST")
10 - access(:Z>=:Z AND :Z<=:Z)

Oracle Optimizer Mode Choose / Rule

Similar Messages

Maybe you are looking for