RBO X CBO

Hi everybody.
I would like to understand where what we are missing here.
We have several installations running 10g, and it's default value for OPTIMIZER_MODE is ALL_ROWS. Well, if there are no statistcs for the application tables, the RDBMS uses by default RULE BASED OPTIMIZER. Ok.
After the statistics are generated (oracle job, automatic), the RDBMS turns to use COST BASED OPTIMIZER. I can understand that.
The problem is: why do several queries run much slower when using CBO? When we analyze the execution plan, we see the wrong indexes being used.
The solution I have for now is set OPTIMIZER_MODE=RULE. Then everything runs smoothly again.
Why does this happen? Shouldn't CBO, after the statistics are generated, find out the best execution plan possible? I really can't use CBO on our sites, because performance is so much worse...
Thanks in advance.
Carlos Inglez

Hi Carlos,
The solution I have for now is set OPTIMIZER_MODE=RULE. Then everything runs smoothly again.It's almost always an issue with CBO parms or CBO statistics.
There are several issues in 10g CBO, and here are my notes:
http://www.dba-oracle.com/t_slow_performance_after_upgrade.htm
Oracle has improved the cost-based Oracle optimizer in 9.0.5 and again in 10g, so you need to take a close look at your environmental parameter settings (init.ora parms) and your optimizer statistics.
- Check optimizer parameters - Ensure that you are using the proper optimizer_mode (default is all_rows) and check optimal settings for optimizer_index_cost_adj (lower from the default of 100) and optimizer_index_caching (set to a higher value than the default).
- Re-set optimizer costing - Consider unsetting your CPU-based optimizer costing (the 10g default, a change from 9i). CPU costing is best of you see CPU in your top-5 timed events in your STATSPACK/AWR report, and the 10g default of optimizercost_model=cpu will try to minimize CPU by invoking more full scans, especially in tablespaces with large blocksizes. To return to your 9i CBO I/O-based costing, set the hidden parameter "_optimizer_cost_model"=io
- Verify deprecated parameters - you need to set optimizer_features_enable = 10.2.0.2 and optimizer_mode = FIRST_ROWS_n (or ALL_ROWS for a warehouse, but remove the 9i CHOOSE default).
- Verify quality of CBO statistics - Oracle 10g does automatic statistics collection and your original customized dbms_stats job (with your customized parameters) will be overlaid. You may also see a statistics deficiency (i.e. not enough histograms) causing performance issues. Re-analyze object statistics using dbms_stats and make sure that you collect system statistics.
Hope this helps. . .
Donald K. Burleson
Oracle Press author

Similar Messages

RBO to CBO conversions

Hi,
I need some help.
My databases are running in RBO environment using oracle 8i, 9i. Now, because RBO being obsolete in oracle 10g and later releases. I want to switch to CBO.
My databases are in production. I want to look at all the scenarios for conversion to CBO (oracle 10g).
Could you please suggest, What will be the best approach for that, how should I start.
I want to know, what conversions are required for changing to CBO. How should i check the performance after conversion e.g. should i check the performance of all operations in both RBO and CBO environment or something else.
Almost all my queries are using hints, do I have to make some changes on queries also, if yes, then this might be the major task for me. Is there any other way out ?
If, any other information is required, please let me know.
Please help in determining the best strategy.
Regards
Ashish Goel

Well, if the RBO is truly desupported in 10G I would expect the RULE hints to just be ignored.
Keep in mind that you will need to generate stats to assist the CBO so that might be step one (getting a stats gathering job in place).
As per Strategy, do you know what your most frequent and imporatnt queries are? If so, benchmark them and comapre in 10G with CBO.

DISTINCT in the query -- RBO vs CBO

Hi all,
We are in a process of migrating our applications from RBO to CBO as we moved to 10g and recently I observed a simple query with DISTINCT clause showing different results in CBO. Here is my order of creating a table in 10g environment,
create table m_test(col1 varchar2(3));
insert into m_test values('ZYT');
insert into m_test values('ABC');
insert into m_test values('RKT');
select * from m_test
col1
ZYT
ABC
RKT
alter session set optimizer_mode = RULE
select distinct col1 from m_test;
col1
ABC
RKT
ZYT
Note: Explain plan shows that it's doing SORT UNIQUE
alter session set optimizer_mode = FIRST_ROWS_1
select distinct col1 from m_test;
col1
ZYT
ABC
RKT
Note: Explain plan shows that it's doing HASH UNIQUE
I would appreciate if someone can let me know why this is happening,
Thank you,
Madhu

