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

Similar Messages

Quick question on how CBO determines hows to access table partitions

Hey all,
I have a large table that is range partitioned on a "code" within the table (about 23 unique values). I'm able to query it very quickly and easily when I specify the code in a query... ie:
select *
from large_table
where code = 'X'
However, I am looking to calculate the code based on a reference table that I have. I can easily re-create the performance drop doing:
select *
from large_table
where code = (Select 'X' from dual)
When running the 2nd SQL, my query takes a very long time. I think I understand why (CBO can't "guess" the results of the subquery) and I understand that the easiest to fix this would be to just run the subquery first and pass its results to a second query.
My question is if anyone knows of a way to provide the CBO a hint or any other trick that would allow Oracle to scan a single partition instead of the whole table using a method like this?

Thanks Tubby, that link at least helps confirm my original reasoning for the degraded performance and appears to be for similar reasons
As for the explain plans, here they are:
(Slow Query -- Object names have been changed)
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | Pstart| Pstop | TQ |IN-OUT| PQ Distrib |
| 0 | SELECT STATEMENT | | 413 | 219K| | 18794 (1)| 00:03:46 | | | | | |
| 1 | PX COORDINATOR | | | | | | | | | | | |
| 2 | PX SEND QC (RANDOM) | :TQ10013 | 413 | 219K| | 18794 (1)| 00:03:46 | | | Q1,13 | P->S | QC (RAND) |
|* 3 | HASH JOIN RIGHT SEMI BUFFERED | | 413 | 219K| | 18794 (1)| 00:03:46 | | | Q1,13 | PCWP | |
| 4 | BUFFER SORT | | | | | | | | | Q1,13 | PCWC | |
| 5 | PX RECEIVE | | 2 | 8 | | 15 (7)| 00:00:01 | | | Q1,13 | PCWP | |
| 6 | PX SEND HASH | :TQ10003 | 2 | 8 | | 15 (7)| 00:00:01 | | | | S->P | HASH |
| 7 | VIEW | VW_NSO_1 | 2 | 8 | | 15 (7)| 00:00:01 | | | | | |
| 8 | VIEW | view_ref_table | 2 | 26 | | 15 (7)| 00:00:01 | | | | | |
|* 9 | TABLE ACCESS FULL | ref_table | 2 | 22 | | 15 (7)| 00:00:01 | | | | | |
| 10 | PX RECEIVE | | 4543 | 2391K| | 18779 (1)| 00:03:46 | | | Q1,13 | PCWP | |
| 11 | PX SEND HASH | :TQ10012 | 4543 | 2391K| | 18779 (1)| 00:03:46 | | | Q1,12 | P->P | HASH |
|* 12 | HASH JOIN | | 4543 | 2391K| | 18779 (1)| 00:03:46 | | | Q1,12 | PCWP | |
| 13 | BUFFER SORT | | | | | | | | | Q1,12 | PCWC | |
| 14 | PX RECEIVE | | 11 | 187 | | 5 (0)| 00:00:01 | | | Q1,12 | PCWP | |
| 15 | PX SEND BROADCAST | :TQ10002 | 11 | 187 | | 5 (0)| 00:00:01 | | | | S->P | BROADCAST |
|* 16 | TABLE ACCESS FULL | threshold_table | 11 | 187 | | 5 (0)| 00:00:01 | | | | | |
|* 17 | VIEW | | 430K| 214M| | 18774 (1)| 00:03:46 | | | Q1,12 | PCWP | |
| 18 | WINDOW SORT | | 430K| 130M| 280M| 18774 (1)| 00:03:46 | | | Q1,12 | PCWP | |
| 19 | PX RECEIVE | | 430K| 130M| | 18772 (1)| 00:03:46 | | | Q1,12 | PCWP | |
| 20 | PX SEND HASH | :TQ10011 | 430K| 130M| | 18772 (1)| 00:03:46 | | | Q1,11 | P->P | HASH |
|* 21 | HASH JOIN BUFFERED | | 430K| 130M| | 18772 (1)| 00:03:46 | | | Q1,11 | PCWP | |
| 22 | BUFFER SORT | | | | | | | | | Q1,11 | PCWC | |
| 23 | PX RECEIVE | | 7332 | 157K| | 16 (13)| 00:00:01 | | | Q1,11 | PCWP | |
| 24 | PX SEND HASH | :TQ10001 | 7332 | 157K| | 16 (13)| 00:00:01 | | | | S->P | HASH |
| 25 | VIEW | view_ref_table | 7332 | 157K| | 16 (13)| 00:00:01 | | | | | |
| 26 | WINDOW SORT | | 7332 | 80652 | | 16 (13)| 00:00:01 | | | | | |
| 27 | TABLE ACCESS FULL | ref_table | 7332 | 80652 | | 14 (0)| 00:00:01 | | | | | |
| 28 | PX RECEIVE | | 129K| 36M| | 18756 (1)| 00:03:46 | | | Q1,11 | PCWP | |
| 29 | PX SEND HASH | :TQ10010 | 129K| 36M| | 18756 (1)| 00:03:46 | | | Q1,10 | P->P | HASH |
| 30 | BUFFER SORT | | 413 | 219K| | | | | | Q1,10 | PCWP | |
| 31 | NESTED LOOPS | | 129K| 36M| | 18756 (1)| 00:03:46 | | | Q1,10 | PCWP | |
| 32 | NESTED LOOPS | | 124K| 30M| | 14444 (1)| 00:02:54 | | | Q1,10 | PCWP | |
| 33 | NESTED LOOPS | | 122K| 25M| | 10173 (1)| 00:02:03 | | | Q1,10 | PCWP | |
|* 34 | HASH JOIN | | 123K| 23M| | 5893 (1)| 00:01:11 | | | Q1,10 | PCWP | |
| 35 | PX RECEIVE | | 124K| 22M| | 5629 (1)| 00:01:08 | | | Q1,10 | PCWP | |
| 36 | PX SEND HASH | :TQ10008 | 124K| 22M| | 5629 (1)| 00:01:08 | | | Q1,08 | P->P | HASH |
| 37 | BUFFER SORT | | 413 | 219K| | | | | | Q1,08 | PCWP | |
| 38 | NESTED LOOPS | | 124K| 22M| | 5629 (1)| 00:01:08 | | | Q1,08 | PCWP | |
|* 39 | HASH JOIN | | 122K| 20M| | 1797 (2)| 00:00:22 | | | Q1,08 | PCWP | |
| 40 | PX RECEIVE | | 119K| 17M| | 1101 (3)| 00:00:14 | | | Q1,08 | PCWP | |
| 41 | PX SEND HASH | :TQ10006 | 119K| 17M| | 1101 (3)| 00:00:14 | | | Q1,06 | P->P | HASH |
|* 42 | HASH JOIN | | 119K| 17M| | 1101 (3)| 00:00:14 | | | Q1,06 | PCWP | |
| 43 | BUFFER SORT | | | | | | | | | Q1,06 | PCWC | |
| 44 | PX RECEIVE | | 86 | 602 | | 3 (0)| 00:00:01 | | | Q1,06 | PCWP | |
| 45 | PX SEND BROADCAST | :TQ10000 | 86 | 602 | | 3 (0)| 00:00:01 | | | | S->P | BROADCAST |
| 46 | TABLE ACCESS FULL | OFFICE | 86 | 602 | | 3 (0)| 00:00:01 | | | | | |
|* 47 | HASH JOIN | | 119K| 16M| | 1098 (3)| 00:00:14 | | | Q1,06 | PCWP | |
| 48 | PX RECEIVE | | 47 | 940 | | 2 (0)| 00:00:01 | | | Q1,06 | PCWP | |
| 49 | PX SEND BROADCAST | :TQ10004 | 47 | 940 | | 2 (0)| 00:00:01 | | | Q1,04 | P->P | BROADCAST |
| 50 | PX BLOCK ITERATOR | | 47 | 940 | | 2 (0)| 00:00:01 | | | Q1,04 | PCWC | |
|* 51 | TABLE ACCESS FULL | REF | 47 | 940 | | 2 (0)| 00:00:01 | | | Q1,04 | PCWP | |
|* 52 | HASH JOIN | | 701K| 84M| | 1095 (3)| 00:00:14 | | | Q1,06 | PCWP | |
| 53 | PX RECEIVE | | 12 | 240 | | 2 (0)| 00:00:01 | | | Q1,06 | PCWP | |
| 54 | PX SEND BROADCAST | :TQ10005 | 12 | 240 | | 2 (0)| 00:00:01 | | | Q1,05 | P->P | BROADCAST |
| 55 | PX BLOCK ITERATOR | | 12 | 240 | | 2 (0)| 00:00:01 | | | Q1,05 | PCWC | |
|* 56 | TABLE ACCESS FULL | REF | 12 | 240 | | 2 (0)| 00:00:01 | | | Q1,05 | PCWP | |
| 57 | PX BLOCK ITERATOR | | 16M| 1617M| | 1090 (2)| 00:00:14 | 1 | 24 | Q1,06 | PCWC | |
| 58 | TABLE ACCESS FULL | Fact_Table | 16M| 1617M| | 1090 (2)| 00:00:14 | 1 | 24 | Q1,06 | PCWP | |
| 59 | PX RECEIVE | | 13M| 323M| | 693 (1)| 00:00:09 | | | Q1,08 | PCWP | |
| 60 | PX SEND HASH | :TQ10007 | 13M| 323M| | 693 (1)| 00:00:09 | | | Q1,07 | P->P | HASH |
| 61 | PX BLOCK ITERATOR | | 13M| 323M| | 693 (1)| 00:00:09 | | | Q1,07 | PCWC | |
| 62 | TABLE ACCESS FULL | Dimension 1 | 13M| 323M| | 693 (1)| 00:00:09 | | | Q1,07 | PCWP | |
| 63 | TABLE ACCESS BY INDEX ROWID | Dimesnion 2 | 1 | 12 | | 0 (0)| 00:00:01 | | | Q1,08 | PCWP | |
|* 64 | INDEX UNIQUE SCAN | Dimension 2 Index | 1 | | | 0 (0)| 00:00:01 | | | Q1,08 | PCWP | |
| 65 | PX RECEIVE | | 15M| 151M| | 261 (2)| 00:00:04 | | | Q1,10 | PCWP | |
| 66 | PX SEND HASH | :TQ10009 | 15M| 151M| | 261 (2)| 00:00:04 | | | Q1,09 | P->P | HASH |
| 67 | PX BLOCK ITERATOR | | 15M| 151M| | 261 (2)| 00:00:04 | | | Q1,09 | PCWC | |
| 68 | INDEX FAST FULL SCAN | Dimension 1 Index | 15M| 151M| | 261 (2)| 00:00:04 | | | Q1,09 | PCWP | |
| 69 | TABLE ACCESS BY INDEX ROWID | Dimension 3 | 1 | 18 | | 0 (0)| 00:00:01 | | | Q1,10 | PCWP | |
|* 70 | INDEX UNIQUE SCAN | Dimension 3 Index | 1 | | | 0 (0)| 00:00:01 | | | Q1,10 | PCWP | |
| 71 | PARTITION HASH ITERATOR | | 1 | 39 | | 0 (0)| 00:00:01 | KEY | KEY | Q1,10 | PCWP | |
| 72 | TABLE ACCESS BY LOCAL INDEX ROWID| Dimension 4 | 1 | 39 | | 0 (0)| 00:00:01 | KEY | KEY | Q1,10 | PCWP | |
|* 73 | INDEX UNIQUE SCAN | dimension 6 Index | 1 | | | 0 (0)| 00:00:01 | KEY | KEY | Q1,10 | PCWP | |
| 74 | TABLE ACCESS BY INDEX ROWID | Dimension 5 | 1 | 38 | | 0 (0)| 00:00:01 | | | Q1,10 | PCWP | |
|* 75 | INDEX UNIQUE SCAN | Dimension 5 index | 1 | | | 0 (0)| 00:00:01 | | | Q1,10 | PCWP | |
(Fast Query -- Object Names Changed)
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | Pstart| Pstop | TQ |IN-OUT| PQ Distrib |
| 0 | SELECT STATEMENT | | 107 | 57673 | | 1302 (1)| 00:00:16 | | | | | |
| 1 | PX COORDINATOR | | | | | | | | | | | |
| 2 | PX SEND QC (RANDOM) | :TQ10009 | 107 | 57673 | | 1302 (1)| 00:00:16 | | | Q1,09 | P->S | QC (RAND) |
|* 3 | HASH JOIN BUFFERED | | 107 | 57673 | | 1302 (1)| 00:00:16 | | | Q1,09 | PCWP | |
| 4 | BUFFER SORT | | | | | | | | | Q1,09 | PCWC | |
| 5 | PX RECEIVE | | 11 | 187 | | 5 (0)| 00:00:01 | | | Q1,09 | PCWP | |
| 6 | PX SEND HASH | :TQ10002 | 11 | 187 | | 5 (0)| 00:00:01 | | | | S->P | HASH |
|* 7 | TABLE ACCESS FULL | Threshold Table | 11 | 187 | | 5 (0)| 00:00:01 | | | | | |
| 8 | PX RECEIVE | | 10163 | 5180K| | 1296 (1)| 00:00:16 | | | Q1,09 | PCWP | |
| 9 | PX SEND HASH | :TQ10008 | 10163 | 5180K| | 1296 (1)| 00:00:16 | | | Q1,08 | P->P | HASH |
|* 10 | VIEW | | 10163 | 5180K| | 1296 (1)| 00:00:16 | | | Q1,08 | PCWP | |
| 11 | WINDOW SORT | | 10163 | 3185K| 6792K| 1296 (1)| 00:00:16 | | | Q1,08 | PCWP | |
| 12 | PX RECEIVE | | 10163 | 3185K| | 1295 (1)| 00:00:16 | | | Q1,08 | PCWP | |
| 13 | PX SEND HASH | :TQ10007 | 10163 | 3185K| | 1295 (1)| 00:00:16 | | | Q1,07 | P->P | HASH |
|* 14 | HASH JOIN BUFFERED | | 10163 | 3185K| | 1295 (1)| 00:00:16 | | | Q1,07 | PCWP | |
| 15 | BUFFER SORT | | | | | | | | | Q1,07 | PCWC | |
| 16 | PX RECEIVE | | 148 | 3256 | | 15 (7)| 00:00:01 | | | Q1,07 | PCWP | |
| 17 | PX SEND HASH | :TQ10001 | 148 | 3256 | | 15 (7)| 00:00:01 | | | | S->P | HASH |
| 18 | VIEW | view_ref table | 148 | 3256 | | 15 (7)| 00:00:01 | | | | | |
| 19 | WINDOW SORT | | 148 | 2072 | | 15 (7)| 00:00:01 | | | | | |
|* 20 | TABLE ACCESS FULL | ref table | 148 | 2072 | | 14 (0)| 00:00:01 | | | | | |
| 21 | PX RECEIVE | | 6867 | 2005K| | 1279 (1)| 00:00:16 | | | Q1,07 | PCWP | |
| 22 | PX SEND HASH | :TQ10006 | 6867 | 2005K| | 1279 (1)| 00:00:16 | | | Q1,06 | P->P | HASH |
| 23 | BUFFER SORT | | 107 | 57673 | | | | | | Q1,06 | PCWP | |
| 24 | NESTED LOOPS | | 6867 | 2005K| | 1279 (1)| 00:00:16 | | | Q1,06 | PCWP | |
| 25 | NESTED LOOPS | | 6591 | 1679K| | 1050 (1)| 00:00:13 | | | Q1,06 | PCWP | |
|* 26 | HASH JOIN | | 6604 | 1567K| | 821 (1)| 00:00:10 | | | Q1,06 | PCWP | |
| 27 | BUFFER SORT | | | | | | | | | Q1,06 | PCWC | |
| 28 | PX RECEIVE | | 86 | 602 | | 3 (0)| 00:00:01 | | | Q1,06 | PCWP | |
| 29 | PX SEND HASH | :TQ10000 | 86 | 602 | | 3 (0)| 00:00:01 | | | | S->P | HASH |
| 30 | TABLE ACCESS FULL | OFFICE | 86 | 602 | | 3 (0)| 00:00:01 | | | | | |
| 31 | PX RECEIVE | | 6604 | 1522K| | 817 (1)| 00:00:10 | | | Q1,06 | PCWP | |
| 32 | PX SEND HASH | :TQ10005 | 6604 | 1522K| | 817 (1)| 00:00:10 | | | Q1,05 | P->P | HASH |
| 33 | NESTED LOOPS | | 6604 | 1522K| | 817 (1)| 00:00:10 | | | Q1,05 | PCWP | |
| 34 | NESTED LOOPS | | 6541 | 1258K| | 590 (1)| 00:00:08 | | | Q1,05 | PCWP | |
| 35 | NESTED LOOPS | | 6612 | 1207K| | 475 (1)| 00:00:06 | | | Q1,05 | PCWP | |
| 36 | NESTED LOOPS | | 6507 | 1112K| | 272 (2)| 00:00:04 | | | Q1,05 | PCWP | |
|* 37 | HASH JOIN | | 6352 | 924K| | 51 (4)| 00:00:01 | | | Q1,05 | PCWP | |
| 38 | PX RECEIVE | | 47 | 940 | | 2 (0)| 00:00:01 | | | Q1,05 | PCWP | |
| 39 | PX SEND BROADCAST | :TQ10003 | 47 | 940 | | 2 (0)| 00:00:01 | | | Q1,03 | P->P | BROADCAST |
| 40 | PX BLOCK ITERATOR | | 47 | 940 | | 2 (0)| 00:00:01 | | | Q1,03 | PCWC | |
|* 41 | TABLE ACCESS FULL | REF | 47 | 940 | | 2 (0)| 00:00:01 | | | Q1,03 | PCWP | |
|* 42 | HASH JOIN | | 37236 | 4690K| | 48 (3)| 00:00:01 | | | Q1,05 | PCWP | |
| 43 | PX RECEIVE | | 12 | 240 | | 2 (0)| 00:00:01 | | | Q1,05 | PCWP | |
| 44 | PX SEND BROADCAST | :TQ10004 | 12 | 240 | | 2 (0)| 00:00:01 | | | Q1,04 | P->P | BROADCAST |
| 45 | PX BLOCK ITERATOR | | 12 | 240 | | 2 (0)| 00:00:01 | | | Q1,04 | PCWC | |
|* 46 | TABLE ACCESS FULL | REF | 12 | 240 | | 2 (0)| 00:00:01 | | | Q1,04 | PCWP | |
| 47 | PX BLOCK ITERATOR | | 849K| 88M| | 46 (3)| 00:00:01 | KEY | KEY | Q1,05 | PCWC | |
| 48 | TABLE ACCESS FULL | Fact Table | 849K| 88M| | 46 (3)| 00:00:01 | 5 | 5 | Q1,05 | PCWP | |
| 49 | TABLE ACCESS BY INDEX ROWID | Dim 1 | 1 | 26 | | 0 (0)| 00:00:01 | | | Q1,05 | PCWP | |
|* 50 | INDEX UNIQUE SCAN | Dim 1 index | 1 | | | 0 (0)| 00:00:01 | | | Q1,05 | PCWP | |
| 51 | TABLE ACCESS BY INDEX ROWID | Dim 2 | 1 | 12 | | 0 (0)| 00:00:01 | | | Q1,05 | PCWP | |
|* 52 | INDEX UNIQUE SCAN | Dim 2 index | 1 | | | 0 (0)| 00:00:01 | | | Q1,05 | PCWP | |
|* 53 | INDEX UNIQUE SCAN | Dim 3 Index | 1 | 10 | | 0 (0)| 00:00:01 | | | Q1,05 | PCWP | |
| 54 | PARTITION HASH ITERATOR | | 1 | 39 | | 0 (0)| 00:00:01 | KEY | KEY | Q1,05 | PCWP | |
| 55 | TABLE ACCESS BY LOCAL INDEX ROWID| Dim 4 | 1 | 39 | | 0 (0)| 00:00:01 | KEY | KEY | Q1,05 | PCWP | |
|* 56 | INDEX UNIQUE SCAN | Dim 4 Index | 1 | | | 0 (0)| 00:00:01 | KEY | KEY | Q1,05 | PCWP | |
| 57 | TABLE ACCESS BY INDEX ROWID | Dim 5 | 1 | 18 | | 0 (0)| 00:00:01 | | | Q1,06 | PCWP | |
|* 58 | INDEX UNIQUE SCAN | Dim 5 Index | 1 | | | 0 (0)| 00:00:01 | | | Q1,06 | PCWP | |
| 59 | TABLE ACCESS BY INDEX ROWID | Dim 6 | 1 | 38 | | 0 (0)| 00:00:01 | | | Q1,06 | PCWP | |
|* 60 | INDEX UNIQUE SCAN | Dim 6 Index | 1 | | | 0 (0)| 00:00:01 | | | Q1,06 | PCWP | |
DB Version is 10g R2:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi
PL/SQL Release 10.2.0.4.0 - Production
"CORE 10.2.0.4.0 Production"
TNS for IBM/AIX RISC System/6000: Version 10.2.0.4.0 - Productio
NLSRTL Version 10.2.0.4.0 - Production

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....

10.2.0.4 CBO behavior without histograms and binds/literals

Hello,
i have a question about the CBO and the collected statistic values LOW_VALUE and HIGH_VALUE. I have seen the following on an oracle 10.2.0.4 database.
The CBO decides for a different execution plan, if we use bind variables (without bind peeking) or literals - no histograms exist on the table columns.
Unfortunately i didn't export the statistics to reproduce this behaviour on my test database, but it was "something" like this.
Environment:
- Oracle 10g 10.2.0.4
- Bind peeking disabled (_optim_peek_user_binds=FALSE)
- No histograms
- No partitioned table/indexes
The table (TAB) has 2 indexes on it:
- One index (INDEX A1) has included the date (which was a NUMBER column) and the values in this columns spread from 0 (LOW_VALUE) up to 99991231000000 (HIGH_VALUE).
- One index (INDEX A2) has included the article number which was very selective (distinct keys nearly the same as num rows)
Now the query looks something like this:
SELECT * FROM TAB WHERE DATE BETWEEN :DATE1 AND :DATE2 AND ARTICLENR = :ARTNR;And the CBO calculated, that best execution plan would be a index range scan on both indexes and perform a btree-to-bitmap conversion .. compare the returned row-ids of both indexes and then access the table TAB with that.
What the CBO didn't know (because of the disabled bind peeking) was, that the user has entered DATE1 (=0) and DATE2 (=99991231000000) .. so the index access on index A1 doesn't make any sense.
Now i executed the query with literals just for the DATE .. so query looks something like this:
SELECT * FROM TAB WHERE DATE BETWEEN 0 AND 99991231000000 AND ARTICLENR = :ARTNR;And then the CBO did the right thing ... just access index A2 which was very selective and then acceesed the table TAB by ROWID.
The query was much faster (factor 4 to 5) and the user was happy.
As i already mentioned, that there were no historgrams i was very amazed, that the execution plan changed because of using literals.
Does anybody know in which cases the CBO includes the values in LOW_VALUE and HIGH_VALUE in its execution plan calcuation?
Until now i thought that these values will only be used in case of histograms.
Thanks and Regards

oraS wrote:
As i already mentioned, that there were no historgrams i was very amazed, that the execution plan changed because of using literals.
Does anybody know in which cases the CBO includes the values in LOW_VALUE and HIGH_VALUE in its execution plan calcuation?
Until now i thought that these values will only be used in case of histograms.I don't have any references in front of me to confirm but my estimation is that the LOW_VALUE and HIGH_VALUE are used whenever there is a range based predicate, be it, the BETWEEN or any one of the <, >, <=, >= operators. Generally speaking the selectivity formula is the range defined in the query over the HIGH_VALUE/LOW_VALUE range. There are some specific variations of this due to including the boundaries (<= vs <) and NULL values. This make sense to use when the literal values are known or the binds are being peaked at.
However, when bind peaking is disabled Oracle has no way to use the general formula above for an estimation of the rows so it mostly likely uses the 5% rule. Since in your query you have a BETWEEN clause the estimated selectivity becomes 5%*5% which equals 0.0025. This estimated cardinality could be what made the CBO decide to use the index path versus ignoring it completely.
If you can post some sample data to reproduce this test case we can confirm.
Just a follow-up question. Why is a date being stored as a number?
HTH!

CBO and spatial index

For a table with 2 million rows, with just ID=123 in the where clause it takes some msecs to return one row, but with a sdo_relate in the where clause, CBO checks both indexes, and if the spatial filter window is big, then can take 30 minutes to return.
This is the query:
SELECT g1.geometry
FROM STAGE1.PARCEL_GEOMETRIES g1
WHERE g1.id=123 and
(mdsys.sdo_relate (g1.geometry,:FilterGeometry, 'mask=ANYINTERACT querytype=window') = 'TRUE');
This is the plan:
SELECT STATEMENT ALL_ROWSCost: 2 Bytes: 32 Cardinality: 1
     8 TABLE ACCESS BY INDEX ROWID TABLE STAGE1.PARCEL_GEOMETRIES Cost: 2 Bytes: 32 Cardinality: 1
          7 BITMAP CONVERSION TO ROWIDS
               6 BITMAP AND
                    2 BITMAP CONVERSION FROM ROWIDS
                         1 INDEX RANGE SCAN INDEX STAGE1.PGM_PK Cost: 1 Cardinality: 1
                    5 BITMAP CONVERSION FROM ROWIDS
                         4 SORT ORDER BY
                              3 DOMAIN INDEX INDEX (DOMAIN) STAGE1.PGM_GMIDX Cost: 1 Cardinality: 1
When I put in a no_index hint to ignore spatial index, it returns right away:
SELECT /*+ NO_INDEX(g1 pgm_gmidx)*/ g1.geometry
FROM STAGE1.PARCEL_GEOMETRIES g1
WHERE g1.id=123 and
(mdsys.sdo_relate (g1.geometry,:FilterGeometry, 'mask=ANYINTERACT querytype=window') = 'TRUE');
Plan
SELECT STATEMENT ALL_ROWSCost: 1 Bytes: 32 Cardinality: 1
     2 TABLE ACCESS BY INDEX ROWID TABLE STAGE1.PARCEL_GEOMETRIES Cost: 1 Bytes: 32 Cardinality: 1
          1 INDEX RANGE SCAN INDEX STAGE1.PGM_PK Cost: 1 Cardinality: 1
My question is, why CBO chose to use spatial index while it knows only one row returned from id=123? With spatial index it can return 500,000 rows from sdo_relate. I do need the spatial index because for other cases it's being used. Is there anything I can do? Is this "work as design"?
Thanks!!

Thanks Bryan.
My database is 10.2.0.4. Although the problem is not the query is doing full table scan here. It's using spatial index. But problem is the attribute query, which in this case is "id=123", has cardinality 1, or 0, if the spatial query can use the 1 geometry return from "id=123", then it works very fast. But because spatial index is being used, so it takes a long time to run if the filter window is big.
In my test case I disabled the spatial index then it worked very fast. What I meant was, I couldn't use hint to disable spatial index to allow this scenario work fast because in other cases I do need the spatial index.
Thanks again!
Sharon

Query Tuning (sequential read + direct path read/write temp)

Following query takes nearly 10 minutes under 10.2.0.2 on WIN2K3 to execute but I am sure there would be an alternate to tune it further.
Major waits are 'db file sequential read' and 'direct path read temp' in addition to 'direct path write temp'
Increasing/tuning the work_area_policy/sort_area_size would help? moving the tables to faster disk would reduce PIO causing sequential read, query re-writing would prove to be helpful?.
Below is the tkprof:
SELECT
P.PER_ID
, CL.DESCR
, P.ENG_NAME
, P.ARA_NAME
, P.NATION
, P.ADDR
, ('Mob:' || NVL(P.MOB, '') || ', Home:' || NVL(P.HOME, '') || ', Bus.:' || NVL(P.BUS, '') || ', Fax:' || NVL(P.FAX, '')) PHONE
, SUM(CASE
          WHEN FT.FT_TYPE_FLG IN ('BS','BX','AD','AX') THEN FT.CUR_AMT
        ELSE 0
        END) BILL
, SUM(CASE
          WHEN FT.FT_TYPE_FLG IN ('PS','PX') THEN FT.CUR_AMT * -1
        ELSE 0
        END) PAY
, SUM(FT.CUR_AMT) DUE
, SUM(CASE
          WHEN FT.FREEZE_DTTM > '03-JUN-08' THEN
              CASE WHEN FT.FT_TYPE_FLG IN ('PS','PX') THEN FT.CUR_AMT * -1
              ELSE 0
              END
        ELSE 0
        END) PAY_02JUN
FROM
CI_FT FT
, CI_SA SA
, CI_ACCT_CHAR AC
, CI_CUST_CL_L CL
, CI_ACCT A
, CI_ACCT_PER AP
      SELECT
        P.PER_ID
        , (P.CITY || ', ' || P.STATE || ',' || P.COUNTRY) ADDR
        , MAX(DECODE(PP.PHONE_TYPE_CD, 'MOB         ', PP.PHONE)) MOB
        , MAX(DECODE(PP.PHONE_TYPE_CD, 'BUSN        ', PP.PHONE)) BUS
        , MAX(DECODE(PP.PHONE_TYPE_CD, 'HOME        ', PP.PHONE)) HOME
        , MAX(DECODE(PP.PHONE_TYPE_CD, 'FAX         ', PP.PHONE)) FAX
        , MAX(DECODE(PN.NAME_TYPE_FLG, 'PRIM', PN.ENTITY_NAME)) ENG_NAME
        , MAX(DECODE(PN.NAME_TYPE_FLG, 'ALT ', PN.ENTITY_NAME)) ARA_NAME
        , MAX(DECODE(PC.CHAR_TYPE_CD, 'NATION ', PC.CHAR_VAL)) NATION
      FROM
        CI_PER P
        , CI_PER_PHONE PP
        , CI_PER_NAME PN
        , CI_PER_CHAR PC
      WHERE
        P.PER_ID = PP.PER_ID (+)
      AND P.PER_ID = PN.PER_ID (+)
      AND P.PER_ID = PC.PER_ID (+)
      GROUP BY
        P.PER_ID
        , (P.CITY || ', ' || P.STATE || ',' || P.COUNTRY)
    ) P
