Rule Based Optimization

Hi,
Rule Based Optimization is a deprecated feature in Oracle 10g.We are in the process of migrating from Oracle 9i to 10g.I have never heard of this Rule based Optimization earlier.I have googled for the same.But, got confused with the results.
Can anybody shed some light on the below things...
Is this Optimization done by Oracle or as a developer do we need to take care of the rules while writing SQL statements?
There is another thing called Cost Based Optimization...
Who will instruct the Oracle whether to use Rule Based Optimization or cost Based Optimization?
Thanks & Regards,
user569598

Hope the following explanation would be helpful.
Whenever a statement is fired, Oracle should goes through the following stages:
Parse -> Execute -> Fetch (fetch only for select statement).
During Parse, Oracle first evaluates, Syntatic checking (SELECT, FROM, WHERE, ORDER BY ,GROUP and etc) and then Semantic Checking (columns names, table name, user permission on the objects and etc). Once these two stages passes, then, it has to decided whether to do soft parse or hard parse. If similar cursor(statement) doesn't exits in the shared pool, Oracle goes for Hard parse where Optimizer comes in picture for generating query plan.
Oracle has to decide either RBO or CBO. It also depends on the OPTIMIZER_MODE parameter value. If RULE hint is used, RBO will be used, if there are no statistics for those tables involved in the query, Oracle decides RBO, (condition applies). If statistics are available, or dynamic samplying is defined then Oracle use CBO to prepare the Optimal execution plan.
RBO is simply relies on set of rules where CBO relies on statistical information.
Jaffar

Similar Messages

Improving performace for a Rule Based Optimizer DB

Hi,
I am looking for information on improving the current performance of an ancient 35GB Oracle 7.3.4 using RULE based optimizer mode. It is using 160 MB SGA and the physical memory on the system is 512MB RAM.
As of now, all the major tasks which take time, are run after peak hours so that the 130 user sessions are not affected significantly.
But recently am told some procedures take too long to execute ( procedure has to do with truncating tables and re-populating data into it ) and I do see 54% of the pie chart for WAITS are for "sequential reads" followed by "scattered reads" of 36%. There are a couple of large tables of around 4GB in this DB.
Autotrace doesn't help me much in terms of getting an explain plan of slow queries since COST option doesnt show up and am trying to find ways of improving the performance of DB in general.
Apart from the "redo log space requests" which I run into frequently (which btw is something I am trying to resolve ..thanks to some of you) I dont see much info on exactly how to proceed.
Is there any info that I can look towards in terms of improving performance on this rule based optimizer DB ? Or is identifying the top sql's in terms of buffer gets the only way to tune ?
Thank you for any suggestions provided.