It happened to be sorted when you were using the RBO because the query plan the RBO generated happened to involve a sort. The CBO knows that sorting isn't strictly necessary, so it may or may not choose to apply the sort.
The CBO has a lot of options for generating query plans, depending on table, column, index, and system statistics, histograms, etc. and has a lot more plan options than the old RBO did. The CBO is a lot more likely to change a query plan than the RBO was, which is normally a good thing (a plan that works for a 10 row table might need to be changed if the table grows to 1 million rows). Depending on the Oracle version, initialization parameters, table statistics, system statistics, etc. the CBO may happen to sort rows before returning them.
If you want Oracle to sort the rows, however, there is only one way to guarantee that-- add an ORDER BY clause.
Justin

RBO vs CBO : Are you going to maintain RBO in DBMS?

Hello, Oracle?
I'm facing many critics about the type of SQL optimization from customer.
I'm still using RBO in application SQL because, sometimes, your automatic optimization (analyze) make the execution plan of performance-oriented SQL worse and that kind of SQL have to be executed very long time.
So I checked these SQLs and appended the hint ("/*+ RULE */").
From that time, these SQLs were always executed in the same execution plan
and other performance issues were disappeared.
I want to ask you that
1) Did I do wrong things?
2) using RBO in the 10g or higher can make other Unexpected, Serious problem?
3) Do you really want to close supporting the RBO?
4) Is it wrong using RBO in the 10g or higher ?
Thanks in Advance, Oracle and Other Experts or People who have the experiece
about the RBO in Oracle 10g or higer.

2) using RBO in the 10g or higher can make other Unexpected, Serious problem?If you are really using 10g then you ought to learn how to use all its features properly. This means learning how Cost-Based Optimization works. You should do this as much as a favour to yourself and your career prospects as for any other reason.
If your database is small enough that the RBO provides sufficiently effective performance then you can get away with it. But in the long run CBO is definitely the way to go.
Cheers, APC
blog: http://radiofreetooting.blogspot.com/

9i to 10g Migration, RBO to CBO conversion