WHERE
P.PER_ID = AP.PER_ID
AND AP.ACCT_ID = AC.ACCT_ID
AND AP.ACCT_ID = SA.ACCT_ID
AND AP.MAIN_CUST_SW = 'Y'
AND A.ACCT_ID = SA.ACCT_ID
AND A.ACCT_ID = AP.ACCT_ID
AND AC.CHAR_TYPE_CD = 'ACCTYPE'
AND AC.CHAR_VAL IN ('UOS', 'DEFAULT')
AND AC.ACCT_ID = SA.ACCT_ID
AND CL.LANGUAGE_CD = 'ENG'
AND A.ACCT_ID = AC.ACCT_ID
AND A.CUST_CL_CD = CL.CUST_CL_CD
AND SA.SA_ID = FT.SA_ID
AND FT.FREEZE_DTTM IS NOT NULL
GROUP BY
P.PER_ID
, CL.DESCR
, P.ENG_NAME
, P.ARA_NAME
, P.NATION
, P.ADDR
, ('Mob:' || NVL(P.MOB, '') || ', Home:' || NVL(P.HOME, '') || ', Bus.:' || NVL(P.BUS, '') || ', Fax:' || NVL(P.FAX, ''))
HAVING
SUM(FT.CUR_AMT) > 0
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.64       0.64          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch      304    353.09     430.04      21720   52997832          0        4543
total      306    353.73     430.69      21720   52997832          0        4543
Misses in library cache during parse: 1
Optimizer mode: CHOOSE
Parsing user id: 79 (CISADM)
Rows     Row Source Operation
   4543 FILTER (cr=52997832 pr=21720 pw=10311 time=430019418 us)
   5412   HASH GROUP BY (cr=52997832 pr=21720 pw=10311 time=430015729 us)