Thanks Hemant.
This is for a 15 minute internal under moderate load early this morning.
Statistic                   Total        Per Transact Per Logon    Per Second
CR blocks created                    275          .95         5.19          .29
Current blocks converted fo           10          .03          .19          .01
DBWR buffers scanned               74600       258.13      1407.55        78.44
DBWR free buffers found            74251       256.92      1400.96        78.08
DBWR lru scans                       607          2.1        11.45          .64
DBWR make free requests              607          2.1        11.45          .64
DBWR summed scan depth             74600       258.13      1407.55        78.44
DBWR timeouts                        273          .94         5.15          .29
OS Integral shared text siz   1362952204   4716097.59 25716079.32   1433177.92
OS Integral unshared data s    308759380   1068371.56   5825648.68    324668.12
OS Involuntary context swit       310493      1074.37      5858.36       326.49
OS Maximum resident set siz       339968      1176.36      6414.49       357.48
OS Page faults                      3434        11.88        64.79         3.61
OS Page reclaims                    6272         21.7       118.34          6.6
OS System time used                19157        66.29       361.45        20.14
OS User time used                 195036       674.87      3679.92       205.09
OS Voluntary context switch        21586        74.69       407.28         22.7
SQL*Net roundtrips to/from         16250        56.23        306.6        17.09
SQL*Net roundtrips to/from           424         1.47            8          .45
background timeouts                  646         2.24        12.19          .68
bytes received via SQL*Net        814224      2817.38     15362.72       856.18
bytes received via SQL*Net         24470        84.67        461.7        25.73
bytes sent via SQL*Net to c       832836      2881.79     15713.89       875.75
bytes sent via SQL*Net to d        42713        147.8       805.91        44.91
calls to get snapshot scn:         17103        59.18        322.7        17.98
calls to kcmgas                      381         1.32         7.19           .4
calls to kcmgcs                      228          .79          4.3          .24
calls to kcmgrs                    20845        72.13        393.3        21.92
cleanouts and rollbacks - c           86           .3         1.62          .09
cleanouts only - consistent           40          .14          .75          .04
cluster key scan block gets         1051         3.64        19.83         1.11
cluster key scans                    376          1.3         7.09           .4
commit cleanout failures: c           18          .06          .34          .02
commit cleanout number succ         2406         8.33         45.4         2.53
consistent changes                   588         2.03        11.09          .62
consistent gets                   929408      3215.94        17536        977.3
cursor authentications              1746         6.04        32.94         1.84
data blocks consistent read          588         2.03        11.09          .62
db block changes                   20613        71.33       388.92        21.68
db block gets                      40646       140.64       766.91        42.74
deferred (CURRENT) block cl          668         2.31         12.6           .7
dirty buffers inspected                3          .01          .06            0
enqueue conversions                  424         1.47            8          .45
enqueue releases                    1981         6.85        37.38         2.08
enqueue requests                    1977         6.84         37.3         2.08
execute count                      20691         71.6        390.4        21.76
free buffer inspected               2264         7.83        42.72         2.38
free buffer requested             490899      1698.61      9262.25       516.19
immediate (CR) block cleano          126          .44         2.38          .13
immediate (CURRENT) block c          658         2.28        12.42          .69
logons cumulative                     53          .18            1          .06
logons current                         1            0          .02            0
messages received                    963         3.33        18.17         1.01
messages sent                        963         3.33        18.17         1.01
no work - consistent read g       905734      3134.03     17089.32        952.4
opened cursors cumulative           2701         9.35        50.96         2.84
opened cursors current               147          .51         2.77          .15
parse count                         2733         9.46        51.57         2.87
physical reads                    490258      1696.39      9250.15       515.52
physical writes                     2265         7.84        42.74         2.38
recursive calls                    37296       129.05        703.7        39.22
redo blocks written                 5222        18.07        98.53         5.49
redo entries                       10575        36.59       199.53        11.12
redo size                        2498156      8644.14     47135.02      2626.87
redo small copies                  10575        36.59       199.53        11.12
redo synch writes                    238          .82         4.49          .25
redo wastage                      104974       363.23      1980.64       110.38
redo writes                          422         1.46         7.96          .44
rollback changes - undo rec            1            0          .02            0
rollbacks only - consistent          200          .69         3.77          .21
session logical reads             969453      3354.51     18291.57       1019.4
session pga memory              35597936    123176.25    671659.17     37432.11
session pga memory max          35579576    123112.72    671312.75      37412.8
session uga memory               2729196      9443.58     51494.26      2869.82
session uga memory max          20580712     71213.54    388315.32     21641.13
sorts (memory)                      1091         3.78        20.58         1.15
sorts (rows)                       12249        42.38       231.11        12.88
table fetch by rowid               57246       198.08      1080.11         60.2
table fetch continued row            111          .38         2.09          .12
table scan blocks gotten          763421       2641.6     14404.17       802.76
table scan rows gotten          13740187      47543.9    259248.81     14448.15
table scans (long tables)            902         3.12        17.02          .95
table scans (short tables)          4614        15.97        87.06         4.85
total number commit cleanou         2489         8.61        46.96         2.62
transaction rollbacks                  1            0          .02            0
user calls                         15266        52.82       288.04        16.05
user commits                         289            1         5.45           .3
user rollbacks                        23          .08          .43          .02
write requests                       331         1.15         6.25          .35Wait Events :
Event Name                       Count         Total Time    Avg Time
SQL*Net break/reset to client                7             0             0
SQL*Net message from client              16383             0             0
SQL*Net message from dblink                424             0             0
SQL*Net message to client                16380             0             0
SQL*Net message to dblink                  424             0             0
SQL*Net more data from client                1             0             0
SQL*Net more data to client                 24             0             0
buffer busy waits                          169             0             0
control file sequential read                55             0             0
db file scattered read                   74788             0             0
db file sequential read                 176241             0             0
latch free                                6134             0             0
log file sync                              225             0             0
rdbms ipc message                           10             0             0
write complete waits                         4             0             0I did enable the timed_stats for the session but dont know why the times are 0's. Since I cant bounce the instance until weekend, cant enable the parameter in init.ora as well.