Hi All,
We used to have 9.2.0.4.0 DB and our applications are tuned to RBO using 'rule' hints.
Recently we migrated to 10gR2 (setting optimizer_hint = 'FIRST_ROWS_1') and we expected that the applications that are using 'rule' hint will be ignored or atleast code will throw errors. But when we looked at the trace file, it looks like it is using RBO.
When Oracle say that RBO is not supported in 10g, does that mean we can still use RBO at our own risk ? Are there any other parameters that need to be set so that CBO is used though RULE hints are used ? (I don't think so..but just to confirm)
Please let me know if someone has any pointers on this,
Thanks,
madhu.

The RBO is no longer supported by Oracle in 10g. The rule hint and optimizer mode are still present in 10g. You are free to use the Rule hint and optimizer mode in 10g, with no support from Oracle.

10g query running faster with RBO than CBO

I am running a query in Oracle 10g that is taking 1minute 15 seconds to run using the CBO. All the tables and indexes in the query are fully analyzed. However if i add a /*+ Rule */ hint to the query and force the optimizer to RBO it runs in 5 seconds.
Anyone any ideas why this would occur? it's contrary to everything Oracle says about CBO and problematic as RBO is no longer supported in 10g
Any help / advice greatfully appreciated
Thanks
Declan

My "best" CBO explain plan is......
Explain complete.
Elapsed: 00:00:01:90
PLAN_TABLE_OUTPUT
| Id | Operation                          | Name                          | Rows | Bytes |TempSpc| Cost |
|   0 | SELECT STATEMENT                   |                                | 3364K| 2553M|       |   666K|
|   1 | SORT ORDER BY                     |                                | 3364K| 2553M| 5840M|   666K|
|   2 |   VIEW                             |                                | 3364K| 2553M|       |   273K|
|   3 |    UNION-ALL                       |                                |       |       |       |       |
|* 4 |     HASH JOIN                      |                                | 2269K| 1415M|       |   255K|
|* 5 |      TABLE ACCESS FULL             | NODE                           |     6 |   198 |       |   183 |
|* 6 |      HASH JOIN OUTER               |                                | 2269K| 1344M|       |   255K|
|* 7 |       HASH JOIN                    |                                |   710 |   266K|       | 2179 |
|* 8 |        HASH JOIN OUTER             |                                | 1219 |   165K|       |   355 |
|* 9 |         HASH JOIN                  |                                | 1219 |   154K|       |   318 |
|* 10 |          HASH JOIN                 |                                | 1219 |   138K|       |   260 |
|* 11 |           HASH JOIN                |                                | 1219 |   127K|       |   224 |
| 12 |            TABLE ACCESS FULL       | TMP_NODE_WALK_ALL_NODES        | 8168 |   311K|       |    17 |
|* 13 |            HASH JOIN               |                                | 10896 |   723K|       |   201 |
| 14 |             INDEX FAST FULL SCAN   | PK_NODE_RULES_NODE_ID_RULE_ID | 10896 |   106K|       |     6 |
| 15 |             TABLE ACCESS FULL      | NODE                           | 73004 | 4134K|       |   183 |
| 16 |           INDEX FAST FULL SCAN     | IDX_NODE_CIX2                  | 73004 |   641K|       |    33 |
PLAN_TABLE_OUTPUT
| 17 |          INDEX FAST FULL SCAN      | IDX_NODE_CIX1                  | 73004 |   998K|       |    54 |
| 18 |         INDEX FAST FULL SCAN       | IDX_NODE_CIX2                  | 73004 |   641K|       |    33 |
|* 19 |        TABLE ACCESS FULL           | RULES                          | 6344 | 1517K|       | 1820 |
| 20 |       VIEW                         |                                |   405M|    89G|       | 43581 |
|* 21 |        HASH JOIN OUTER             |                                |   405M|    23G|       | 43581 |
| 22 |         TABLE ACCESS FULL          | TMP_NODE_WALK_ALL_NODES        | 8168 |   103K|       |    17 |
| 23 |         TABLE ACCESS FULL          | UNIVERSAL_RULES                | 3377K|   157M|       | 43256 |
|* 24 |     HASH JOIN OUTER                |                                | 1094K|   410M|   148M| 17453 |
| 25 |      MERGE JOIN CARTESIAN          |                                |   390K|   143M|       | 15029 |
| 26 |       NESTED LOOPS                 |                                |    70 | 25060 |       | 2849 |
| 27 |        NESTED LOOPS                |                                |    70 | 21000 |       | 2779 |
| 28 |         TABLE ACCESS BY INDEX ROWID| UNIVERSAL_RULES                | 1392 | 76560 |       | 1387 |
|* 29 |          INDEX RANGE SCAN          | IDX_UNIVERSAL_RULES_ACCOUNT    | 1392 |       |       |     6 |
|* 30 |         TABLE ACCESS BY INDEX ROWID| RULES                          |     1 |   245 |       |     1 |
|* 31 |          INDEX UNIQUE SCAN         | PK_RULES_RULE_ID_VERSION_ID    |    20 |       |       |       |
|* 32 |        TABLE ACCESS BY INDEX ROWID | NODE                           |     1 |    58 |       |     1 |
|* 33 |         INDEX UNIQUE SCAN          | PK_NODE_NODE_ID                |     6 |       |       |       |
| 34 |       BUFFER SORT                  |                                | 5616 |   153K|       | 15028 |
| 35 |        TABLE ACCESS BY INDEX ROWID | NODE                           | 5616 |   153K|       |   174 |
|* 36 |         INDEX RANGE SCAN           | IDX_NODE_NODE_TYPE_ID          | 5616 |       |       |    11 |
|* 37 |      INDEX FAST FULL SCAN          | IDX_RULES_RULE_ID_STATUS       | 42293 |   289K|       |    48 |
PLAN_TABLE_OUTPUT
Predicate Information (identified by operation id):
   4 - access("NODE"."NODE_TYPE_ID"="SN"."HIERARCHY_TYPE_ID")
   5 - filter("NODE"."PARENT_NODE_ID" IS NULL)
   6 - access("SYS_ALIAS_1"."RULE_ID"="UR"."RULE_ID"(+) AND "SYS_ALIAS_1"."VERSION_ID"="UR"."VERSION_ID"(+))
   7 - access("NR"."RULE_ID"="SYS_ALIAS_1"."COMBINED_RULE_ID")
   8 - access("SN"."PARENT_NODE_ID"="SP"."NODE_ID"(+))
   9 - access("AN"."START_NODE_ID"="SN"."NODE_ID")
10 - access("AN"."EFFECTIVE_NODE_ID"="EN"."NODE_ID")
11 - access("AN"."SHORTCUT_NODE_ID"="N"."NODE_ID")
13 - access("N"."NODE_ID"="NR"."NODE_ID")
19 - filter(',A,P,' LIKE '%,'||"SYS_ALIAS_1"."STATUS"||',%')
21 - access("UR"."NODE_ID"(+)="AN"."START_NODE_ID")
24 - access("R"."RULE_ID"="RP"."RULE_ID"(+))
29 - access("UR"."ACCOUNT_ID"='0069')
30 - filter(',A,P,' LIKE '%,'||"R"."STATUS"||',%')
31 - access("UR"."RULE_ID"="R"."RULE_ID" AND "UR"."VERSION_ID"="R"."VERSION_ID")
32 - filter("N"."HIERARCHY_TYPE_ID"=9)
PLAN_TABLE_OUTPUT
33 - access("UR"."NODE_ID"="N"."NODE_ID")
36 - access("NODE"."NODE_TYPE_ID"=9)
37 - filter("RP"."STATUS"(+)='P')
Note: cpu costing is off
28 rows selected.
Elapsed: 00:00:02:45
68 rows selected.
Elapsed: 00:00:05:76While my RBO explain plan is
Explain complete.
Elapsed: 00:00:01:23
PLAN_TABLE_OUTPUT
| Id | Operation                                | Name                        | Rows | Bytes | Cost |
|   0 | SELECT STATEMENT                         |                              |       |       |       |
|   1 | SORT ORDER BY                           |                              |       |       |       |
|   2 |   VIEW                                   |                              |       |       |       |
|   3 |    UNION-ALL                             |                              |       |       |       |
|   4 |     MERGE JOIN OUTER                     |                              |       |       |       |
|   5 |      SORT JOIN                           |                              |       |       |       |
|* 6 |       TABLE ACCESS BY INDEX ROWID        | NODE                         |       |       |       |
|   7 |        NESTED LOOPS                      |                              |       |       |       |
|   8 |         NESTED LOOPS                     |                              |       |       |       |
|   9 |          NESTED LOOPS                    |                              |       |       |       |
| 10 |           NESTED LOOPS                   |                              |       |       |       |
| 11 |            NESTED LOOPS                  |                              |       |       |       |
| 12 |             NESTED LOOPS OUTER           |                              |       |       |       |
| 13 |              NESTED LOOPS                |                              |       |       |       |
| 14 |               TABLE ACCESS FULL          | TMP_NODE_WALK_ALL_NODES      |       |       |       |
| 15 |               TABLE ACCESS BY INDEX ROWID| NODE                         |       |       |       |
|* 16 |                INDEX UNIQUE SCAN         | PK_NODE_NODE_ID              |       |       |       |
PLAN_TABLE_OUTPUT
| 17 |              TABLE ACCESS BY INDEX ROWID | NODE                         |       |       |       |
|* 18 |               INDEX UNIQUE SCAN          | PK_NODE_NODE_ID              |       |       |       |
| 19 |             TABLE ACCESS BY INDEX ROWID | NODE                         |       |       |       |
|* 20 |              INDEX UNIQUE SCAN           | PK_NODE_NODE_ID              |       |       |       |
| 21 |            TABLE ACCESS BY INDEX ROWID   | NODE                         |       |       |       |
|* 22 |             INDEX UNIQUE SCAN            | PK_NODE_NODE_ID              |       |       |       |
| 23 |           TABLE ACCESS BY INDEX ROWID    | NODE_RULES                   |       |       |       |
|* 24 |            INDEX RANGE SCAN              | IDX_NODE_RULES_NODE_ID       |       |       |       |
|* 25 |          TABLE ACCESS BY INDEX ROWID     | RULES                        |       |       |       |
|* 26 |           INDEX RANGE SCAN               | IDX_RULES_COMBINED_RULE_ID   |       |       |       |
|* 27 |         INDEX RANGE SCAN                 | IDX_NODE_NODE_TYPE_ID        |       |       |       |
|* 28 |      SORT JOIN                           |                              |       |       |       |
| 29 |       VIEW                               |                              |       |       |       |
| 30 |        NESTED LOOPS OUTER                |                              |       |       |       |
| 31 |         TABLE ACCESS FULL                | TMP_NODE_WALK_ALL_NODES      |       |       |       |
| 32 |         TABLE ACCESS BY INDEX ROWID      | UNIVERSAL_RULES              |       |       |       |
|* 33 |          INDEX RANGE SCAN                | IDX_UNIVERSAL_RULES_NODE     |       |       |       |
| 34 |     NESTED LOOPS OUTER                   |                              |       |       |       |
| 35 |      NESTED LOOPS                        |                              |       |       |       |
| 36 |       NESTED LOOPS                       |                              |       |       |       |
| 37 |        NESTED LOOPS                      |                              |       |       |       |
PLAN_TABLE_OUTPUT
| 38 |         TABLE ACCESS BY INDEX ROWID      | NODE                         |       |       |       |
|* 39 |          INDEX RANGE SCAN                | IDX_NODE_NODE_TYPE_ID        |       |       |       |
| 40 |         TABLE ACCESS BY INDEX ROWID      | UNIVERSAL_RULES              |       |       |       |
|* 41 |          INDEX RANGE SCAN                | IDX_UNIVERSAL_RULES_ACCOUNT |       |       |       |
|* 42 |        TABLE ACCESS BY INDEX ROWID       | NODE                         |       |       |       |
|* 43 |         INDEX UNIQUE SCAN                | PK_NODE_NODE_ID              |       |       |       |
|* 44 |       TABLE ACCESS BY INDEX ROWID        | RULES                        |       |       |       |
|* 45 |        INDEX UNIQUE SCAN                 | PK_RULES_RULE_ID_VERSION_ID |       |       |       |
|* 46 |      INDEX RANGE SCAN                    | IDX_RULES_RULE_ID_STATUS     |       |       |       |
Predicate Information (identified by operation id):
   6 - filter("NODE"."PARENT_NODE_ID" IS NULL)
16 - access("AN"."START_NODE_ID"="SN"."NODE_ID")
18 - access("SN"."PARENT_NODE_ID"="SP"."NODE_ID"(+))
20 - access("AN"."EFFECTIVE_NODE_ID"="EN"."NODE_ID")
22 - access("AN"."SHORTCUT_NODE_ID"="N"."NODE_ID")
24 - access("N"."NODE_ID"="NR"."NODE_ID")
25 - filter(',A,P,' LIKE '%,'||"SYS_ALIAS_1"."STATUS"||',%')
PLAN_TABLE_OUTPUT
26 - access("NR"."RULE_ID"="SYS_ALIAS_1"."COMBINED_RULE_ID")
27 - access("NODE"."NODE_TYPE_ID"="SN"."HIERARCHY_TYPE_ID")
28 - access("SYS_ALIAS_1"."RULE_ID"="UR"."RULE_ID"(+))
       filter("SYS_ALIAS_1"."VERSION_ID"="UR"."VERSION_ID"(+) AND
              "SYS_ALIAS_1"."RULE_ID"="UR"."RULE_ID"(+))
33 - access("UR"."NODE_ID"(+)="AN"."START_NODE_ID")
39 - access("NODE"."NODE_TYPE_ID"=9)
41 - access("UR"."ACCOUNT_ID"='0069')
42 - filter("N"."HIERARCHY_TYPE_ID"=9)
43 - access("UR"."NODE_ID"="N"."NODE_ID")
44 - filter(',A,P,' LIKE '%,'||"R"."STATUS"||',%')
45 - access("UR"."RULE_ID"="R"."RULE_ID" AND "UR"."VERSION_ID"="R"."VERSION_ID")
46 - access("R"."RULE_ID"="RP"."RULE_ID"(+) AND "RP"."STATUS"(+)='P')
Note: rule based optimization
28 rows selected.
Elapsed: 00:00:04:42
78 rows selected.
Elapsed: 00:00:08:86Any additional help appreciated
I am going to try and run a trace against the sql now and see if i can get any more information
Thanks in advance
Declan

Difference between RBO and CBO

Hi All,
Can you just tell me what is the difference between Rule-Based optimization and
Cost-Based optimization?
Thanks and Regards,
Padma

hi,
A long time ago, the only optimizer in the Oracle database was the Rule-Based Optimizer (RBO). Basically, the RBO used a set of rules to determine how to execute a query. If an index was available on a table, the RBO rules said to always use the index. There are some cases where the use of an index slowed down a query. For example, assume someone put an index on the GENDER column, which holds one of two values, MALE and FEMALE. Then someone issues the following query:
SELECT * FROM emp WHERE gender='FEMALE'; I
f the above query returned approximately 50% of the rows, then using an index would actually slow things down. It would be faster to read the entire table and throw away all rows that have MALE values. Experts in Oracle query optimization have come to a rule of thumb that says if the number of rows returned is more than 5-10% of the total table volume, using an index would slow things down. The RBO would always use an index if present because its rules said to.
It became obvious that the RBO, armed with its set of discrete rules, did not always make great decisions. The biggest problem with the RBO was that it did not take the data distribution into account. So the Cost-Based Optimizer (CBO) was born. The CBO uses statistics about the table, its indexes and the data distribution to make better informed decisions. Using our previous example, assume that the company has employees that are 95% female and 5% male. If you query for females, then you do not want to use the index. If you query for males, then you would like to use the index. The CBO has information at hand to help make these kind of determinations that were not available in the old RBO.
Thanks

RBO vs CBO

hi,
Can anyone explain when to use Rule Based Optimizer and cost Based Optimizer
and also the difference for these two

Can anyone explain when to use Rule Based Optimizer and cost Based OptimizerRule Based Optimizer is obsoleted & should be ignored.
Handle:      Adithya
Status Level:      Newbie (10)
Registered:      Mar 26, 2008
Total Posts:      52
Total Questions:      29 (29 unresolved)
so many questions without ANY answers.
Edited by: sb92075 on Apr 7, 2011 9:57 PM

Question on RBO & CBO

hi,
Plz clear some doubts.In 1 interview below questions were asked to me..
1) how oracle will decide RBO or CBO have to used for query optimization? is there any parameter we need to set in init.ora file or any other parameter will decide to pick RBO/CBO by oracle?
2) if tab1,tab2,tab3,tab4,tab5 are using in sql stmnt and only on tab1,tab2 statistics is collected then what will b senerio in terms of RBO/CBO?
I m using tab1.col1,tab2.col1,tab3.col1,tab14col1,tab5.col1 in my join condition.
Might be my question will not b clear but like in some way it was asked to me.
3) some query is running fine but since some days they are taking too much time to execute.what might be reason?
note: nothing changed in sqlcode, nothing is running on backend on database,no rows were deleted from tables,no lock on tables by anyone,..then what might be the reason and
how we can figure out those reason?
I tried to search on net also these answers but didn't get cool answer.then remind that expert community forum oracle..plz help..
rgds,
Pc