199471    VIEW (cr=52997832 pr=21720 pw=10311 time=423392346 us)
199471     HASH GROUP BY (cr=52997832 pr=21720 pw=10311 time=423192867 us)
4013304      TABLE ACCESS BY INDEX ROWID CI_FT (cr=52997832 pr=11409 pw=0 time=140469508 us)
17717785       NESTED LOOPS (cr=49295470 pr=8987 pw=0 time=407554071 us)
13704480        NESTED LOOPS (cr=21818135 pr=7655 pw=0 time=287797921 us)
2782119         NESTED LOOPS OUTER (cr=3915432 pr=2950 pw=0 time=38953485 us)
571492          NESTED LOOPS OUTER (cr=2545763 pr=2711 pw=0 time=7433194 us)
286061           NESTED LOOPS OUTER (cr=2253263 pr=2671 pw=0 time=26607373 us)
123411            NESTED LOOPS (cr=1989056 pr=2642 pw=0 time=22711194 us)
123411             NESTED LOOPS (cr=1864959 pr=2642 pw=0 time=20860026 us)
123411              NESTED LOOPS (cr=1494040 pr=1754 pw=0 time=15553373 us)
243088               NESTED LOOPS (cr=29540 pr=1754 pw=0 time=10213331 us)
13227                TABLE ACCESS FULL CI_PER (cr=251 pr=49 pw=0 time=43331 us)
243088                INDEX RANGE SCAN XM150S1 (cr=29289 pr=1705 pw=0 time=6178159 us)(object id 97173)
123411               INLIST ITERATOR (cr=1464500 pr=0 pw=0 time=7220251 us)
123411                INDEX RANGE SCAN CM064S0 (cr=1464500 pr=0 pw=0 time=5631936 us)(object id 108631)
123411              TABLE ACCESS BY INDEX ROWID CI_ACCT (cr=370919 pr=888 pw=0 time=7241286 us)
123411               INDEX UNIQUE SCAN XM148P0 (cr=247508 pr=0 pw=0 time=1198649 us)(object id 97147)
123411             TABLE ACCESS BY INDEX ROWID CI_CUST_CL_L (cr=124097 pr=0 pw=0 time=1391837 us)
123411              INDEX UNIQUE SCAN XC523P0 (cr=686 pr=0 pw=0 time=595005 us)(object id 97745)
283749            TABLE ACCESS BY INDEX ROWID CI_PER_PHONE (cr=264207 pr=29 pw=0 time=3549713 us)
283749             INDEX RANGE SCAN XM172P0 (cr=125886 pr=4 pw=0 time=1307395 us)(object id 98733)
571492           INDEX RANGE SCAN XM171S2 (cr=292500 pr=40 pw=0 time=2976807 us)(object id 98728)
2777066          TABLE ACCESS BY INDEX ROWID CI_PER_CHAR (cr=1369669 pr=239 pw=0 time=23084761 us)
2777066           INDEX RANGE SCAN XM168P0 (cr=596156 pr=53 pw=0 time=7394319 us)(object id 98719)
13704480         TABLE ACCESS BY INDEX ROWID CI_SA (cr=17902703 pr=4705 pw=0 time=163320548 us)
13704480          INDEX RANGE SCAN XM199S1 (cr=5688247 pr=104 pw=0 time=51063061 us)(object id 98973)
4013304        INDEX RANGE SCAN CM112S1 (cr=27477335 pr=1332 pw=0 time=124063022 us)(object id 116797)
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
SQL*Net message to client                     304        0.00          0.00
db file sequential read                     11366        0.34         65.63
direct path write temp                       1473        0.06          2.91
latch: cache buffers chains                    17        0.00          0.00
db file scattered read                          7        0.01          0.03
read by other session                           2        0.00          0.00
direct path read temp                        1473        0.03          6.85
SQL*Net message from client                   304        0.02          2.74
SQL*Net more data to client                   292        0.00          0.00
********************************************************************************