RULE BASED OPTIMIZER

hi,
my database is 10.2.0.1...by default optimizer_mode=ALL_ROWS..
for some sessions..i need rule based optimizer...
so can i use
alter session set optimizer_mode=rule;
will it effect that session only or entire database....
and following also.i want to make them at session level...
ALTER SESSION SET "_HASH_JOIN_ENABLED" = FALSE;
ALTER SESSION SET "_OPTIMIZER_SORTMERGE_JOIN_ENABLED" = FALSE ;
ALTER SESSION SET "_OPTIMIZER_JOIN_SEL_SANITY_CHECK" = TRUE;
will those effect only session or entire database...please suggest

< CBO outperforms RBO ALWAYS! > I disagree - mildlyWhen I tune SQL, the first thing I try is a RULE hint, and in very simple databases, the RBO still does a good job.
Of course, you should not use RULE hints in production (That's Oracle job).
When Oracle eBusiness suite migrated to the CBO, they placed gobs of RULE hints into their own SQL!!
Anyway, always adjust your CBO stats to replicate an RBO execution plan . . . .
specifically CAST() conversions from collections and pipelined functions.Interesting. Hsve you tried dynamic sampling for that?
Hope this helps. . .
Don Burleson
Oracle Press author
Author of “Oracle Tuning: The Definitive Reference”
http://www.dba-oracle.com/bp/s_oracle_tuning_book.htm

RULE BASED OPTIMIZER TUNING

Hi all,
On one of the production server we are using RULE BASED OPTIMIZER(Its application requirement).
I have to tune this database as users are complaining about the performance.
Any tips how can I tune for a RULE BASED optimizer database.
Does the tuning statergy will remain same as like seeing execution plan for missing index,instance paramets
execpt you cant generate stats.
Regards
Umair

Hi!
There are one thing about RBO, YOU must check all long-running queryis for it's
execution plans, try find better plans and after force RBO to using it.
You can use different hints for changing eceution plans. But for tuning RBO's database you must soent a very big time, YOU must be a CBO ;)

Rule-Based Optimizer doesn4t use the index

Does anybody know why the rule-based optimizer doesn4t use the index of all columns in the where clause?
I have a select that use the hint RULE to force the optimizer to work in rule mode and also one index to all columns used in the where clause. Analyzing the execution plan (EXPLAIN PLAN) I observed the optimizer accesses all tables, but one, using the index. There4s one table (the first of the execution plan) that is accessed using a Full Table Scan (FTS).
I've rebuilt the index for this table, but the execution plan doesn4t change.
Any suggestions?
Thanks in advance.
Eliane.

Hi. Oracle may not use an index if it finds that a full table scan is quicker/more efficient. Try the hint /*+ INDEX (table index) */ and compare the query performance with that of the one without this hint. (As you know, if you force Rule-based approach, the COST column in EXPLAIN PLAN output will not be populated. You may have to use trace/tkprof.)

Rule based optimizer vs Cost based optimizer - 9i

Is Rule based optimizer not used any more or can be used depending on the application etc.
I think Rule based optimizer still has some advantages. Please give your input if you think otherwise.
Thx

I think Rule based optimizer still has some
advantages. Please give your input if you think
otherwise.You are absolutely correct. There are a few advantages to RBO.
RBO is better for any application that meets the following criteria:
- designed for Oracle version 7;
- has not been updated since Oracle 7;
- was hand tuned in Oracle 7;
- will not be upgraded to Oracle Database 10g (where RBO is obsolete);
- will not use Bitmap Indexes, Materialized Views, Query Rewrite, or vitrtually anything that was introduced in Oracle8 and beyond.
CBO, while not perfect, will allow new features to be used. And it is improving with every release.

How to avoid full Table scan when using Rule based optimizer (Oracle817)

1. We have a Oracle 8.1.7 DB, and the optimizer_mode is set to "RULE"
2. There are three indexes on table cm_contract_supply, which is a large table having 28732830 Rows, and average row length 149 Bytes
COLUMN_NAME INDEX_NAME
PROGRESS_RECID XAK11CM_CONTRACT_SUPPLY
COMPANY_CODE XIE1CM_CONTRACT_SUPPLY
CONTRACT_NUMBER XIE1CM_CONTRACT_SUPPLY
COUNTRY_CODE XIE1CM_CONTRACT_SUPPLY
SUPPLY_TYPE_CODE XIE1CM_CONTRACT_SUPPLY
VERSION_NUMBER XIE1CM_CONTRACT_SUPPLY
CAMPAIGN_CODE XIF1290CM_CONTRACT_SUPPLY
COMPANY_CODE XIF1290CM_CONTRACT_SUPPLY
COUNTRY_CODE XIF1290CM_CONTRACT_SUPPLY
SUPPLIER_BP_ID XIF801CONTRACT_SUPPLY
COMMISSION_LETTER_CODE XIF803CONTRACT_SUPPLY
COMPANY_CODE XIF803CONTRACT_SUPPLY
COUNTRY_CODE XIF803CONTRACT_SUPPLY
COMPANY_CODE XPKCM_CONTRACT_SUPPLY
CONTRACT_NUMBER XPKCM_CONTRACT_SUPPLY
COUNTRY_CODE XPKCM_CONTRACT_SUPPLY
SUPPLY_SEQUENCE_NUMBER XPKCM_CONTRACT_SUPPLY
VERSION_NUMBER XPKCM_CONTRACT_SUPPLY
3. We are querying the table for a particular contract_number and version_number. We want to avoid full table scan.
SELECT /*+ INDEX(XAK11CM_CONTRACT_SUPPLY) */
rowid, pms.cm_contract_supply.*
FROM pms.cm_contract_supply
WHERE
contract_number = '0000000000131710'
AND version_number = 3;
However despite of giving hint, query results are fetched after full table scan.
Execution Plan
0 SELECT STATEMENT Optimizer=RULE (Cost=1182 Card=1 Bytes=742)
1 0 TABLE ACCESS (FULL) OF 'CM_CONTRACT_SUPPLY' (Cost=1182 Card=1 Bytes=742)
4. I have tried giving
SELECT /*+ FIRST_ROWS + INDEX(XAK11CM_CONTRACT_SUPPLY) */
rowid, pms.cm_contract_supply.*
FROM pms.cm_contract_supply
WHERE
contract_number = '0000000000131710'
AND version_number = 3;
and
SELECT /*+ CHOOSE + INDEX(XAK11CM_CONTRACT_SUPPLY) */
rowid, pms.cm_contract_supply.*
FROM pms.cm_contract_supply
WHERE
contract_number = '0000000000131710'
AND version_number = 3;
But it does not work.
Is there some way without changing optimizer mode and without creating an additional index, we can use the index instead of full table scan?

David,
Here is my test on a Oracle 10g database.
SQL> create table mytable as select * from all_tables;
Table created.
SQL> set autot traceonly
SQL> alter session set optimizer_mode = choose;
Session altered.
SQL> select count(*) from mytable;
Execution Plan
   0      SELECT STATEMENT Optimizer=CHOOSE
   1    0   SORT (AGGREGATE)
   2    1     TABLE ACCESS (FULL) OF 'MYTABLE' (TABLE)
Statistics
          1 recursive calls
          0 db block gets
         29 consistent gets
          0 physical reads
          0 redo size
        223 bytes sent via SQL*Net to client
        276 bytes received via SQL*Net from client
          2 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
          1 rows processed
SQL> analyze table mytable compute statistics;
Table analyzed.
SQL> select count(*) from mytable
2 ;
Execution Plan
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=11 Card=1)
   1    0   SORT (AGGREGATE)
   2    1     TABLE ACCESS (FULL) OF 'MYTABLE' (TABLE) (Cost=11 Card=1
          788)