sb92075 wrote:
PC wrote:
hi,
Plz clear some doubts.In 1 interview below questions were asked to me..I would not work for any company where RBO was still be used.
V9 Oracle was last version to include RBO & V9 has been obsoleted this whole Century.So, I should resign from my employer of 17 years because we still have a couple of applications that use RBO, I can just hear the exit interview now :-)
In case you are wondering, one of the applications that uses RBO is on 10.2.0.3, and the other is 9.2.0.8
John

CBO Performing Bad as compared to RBO any suggestions

Hi
I am migrating from RBO to CBO. I have taken the Stats on the schema tables and indexes. The response times in CBO are really Bad as compared to RBO. Can any one suggest where should I Start to make the performance better.
Thanks

In order to get a list of name and values of optimizer parameters that your session is using you can use 10053 event. here is an example;
HR on 25/03/2006 19:55:33 at XE > alter session set events ‘10053 trace name on
text forever, level 1′;
Session altered.
HR on 25/03/2006 19:55:51 at XE > SELECT TO_CHAR(sysdate,’DD-MON-YY HH24:MI:SS’)
”Start” FROM dual;
Start
25-MAR-06 19:55:59
1 row selected.
HR on 25/03/2006 19:55:59 at XE > ALTER SESSION SET EVENTS ‘10053 TRACE NAME CONTEXT OFF’;
The file at User_Dump_Dest folder in your Os with .trc extention will be created.
Hope this helps, kind regards.
Tonguç

