Comments on: first_rows_n

By: First_rows hash « Oracle Scratchpad

First_rows hash « Oracle Scratchpad — Mon, 12 Mar 2012 01:51:11 +0000

[...] the internet from time to time along the lines of “first_rows_N is for OLTP systems” (that’s not really correct, by the way), it’s probably best to stick with all_rows unless you can come up with a very [...]

By: True or False – Optimizer Mode and Tuning Goals « Charles Hooper's Oracle Notes

Thu, 13 May 2010 06:02:16 +0000

[...] http://jonathanlewis.wordpress.com/2008/11/11/first_rows_n/ [...]

By: first_rows_N again « Oracle Scratchpad

first_rows_N again « Oracle Scratchpad — Sun, 10 Jan 2010 19:03:40 +0000

[...] effects and first_rows_n, and an example of the problem in this item on the OTN database forum. Leave a [...]

By: Jonathan Lewis

Jonathan Lewis — Mon, 30 Nov 2009 09:58:12 +0000

For anyone at the UKOUG conference, Randolf Geist will be doing a presentation all about first_rows_N optimization at 11:05 on Tuesday.

By: Lothar

Lothar — Thu, 26 Nov 2009 11:17:55 +0000

There are indeed some strnage effects when cost gets adjusted to first_k_rows.
The optimzer went for highly inselective Indexes first.
Look for the token “First K Rows: ” in 10053.
It seems to be related to Histograms on these uselective columns, in which way is not entirely clear.
The issue seems to go away after I got rid of Histograms, but not immediatly, it could take some hours although I fluhsed the shared pool.
Note that you can set a ALL_ROWS hint in Siebel at Business component level.

By: Rownum effects « Oracle Scratchpad

Rownum effects « Oracle Scratchpad — Mon, 21 Sep 2009 11:11:30 +0000

[...] Execution plans, Hints — Jonathan Lewis @ 7:21 pm UTC Aug 7,2009 A few months ago, I wrote a note about setting the optimizer_mode to one of the first_rows_N values (first_rows_1, first_rows_10, first_rows_100, or [...]

By: Joe Coffey

Joe Coffey — Mon, 10 Aug 2009 13:43:10 +0000

Thanks for the note and I will keep an eye on Randolf’s blog as well. Since this problem is
1. Usually limited to a few queries per installation and easily remedied by stored outline
and
2. Seems to not re-occur often (only once in my sphere) since Siebel customers started using 10g.

I suspect that this will remain one of those where resolution < root cause solution.

If I do have opportunity to expose more on it, I'll post back here, but it does look like something related in the optimizer changed for the better between 9i and 10g.

By: Timur Akhmadeev

Timur Akhmadeev — Fri, 07 Aug 2009 07:34:03 +0000

Hi Joe, here is recent OTN thread which looks very similar to your problem.

By: Jonathan Lewis

Jonathan Lewis — Thu, 06 Aug 2009 17:15:35 +0000

Joe, I don't have any definite information about this but there is a new parameter in 10g called "_first_k_rows_dynamic_proration" which has the description: "enable the use of dynamic proration of join cardinalities". That sounds as if it might be relevant. I know that Randolf Geist has been doing some work on first_rows_k in the last couple of weeks - I don't think he's published anything about it, but it might be worth keeping an eye on his blog.

By: Joe Coffey

Joe Coffey — Tue, 04 Aug 2009 15:12:50 +0000

Jonathan,

One application that makes extensive use of this is Siebel. You made some comments here (http://www.freelists.org/post/oracle-l/ORDER-BY-and-first-rows-10-madness,4) on how the optimizer behaves in this mode.

Indeed, the problem that the original poster in that thread had was quite common when running Siebel on Oracle 9i, but I haven’t seen it recently (corresponding to 10g installs). That is, execpt of course in one isolated instance that came to my attention yesterday – hence why I thought to post a note here… The basic problem is that the optimizer chooses an index that covers the sort rather than a selective filter.

Certainly, this could be influenced by statistics. But what we seem to have is a case of the same query and generally the same data pattern (its a package…) driving to a different (better) plan in 10g than in 9i. I’m wondering if there was an underlying improvement in the algorithm for this feature from 9i to 10g. Are you aware of any such change?