Statistics
          1 recursive calls
          0 db block gets
         29 consistent gets
          0 physical reads
          0 redo size
        222 bytes sent via SQL*Net to client
        276 bytes received via SQL*Net from client
          2 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
          1 rows processed
SQL> disconnect
Disconnected from Oracle Database 10g Enterprise Edition Release 10.1.0.2.0 - 64bit Production
With the Partitioning, Oracle Label Security, OLAP and Data Mining options

RULE BASED OPTIMIZER의 PLAN 선택 등급

제품 : ORACLE SERVER
작성날짜 : 1997-01-21
Index 사용의 우선 순위
======================
테이블에 인덱스가 생성되어 있다 하더라도 SQL의 코딩 방법에 따라 한개 이상의
인덱스가 사용되기도 하고 전혀 사용되지 않을 수가 있다.
그러므로, 항상 적절한 인덱스를 사용하여 좋은 액세스 경로를 확보하여야 한다.
또한 처리해야 할 문장의 WHERE 조건에 사용한 컬럼이 모두 인덱스 컬럼인 경우
이들에게도 우선 순위가 있다. 즉 모든 인덱스가 사용되어지는 것이 아니고 우선
순위가 높은 인덱스가 먼저 사용되어져서 처리된다.
인덱스의 우선 순위를 높은 순서부터 살펴보면 아래와 같다.
1) Rowid = Constant 의 비교
2) Unique indexed column = Constant 의 비교
3) Entire unique concatenated index = Constant 의 비교
4) Entire cluster key = Corresponding cluster key in another table in
same cluster의 비교
5) Entire cluster key = Constant 의 비교
6) Entire non unique concatenated index = Constant 의 비교
7) Non unique index = Constant 의 비교
8) Entire concatenated index >= Constant 의 비교
9) Unique indexed column BETWEEN low value AND
high value, or Unique indexed column LIKE 'C%' 의 비교
10) Non unique indexed column BETWEEN low value AND
high value, or Non Unique indexed column LIKE 'C%' 의 비교
11) Unique indexed column < or > Constant 의 비교
12) Non unique indexed column < or > Constant 의 비교
13) Sort/Merge(Joins only) 의 비교
14) Max or Min of single indexed column 의 비교
15) ORDER BY entire index 의 비교
16) Full table scans 의 비교
이 의미는 한 SQL의 WHERE 조건에 2)와 3)의 인덱스가 사용된 경우 우선
순위가 높은 2)의 인덱스가 사용되어진다는 것이다.

