Comments on: Oracle 11g: Extended Statistics

By: Extended Stats « Oracle Scratchpad

Extended Stats « Oracle Scratchpad — Wed, 11 Apr 2012 23:37:33 +0000

[...] very keen on the 11g extended stats feature, but I’ve just discovered a critical weakness in one of the implementation details [...]

By: Index Upgrades « Oracle Scratchpad

Index Upgrades « Oracle Scratchpad — Fri, 09 Mar 2012 18:06:07 +0000

[...] use the number of distinct keys for an index in much the same way that it can take advantage of extended statistics (specifically in the “column group” variant) to improve its estimates of cardinality [...]

By: I wish « Oracle Scratchpad

I wish « Oracle Scratchpad — Tue, 13 Dec 2011 18:09:26 +0000

[...] values for each of the possible prefixes for that index. This could piggy-back on the existing extended statistics feature, and wouldn’t be too expensive to operate if it used the approximate NDV mechanism; [...]

By: I wish (2) « Oracle Scratchpad

I wish (2) « Oracle Scratchpad — Fri, 18 Jun 2010 06:43:07 +0000

[...] course, you can emulate this in 11g with extended statistics – and you might argue that it’s better to make it a deliberate choice. Given the new [...]

By: Best Practices for Statistics Gathering on Oracle 11g « ocpdba oracle weblog

Thu, 13 May 2010 13:43:57 +0000

[...] See an example in this very good article. [...]

By: Kerry Osborne’s Oracle Blog » Blog Archive I’ll Gladly Pay You Tuesday for a Hamburger Today - Kerry Osborne’s Oracle Blog

Thu, 21 May 2009 00:31:44 +0000

[...] So the short term fix worked. The statements picked up the correct plans after re-parsing. Now let’s talk about the long term fix. Why did the partition not have stats on it? Turns out the partitioning scheme in place was range by date with a new partition for each week. Each partition goes from Thursday through the following Wednesday. Several partitions had been created in advance but as you may have guessed by now, nothing was done about the stats. Meaning that the partitions had values of 0 for the number of rows. Since the gather stats job was kicking in every evening, a whole days worth of data could be loaded into the partition before the stats would be updated. So that means that 24 hours worth of activity would occur with “bad” stats every week. Couple that with the default of NO_INVALIDATE=TRUE on the stats gathering and you get statements that may hang around for extended periods of time, even if the stats change dramatically (0 rows to a few million is dramatic, right?). So we manually set the stats on the pre-created partitions using a combination of dbms_stats.copy_table_stats and dbms_stats.set_table_stats and dbms_stats.set_column_stats (see Dion Cho’s excellent post for details and example code – and also this post on the Optimizermagic Blog for further info). I should also mention that Greg Rahn has several good posts on 11g Statistics Enhancements here, here, and here. [...]

By: Virtual Columns « Oracle Scratchpad

Virtual Columns « Oracle Scratchpad — Thu, 16 Apr 2009 21:47:08 +0000

[...] without such as (sal + nvl(comm,0)) without creating a virtual column by making a call to dbms_stats.create_extended_stats(). But this will create exactly the same hidden virtual column that you would have had anyway, with [...]

By: Correlation, nocorrelation and extended stats « Oracle database internals by Riyaj

Fri, 19 Dec 2008 00:05:57 +0000

[...] zodiac sign and birth date in his Script. [ You can read his blog entry about extended statistics here ]. I used that script to create tables, populate data, etc and I will quickly jump to the [...]

By: Greg Rahn

Greg Rahn — Sat, 25 Oct 2008 16:45:30 +0000

@Jean
I’ve only run it against generated data.

By: Jean

Jean — Sat, 25 Oct 2008 06:07:01 +0000

has this very beautiful code ever been run against any real datasets? do we know if any sign(s) has a significantly larger no. of births? just curious.