What will be my optimizer after importing 9iR2 to 10gR2 CBO or RBO?

Friends,
OS: RHEL AS 3
what will be my optimizer after importing 9iR2 to 10gR2?
will it be in RBO or CBO?
What are the precautionary steps should i follow for the optimizer part?
thanks

The default optimizer , as mentioned already will be CBO based. Oracle would go for All_rows as the one.
RBO is still there ,even in 11g its there but oracle won't be accepting any bug reports or wont supply anything for issues about it. So if your stats are okay than it wil be cbo otherwise it will be RBO that would be kicking in,
Connected to:
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
With the Partitioning, Oracle Label Security, OLAP, Data Mining,
Oracle Database Vault and Real Application Testing options
SQL> set auot trace exp
SP2-0158: unknown SET option "auot"
SQL> set autot trace exp
SQL> alter session set optimizer_mode=choose;
Session altered.
SQL> create table t( a char);
Table created.
SQL> select * from t;
Execution Plan
Plan hash value: 1601196873
| Id | Operation         | Name |
|   0 | SELECT STATEMENT |      |
|   1 | TABLE ACCESS FULL| T    |
Note
   - rule based optimizer used (consider using cbo)
SQL> create table iot(a number primary key) organization index;
Table created.
SQL> select * from iot;
Execution Plan
Plan hash value: 3063468998
| Id | Operation            | Name              | Rows | Bytes | Cost (%CPU)|
Time     |
|   0 | SELECT STATEMENT     |                   |     1 |    13 |     2   (0)|
00:00:01 |
|   1 | INDEX FAST FULL SCAN| SYS_IOT_TOP_71833 |     1 |    13 |     2   (0)|
00:00:01 |
Note
   - dynamic sampling used for this statement