Rule based & Cost based optimizer

Hi,
What is the difference Rule based & Cost based optimizer ?
Thanks

Without an optimizer, all SQL statements would simply do block-by-block, row-by-row table scans and table updates.
The optimizer attempts to find a faster way of accessing rows by looking at alternatives, such as indexes.
Joins add a level of complexity - the simplest join is "take an appropriate row in the first table, scan the second table for a match". However, deciding which is the first (or driving) table is also an optimization decision.
As technology improves a lot of different techiques for accessing the rows or joining that tables have been devised, each with it's own optimium data-size:performance:cost curve.
Rule-Based Optimizer:
The optimization process follows specific defined rules, and will always follow those rules. The rules are easily documented and cover things like 'when are indexes used', 'which table is the first to be used in a join' and so on. A number of the rules are based on the form of the SQL statement, such as order of table names in the FROM clause.
In the hands of an expert Oracle SQL tuner, the RBO is a wonderful tool - except that it does not support such advanced as query rewrite and bitmap indexes. In the hands of the typical developer, the RBO is a surefire recipie for slow SQL.
Cost-Based Optimizer:
The optimization process internally sets up multiple execution proposals and extrapolates the cost of each proposal using statistics and knowledge of the disk, CPU and memory usage of each of the propsals. It is not unusual for the optimizer to analyze hundred, or even thousands, of proposals - remember, something as simple as a different order of table names is a proposal. The proposal with the least cost is generally selected to be executed.
The CBO requires accurate statistics to make reasonable decisions.
Even with good statistics, the complexity of the SQL statement may cause the CBO to make a wrong decision, or ignore a specific proposal. To compensate for this, the developer may provide 'hints' or recommendations to the optimizer. (See the 10g SQL Reference manual for a list of hints.)
The CBO has been constantly improving with every release since it's inception in Oracle 7.0.12, but early missteps have given it a bad reputation. Even in Oracle8i and 9i Release 1, there were countless 'opportunities for improvement' <tm> As of Oracle 10g, the CBO is quite decent - sufficiently so that the RBO has been officially deprecated.

