Comments on: Debugging SQL with Oracle Cost Based Optimizer http://blog.notesonsiebel.com/2007/10/16/debugging-sql-with-oracle-cost-based-optimizer/ Technical advice, help and instruction with Siebel Systems Fri, 21 Nov 2008 20:14:13 +0000 http://wordpress.org/?v=2.6.3 By: stuandgravy http://blog.notesonsiebel.com/2007/10/16/debugging-sql-with-oracle-cost-based-optimizer/#comment-57 stuandgravy Tue, 27 Nov 2007 11:25:27 +0000 http://blog.notesonsiebel.com/2007/10/16/debugging-sql-with-oracle-cost-based-optimizer/#comment-57 Great info, thanks Mike. Robert's <a href="http://siebel.ittoolbox.com/groups/technical-functional/siebel-dev-l/making-siebel-run-fast-with-oracle-cbo-new-pps-recommendation-optimizer_index_cost_adj-1717907" rel="nofollow">original post</a>, for anyone interested. Great info, thanks Mike.

Robert’s original post, for anyone interested.

]]> By: Mike Lin http://blog.notesonsiebel.com/2007/10/16/debugging-sql-with-oracle-cost-based-optimizer/#comment-56 Mike Lin Tue, 27 Nov 2007 00:54:49 +0000 http://blog.notesonsiebel.com/2007/10/16/debugging-sql-with-oracle-cost-based-optimizer/#comment-56 There was an interesting post on ITToolbox from Robert Ponder about the Oracle CBO parameter optimizer_index_cost_adj, which is a setting that tells the optimizer whether to favor index scans or full-table scans. Oracle's default value of 100 (on a 1 to 1000 range) tells the optimizer that the cost of each is the same, so the optimizer weights them equally when determining the execution plan. Siebel recommends a value of 1, which tells the optimizer that index scans are much prefered over full-table scans. The new thinking is that this value might be too low, and a setting of 1 may result in a less-than-optimal plan to be chosen. I don't fully understand it, so I can't tell you what the sweet spot is. Robert is recommending a setting of 10, although an Oracle RAC expert recommended setting this parameter back to the default setting of 100. The way to fine-tune this may just be to start lowering the value from 100 until you get a peak in performance. For those of you thinking, "but isn't it always better to do a index scan versus a full-table scan?" The answer is not always. It depends on the make-up of your data (especially table size), and your hardware. The faster your system is able to handle multi-block reads, or the fewer blocks that need to be read, the cheaper full-table scans become. There was an interesting post on ITToolbox from Robert Ponder about the Oracle CBO parameter optimizer_index_cost_adj, which is a setting that tells the optimizer whether to favor index scans or full-table scans. Oracle’s default value of 100 (on a 1 to 1000 range) tells the optimizer that the cost of each is the same, so the optimizer weights them equally when determining the execution plan. Siebel recommends a value of 1, which tells the optimizer that index scans are much prefered over full-table scans.

The new thinking is that this value might be too low, and a setting of 1 may result in a less-than-optimal plan to be chosen. I don’t fully understand it, so I can’t tell you what the sweet spot is. Robert is recommending a setting of 10, although an Oracle RAC expert recommended setting this parameter back to the default setting of 100.

The way to fine-tune this may just be to start lowering the value from 100 until you get a peak in performance.

For those of you thinking, “but isn’t it always better to do a index scan versus a full-table scan?” The answer is not always. It depends on the make-up of your data (especially table size), and your hardware. The faster your system is able to handle multi-block reads, or the fewer blocks that need to be read, the cheaper full-table scans become.

]]> By: stuandgravy http://blog.notesonsiebel.com/2007/10/16/debugging-sql-with-oracle-cost-based-optimizer/#comment-55 stuandgravy Tue, 16 Oct 2007 23:39:03 +0000 http://blog.notesonsiebel.com/2007/10/16/debugging-sql-with-oracle-cost-based-optimizer/#comment-55 Good point about using bind variables - another thing that can catch you trying to debug. Good point about using bind variables - another thing that can catch you trying to debug.

]]> By: Andy C http://blog.notesonsiebel.com/2007/10/16/debugging-sql-with-oracle-cost-based-optimizer/#comment-54 Andy C Tue, 16 Oct 2007 08:15:48 +0000 http://blog.notesonsiebel.com/2007/10/16/debugging-sql-with-oracle-cost-based-optimizer/#comment-54 Hi Stuart Great post. The issue of stats on empty tables is well documented (<a href="https://metalink3.oracle.com/od/faces/secure/km/DocumentDisplay.jspx?id=478242.1&h=Y" rel="nofollow">Alert 1162</a>) but not widely known in the Siebel community. Another potential gotcha when debugging Siebel queries in TOAD is that people often substitute literals where Siebel Object Manager uses bind variables. The presence of literals forces Oracle to re-parse the query and potentially can generate a different plan (and hence different performance). Andy Hi Stuart

Great post. The issue of stats on empty tables is well documented (Alert 1162) but not widely known in the Siebel community.

Another potential gotcha when debugging Siebel queries in TOAD is that people often substitute literals where Siebel Object Manager uses bind variables.

The presence of literals forces Oracle to re-parse the query and potentially can generate a different plan (and hence different performance).

Andy

]]>