Luckys
I've just realised that I mis-read part of your plan:
199471     HASH GROUP BY (cr=52997832 pr=21720 pw=10311 time=423192867 us)
4013304      TABLE ACCESS BY INDEX ROWID CI_FT (cr=52997832 pr=11409 pw=0 time=140469508 us)
17717785       NESTED LOOPS (cr=49295470 pr=8987 pw=0 time=407554071 us)The time component for a line is the time it supplies, plus the sum of the time from its direct descendents.
In this case I looked at the HASH GROUP BY and TABLE ACCESS and got a difference of about 283 seconds. In fact I should have taken more notice of the other lines in the plan - comparing the HASH GROUP BY with the NESTED LOOP for a difference of about 16 seconds and assuming that the time in the TABLE ACCESS line was not to be trusted. (See http://jonathanlewis.wordpress.com/2007/04/26/heisenberg/ for a couple of comments on the timing issue).
So the grouping is responsible for relatively little of the excess time - most of the time goes into the nested loop.
I shall be using the Hints as advised, when we say we
have to "rewrite the query"
given the current context excluding the HINTS, what
exactly should I be
considering in terms of query rewrite, what
additional intelligence I can add to the
query in question so that CBO produces a different
plan.
The main consideration is what the query is supposed to report. Compare this with the way the optimizer is running the query and see if it makes sense.
When are talking about high intermediate rows
processing are we referring to this
section of the plan?;
4013304      TABLE ACCESS BY INDEX ROWID CI_FT
(cr=52997832 pr=11409 pw=0 time=140469508 us)
17717785       NESTED LOOPS (cr=49295470 pr=8987
pw=0 time=407554071 us)
13704480        NESTED LOOPS (cr=21818135 pr=7655
pw=0 time=287797921 us)
2782119         NESTED LOOPS OUTER (cr=3915432
pr=2950 pw=0 time=38953485 us)
2777066          TABLE ACCESS BY INDEX ROWID
CI_PER_CHAR (cr=1369669 pr=239 pw=0 time=23084761
us)
2777066           INDEX RANGE SCAN XM168P0 (cr=596156
pr=53 pw=0 time=7394319 us)(object id 98719)
13704480         TABLE ACCESS BY INDEX ROWID CI_SA
(cr=17902703 pr=4705 pw=0 time=163320548 us)
13704480          INDEX RANGE SCAN XM199S1
(cr=5688247 pr=104 pw=0 time=51063061 us)(object id
98973)
4013304        INDEX RANGE SCAN CM112S1 (cr=27477335
pr=1332 pw=0 time=124063022 us)(object id 116797)
Correct - one of the nested loops returns 2.78M rows - but as you run the next join you end up collecting 13.7M entires from the next index and table. That step is responsible for quite a lot of your work and time (as is the following step where you USE the 13.7M rows to probe the next index/table combination). If the optimizer had not grown the data set by merging the P view earlier on, the data sizes would be significantly smaller at that point.
Your inline view looks as if it is trying to turn rows into columns (the max(decode()) trick) - which is why I think it might be a good idea to stop Oracle from merging the view. So, as I suggested, look at the query withouth that bit of complexity and work out a sensible way to walk through the tables - bearing in mind the statistics below and the available indexes, and the amount of data your predicates identify at each stage.
Moreover tables have been analyzed:
CI_ACCT                            243068
CI_ACCT_CHAR                       222320
CI_ACCT_PER                        242971
CI_FT                              794510
CI_PER                              13227
CI_PER_CHAR                         42555
CI_PER_PHONE                        18488
CI_SA                             1082301
Parameters:
optimizer_features_enable string 10.2.0.2
optimizer_index_caching integer 100
optimizer_index_cost_adj integer 1
Unless you've been given strict instructions by a 3rd-part supplier, those settings for the optimizer_index_caching and optimizer_index_cost_adj are particularly bad - especially in 10g. With those settings, the optimizer is quite likely to choose stupid plans with excessive use of indexes - and pick the wrong index while doing it.
It's not appropriate to fiddle with system parameters to address one query - but at some stage you need to rethink your entire set of parameter settings to do things the 10g way. See this note from the Optimizer Group: http://www.oracle.com/technology/products/bi/db/10g/pdf/twp_bidw_optimizer_10gr2_0208.pdf
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
"The greatest enemy of knowledge is not ignorance,
it is the illusion of knowledge." Stephen Hawking.

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.

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.

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.

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

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

CBO (optimizer) nest-loop join question

OS: Red Hat Linux
DB: 11gR1
I have gotten two conflicting answers while reading books by Don Burleson and Dan Hotka. It has to do with the CBO and nested-joins:
One says the CBO will choose the 'smaller' table as the driving table, the other states that the 'larger' table will be the driving table. And both stick by this philosophy as the preferred goal of any SQL Tuning -- that is, one states that the 'smaller' table should be the driving table. The other says the 'larger' table should be the driving table.
I had always thought that the 'smaller' table should be the driving table. That in a nested loop the driving will not likely use an index even. Who is correct? (I am not going to say who said what, btw). :-)
But I got to let one of them know they got a 'typo' ... :-)
Thx.