SQL> select * from t,iot;
Execution Plan
Plan hash value: 3684863450
| Id | Operation              | Name              | Rows | Bytes | Cost (%CPU)
| Time     |
|   0 | SELECT STATEMENT       |                   |     1 |    16 |     4   (0)
| 00:00:01 |
|   1 | MERGE JOIN CARTESIAN |                   |     1 |    16 |     4   (0)
| 00:00:01 |
|   2 |   TABLE ACCESS FULL    | T                 |     1 |     3 |     2   (0)
| 00:00:01 |
|   3 |   BUFFER SORT          |                   |     1 |    13 |     2   (0)
| 00:00:01 |
|   4 |    INDEX FAST FULL SCAN| SYS_IOT_TOP_71833 |     1 |    13 |     2   (0)
| 00:00:01 |
Note
   - dynamic sampling used for this statement
SQL>You can see that with a simple table,T , without stats, RBO is coming but with IOT,which is a somewhat new object to RBO, CBO is kicking in.When both combined together, CBO is coming up.
If you would analyze the table, T CBO would come in.
You should check after upgrade those queries with a keen eye who are using RBO hint and are doing some index scans in RBO. They might change the behaviour after theupgrade.
HTH
Aman....

How to tune the query and difference between CBO AND RBO.. Which is good