Re: Oracle 8i (8.1.7.4) Rule based v/s Cost based

Hi,
I would like to know the advantages/disadvantages of using RULE based optimizer v/s COST based optimizer in Oracle 8i. We have a production RULE based database and are experiencing performance issues on some queries sporadically.
TKPROF revealed:
call     count       cpu    elapsed             disk                  query                current              rows
Parse        0      0.00       0.00                0                      0                      0                      0
Execute      3     94.67    2699.16            1020421            5692711            51404               0
Fetch       13    140.93    4204.41            688482             4073366          0                      26896
total       16       235.60    6903.57           1708903           9766077            51404               26896
Please post your expert suggestions as soon as possible.
Thanks and Regards,
A

I think the answer you are looking for is that Rule Based optimizer is predictive, but Cost Based optimizer results may vary depending on statistics of rows, indexes, etc. But at the same time, you can typically get better speed for OLTP relational databases with CBO, assuming you have correct statistics, and correct optimizer settings set.

Top Link Special Considerations in moving to Cost Based Optimizer....

Our current application architecture consists of running a Java based application with Oracle 9i as the database and toplink as the object relational mapping tool. This is a hosted application about 5 years old with stringent SLA requirements and high availability needs. We are currently using Rule Based Optimizer (RBO) mode and do not collect statistics for the schemas. We are planning a move to Cost Based Optimizer (CBO)
What are the special considerations we need to be aware of from moving RBO to CBO from top link perspective. Is top link code optimized for one mode over the other ?. What special parameter settings are needed ?. Any of your experience in moving Top Link based applications to RBO and best practices will be very much appreciated.
-Thanks
Ganesan Maha

Ganesan,
Over the 10 years we have been delivering TopLink I do not recall any issues with customizing TopLink for either approach. You do have the ability to customize how the SQL is generated and even replace the generated SQL with custom queries should you need to. This will not require application changes but simply modifications to the TopLink metadata.
As of 9.0.4 you can also provide hints in the TopLink query and expression framework that will be generated into the SQL to assist the optimizer.
Doug

Partitioning on Oracle 8i (Rule Based vs. Cost Based)

At my current engagement, we are using Oracle Financials 11.0.3 on Oracle 8.0.6. The application uses rule-based optimizer. The client wants to 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?
Could it degrade performance at the SQL level?
If this change from 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

Rule based Optimiser in 10g

Can anyone tell me if there is still a rule based optimiser in 10g, i have heard that it has been removed? Is this correct?