user601798 wrote:
It is an over-simplistic scenario but, as I mentioned, if all other things are 'equal' -- which would include 'access time/work', then I think the small table as the driving table has the advantage.
It is not possible for +"*all* other things to be equal"+. (my emphasis).
If by +'access time/work'+ you mean the total is the same then it doesn't matter which table is first, the time/work is the same either way round.
If you want to say that the +'access time/work'+ for acquiring the first rowsource is the same for both paths, and the +'access time/work'+ for acquiring related rows from the second table is the same FOR EACH DRIVING ROW, then the total +'access time/work'+ will be difference, and it would be better to start with the smaller table. (The example by Salman Qureshi above: Re: CBO (optimizer) nest-loop join question would apply.)
On the other hand, and ignoring any idea of "all other things being equal", smaller tables tend to have smaller indexes, so if your smaller rowsource comes from a smaller table then acquiring those rows may be cheaper than acquiring rows from a larger table - which leads to the observation that (even with perfectly precise indexing):
<ul>
smaller number of rows * larger unit cost to find related rows
</ul>
may produce a larger value than
<ul>
larger number of rows * smaller unit cost to find related rows
</ul>
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
A general reminder about "Forum Etiquette / Reward Points": http://forums.oracle.com/forums/ann.jspa?annID=718
If you never mark your questions as answered people will eventually decide that it's not worth trying to answer you because they will never know whether or not their answer has been of any use, or whether you even bothered to read it.
It is also important to mark answers that you thought helpful - again it lets other people know that you appreciate their help, but it also acts as a pointer for other people when they are researching the same question, moreover it means that when you mark a bad or wrong answer as helpful someone may be prompted to tell you (and the rest of the forum) what's so bad or wrong about the answer you found helpful.

CBO possible in session even if DB is started in RBO?

Is it possible to switch some sessions into cost based optimizer mode even if the database is started in RULE mode?
Idea:
- Start the DB in RBO mode (optimzer_mode=RULE)
- Gather table statistics
- After connect, ALTER SESSION SET OPTIMIZER_MODE = CHOOSE/FIRST_ROWS for applications that need CBO
If it is possible, what CBO features are allowed? FGA / VPD, query rewrite, materialized views, function based indexes?
Thanks,
Markus

You may use hint
SELECT /*+COST*/ * from t1
or
SELECT /*+FIRST_ROW*/ * from t1
But this make sense if you have statistic information for t1.
ANALYZE TABLE T1 COMPUTE STATISTIC;

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ç

Question on RBO & CBO

Similar Messages

Maybe you are looking for