Hello Friends,
Here are some questions I have pls reply back with complete description and url if any ..
1)How Did you tune Query,
2)What approach you take to tune query? Do you use Hints?
3)Where did you tune the query and what are the issue with query?
4)What is difference between RBO and CBO? where u use RBO and CBO.
5)Give some information about hash join?
6) Using explain plan how do u know where the bottle neck in query .. how u will identify where the bottle neck is from explain plan .
thanks/Kumar

Hi,
kumar73 wrote:
Hello Friends,
Here are some questions I have pls reply back with complete description and url if any ..
1)How Did you tune Query, Use EXPLAIN PLAN to see exactly where it is spending its time, and address those areas.
See the forum FAQ
SQL and PL/SQL FAQ
"3. How to improve the performance of my query?"
2)What approach you take to tune query? Do you use Hints?Hints can help.
Even more helpful is writing the SQL efficiently (avoiding multiple scans of the same table, filtering early, using built-in rather than user-defined functions, ...), creating and using indexes, and, for large tables, partitioning.
Table design can have a big impact on performace.
Look for ways to do part of what you need before the query. This includes denormalizing (when appropriate), the kind of pre-digesting that often takes place in data warehouses, function-based indexes, and, starting in Oracle 11, virtual columns.
3)Where did you tune the query and what are the issue with query?Either this question is a vague summary of the entire thread, or I don't understand it. Can you re-phrase this part?
4)What is difference between RBO and CBO? where u use RBO and CBO.Basically, use RBO if you have Oracle 7 or earlier.

Index Usage in 9i changed when used rownum

Hi List,My Application is in RBO
Here is one more brain twister ?
Assume following I Have table SHRI with a single column
COL I have created Index on COL column say IND_COL.
Now when I run Following query on 8i with AUTOTRACE ON
I can see that 8i Uses the Index IND_COL Clearly .
select * from shri where (h_name='ABC' or h_name='BOM')
or (h_name ='BOM' or h_name='MOM')
and rownum=1
select * from shri where (COL='ABC' or COL='BOM')
or (COL='ABC' or COL='BOM')
and rownum=1
(Note:Above example is just for ur understanding plz.dont see the usage)
Now my problem is when I see the explain plan for above query in 8i I can see that Query uses IND_COL .
But when I run the same in 9i It does not uses IND_COL Index (Strange!!!) .
However when I remove "and rownum=1" clause then It again uses the index in 9i.
Assume that such queries are existing many places .
I am badly stuck because of this problem can anybody suggest the best way (Other than changing RBO to CBO) ?
Regards
Sripad.