Here's what's in the Database Performance Tuning Guide 10g Release 1:
Rule-based Optimization (RBO) Obsolescence
RBO as a functionality is no longer supported. RBO still exists in Oracle 10g Release 1, but is an unsupported feature. No code changes have been made to RBO and no bug fixes are provided. Oracle supports only the query optimizer, and all applications running on Oracle Database 10g Release 1 (10.1) should use that optimizer. Please review the following Oracle Metalink desupport notice (189702.1) for RBO:
http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_
database_id=NOT&p_id=189702.1
You can also access desupport notice 189702.1 and related notices by searching for "desupport of RBO" at:
http://metalink.oracle.com
Notice 189702.1 provides details about the desupport of RBO and the migration of applications based on RBO to query optimization.
Some consequences of the desupport of RBO are:
CHOOSE and RULE are no longer supported as OPTIMIZER_MODE initialization parameter values and a warning is displayed in the alert log if the value is set to RULE or CHOOSE. The functionalities of those parameter values still exist but will be removed in a future release. See "OPTIMIZER_MODE Initialization Parameter" for information optimizer mode parameters.
ALL_ROWS is the default value for the OPTIMIZER_MODE initialization parameter.
The CHOOSE and RULE optimizer hints are no longer supported. The functionalities of those hints still exist but will be removed in a future release.
Existing applications that previously relied on rule-based optimization (RBO) need to be moved to query optimization.
HTH

Cost Based Optimizer (CBO)

not sure if this is a daft question or what. but i am trying to find out where exactly it exists.
i know, when performing ST05 and viewing the execution plan, we see what the CBO has used, but is the CBO purely performed at the database server, and not at the SAP Application.
When updating the statistics, are these passed to the database server, and once again, the CBO utilizes them for the execution plan, or do the database statistics actually reside in the database server.
finally, in viewing the execution plan, the statement "execution costs = xxx" (xxx being a numeric value). what exactly is xxx. maybe an internal index used to compare execution plans, or maybe the number of blocks required to read the "estimated #rows".
anyone ??
thanks
glen

Hello Glen,
So far as my knowledge is concerned, the statistics are actually located on the database server. That is what appears to be more logical too. what is the use of maintaining the access paths on tha application server ? Most of the modern database servers are equipped with the CBO functionality. And Cost-Based-Optimizing is dependent on the database.
Here's what the documentation says:
<i>You can update statistics on the Oracle database using the Computing Center Management System (CCMS). The transactions to be used are DB20 and DB21.
By running update statistics regularly, you make sure that the database statistics are up-to-date, so improving database performance. The Oracle cost-based optimizer (CBO) uses the statistics to optimize access paths when retrieving data for queries. If the statistics are out-of-date, the CBO might generate inappropriate access paths (such as using the wrong index), resulting in poor performance.
From Release 4.0, the CBO is a standard part of the SAP System. If statistics are available for a table, the database system uses the cost-based optimizer. Otherwise, it uses the rule-based optimizer.</i>
Regards,
Anand Mandalika.

How can I know the database is using Cost Based or Rule Based?

Hi all expertise,
How can I know the database is using Cost Based or Rule Based?
If cost based it is using, what methods are need to use to minimize the cost when database is running? And which tables I can see the performance of the database?
Thanks
Amy

how to see database setting ?
use this
SQL> sho parameter optimizer
NAME TYPE VALUE
optimizer_dynamic_sampling integer 1
optimizer_features_enable string 9.2.0
optimizer_index_caching integer 0
optimizer_index_cost_adj integer 100
optimizer_max_permutations integer 2000
optimizer_mode string CHOOSE
choose means if table statistics is available then it will use cost
else
use rule based optimizer
for seeing performnace of table use
set autotrace on
and run your query
if it doen't show cost.it means it use rule based
for using cost based
u will calculate table statistics
9i
dbms_stats.gather_table_stats('owner','table');
8i
analyze table <table_name> compute statistics;
hope it will help you
kuljeet pal singh

Rule Based Optimization

Similar Messages

Maybe you are looking for