Run below query, you will get all the details of tablespaces.
col "Tablespace" for a22
col "Used MB" for 99,999,999
col "Free MB" for 99,999,999
col "Total MB" for 99,999,999
select df.tablespace_name "Tablespace",
totalusedspace "Used MB",
(df.totalspace - tu.totalusedspace) "Free MB",
df.totalspace "Total MB",
round(100 * ( (df.totalspace - tu.totalusedspace)/ df.totalspace))
"Pct. Free"
from
(select tablespace_name,
round(sum(bytes) / 1048576) TotalSpace
from dba_data_files
group by tablespace_name) df,
(select round(sum(bytes)/(1024*1024)) totalusedspace, tablespace_name
from dba_segments
group by tablespace_name) tu
where df.tablespace_name = tu.tablespace_name ;

URGENT: Migrating from SQL to Oracle results in very poor performance!

*** IMPORTANT, NEED YOUR HELP ***
Dear, I have a banking business solution from Windows/SQL Server 2000 to Sun Solaris/ORACLE 10g migrated. In the test environment everything was working fine. On the production system we have very poor DB performance. About 100 times slower than SQL Server 2000!
Environment at Customer Server Side:
Hardware: SUN Fire 4 CPU's, OS: Solaris 5.8, DB Oracle 8 and 10
Data Storage: Em2
DB access thru OCCI [Environment:OBJECT, Connection Pool, Create Connection]
Depending from older applications it's necessary to run ORACLE 8 as well on the same Server. Since we have running the new solution, which is using ORACLE 10, the listener for ORACLE 8 is frequently gone (or by someone killed?). The performance of the whole ORACLE 10 Environment is very poor. As a result of my analyse I figured out that the process to create a connection to the connection pool takes up to 14 seconds. Now I am wondering if it a problem to run different ORACLE versions on the same Server? The Customer has installed/created the new ORACLE 10 DB with the same user account (oracle) as the older version. To run the new solution we have to change the ORACLE environment settings manually. All hints/suggestions to solve this problem are welcome. Thanks in advance.
Anton

On the production system we have very poor DB performanceHave you identified the cause of the poor performance is not the queries and their plans being generated by the database?
Do you know if some of the queries appear to take more time than what it used to be on old system? Did you analyze such queries to see what might be the problem?
Are you running RBO or CBO?
if stats are generated, how are they generated and how often?
Did you see what autotrace and tkprof has to tell you about problem queries (if in fact such queries have been identified)?
http://download-west.oracle.com/docs/cd/B14117_01/server.101/b10752/sqltrace.htm#1052

SQL Query Optimization

I have a query related to how the CBO and RBO actually works.
I understand that Oracle uses CBO in 10g and was using both RBO and CBO from version 7 to 9i.
Lets say I have a query
Select * from X where A = &A and B = &B and C = &C
Index is created on A and B.
Please correct me if I am wrong, internally oracle maintains a hash for the fields A and B.
When the above query is executed, oracle needs to search in the hash.
If I change the query like
Select * from X where B = &B and A = &A and C = &C, will it (order of cols in where clause) make any diff. to the oracle when it searches in the hash with respect to performance.
On similar lines lets say i have a query (no index this time)
select * from X where A = &A and B = &B
Lets assume that the first condition A=&A will greatly reduce the list and the second condition B=&B will almost always be a subset of the result of first condition (if executed separately).
As a develop I know about the above condition, so will it help if the query is written like this or even if I write something like select * from X where B = &B and A = &A, it will give the same performance.
Please advise.

Oracle does not maintain a hash internally, it uses B-Tree indexes. Essentially, the actual value of each indexed column plus the rowid (a pointer to the physical location of the row) is kept for each index entry. As long as you have the leading columns of the index in the where clause in any order, Oracle will be able to use an index on those columns. Under the RBO, it would certainly use the index. Under the CBO, Oracele may or may not use the index. The choice would depend on a number of factors such as the statistics on the table and index, and various initialization parameters.
In your second example with no indexes, Oracle would do a full table scan examining every record. There is no documented order to the evaluation of predicates (at least none that I have ever seen), and I doubt very much whether it would have much of an effect on the performance of a full table scan if the predicates were evaluated in optimal order versus worst possible order.
TTFN
John

RBO X CBO

Similar Messages

Maybe you are looking for