Comments on: DBMS_STATS, METHOD_OPT and FOR ALL INDEXED COLUMNS

By: Greg Rahn

Greg Rahn — Fri, 09 Mar 2012 19:52:29 +0000

I’d suggest opening up the documentation where it is discussed:
http://docs.oracle.com/cd/E11882_01/appdev.112/e25788/d_stats.htm#r4c1-t43

By: JOHN

JOHN — Fri, 09 Mar 2012 06:12:11 +0000

Hi,
Guys What do you mean by SKEW OPTION in method_opt parameter. And What should i do to gathering statistics in a very minimum time. i got table which has 12 lacs records so, what should i do?

By: Greg Rahn

Greg Rahn — Thu, 29 Dec 2011 18:00:25 +0000

Do note, you are taking that comment out of context. It is 100% correct as stated, but it is not meant to cover 100% of the use cases.
Notice that I say if there are no stats, then dynamic sampling is guaranteed to kick in (given default parameters and it meets the criteria), however, I do not say dynamic sampling won’t kick in if the table does have stats. Stating the positive does not negate the negative.
It’s all in the documentation: http://docs.oracle.com/cd/E11882_01/server.112/e16638/stats.htm#CHDHAFBJ

In your case dynamic sampling kicks in no matter what because you have a type conversion: the bind variable is a number, but the column is a string.

By: Khurram

Khurram — Thu, 29 Dec 2011 09:43:19 +0000

Greg great article , one thing i intend to clear that you said "Obviously if the table has no stats (as in your test case) or you use an explicit hint, dynamic sampling will kick in, even with bind variables." dynamic simply will kick in either you have stats or not.

SQL> create table regions2
  2  (region_id  varchar2(10) primary key,
  3   region_name varchar2(25))
  4  /

Table created.

SQL> insert into regions2 values ('1','A')
  2  /

1 row created.

SQL> insert into regions2 values (2,'B')
  2  /

1 row created.

SQL> insert into regions2 values ('3','C')
  2  /

1 row created.

SQL> insert into regions2 values ('4','D')
  2  /

1 row created.

SQL> commit
  2  /

Commit complete.

SQL> select * from regions2
  2  /

REGION_ID  REGION_NAME
---------- -------------------------
1          A
2          B
3          C
4          D

SQL> variable regid number
SQL> exec :regid:=1

PL/SQL procedure successfully completed.

SQL> select /*+ gather_plan_statistics */ *
  2    from regions2
  3   where region_id=:regid
  4  /

REGION_ID  REGION_NAME
---------- -------------------------
1          A

SQL> SELECT * FROM table(dbms_xplan.display_cursor(NULL,NULL,'ALLSTATS LAST'))
  2  /

PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------
SQL_ID  27wd2gm8ruukh, child number 0
-------------------------------------
select /*+ gather_plan_statistics */ *   from regions2   where region_id=:regid

Plan hash value: 670750275

----------------------------------------------------------------------------------------
| Id  | Operation         | Name     | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
----------------------------------------------------------------------------------------
|*  1 |  TABLE ACCESS FULL| REGIONS2 |      1 |      1 |      1 |00:00:00.01 |      16 |
----------------------------------------------------------------------------------------

PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter(TO_NUMBER("REGION_ID")=:REGID)

Note
-----
   - dynamic sampling used for this statement


21 rows selected.

SQL> exec dbms_stats.gather_table_stats('APPS','REGIONS2',cascade=>true,method_opt=>'for all columns size 254')

PL/SQL procedure successfully completed.

SQL> select /*+ gather_plan_statistics */ *
  2    from regions2
  3    where region_id=:regid
  4  /

REGION_ID  REGION_NAME
---------- -------------------------
1          A

SQL> SELECT * FROM table(dbms_xplan.display_cursor(NULL,NULL,'ALLSTATS LAST'))
  2  /

PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------
SQL_ID  27wd2gm8ruukh, child number 0
-------------------------------------
select /*+ gather_plan_statistics */ *   from regions2   where region_id=:regid

Plan hash value: 670750275

----------------------------------------------------------------------------------------
| Id  | Operation         | Name     | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
----------------------------------------------------------------------------------------
|*  1 |  TABLE ACCESS FULL| REGIONS2 |      1 |      1 |      1 |00:00:00.01 |      16 |
----------------------------------------------------------------------------------------

PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter(TO_NUMBER("REGION_ID")=:REGID)

Note
-----
   - dynamic sampling used for this statement


21 rows selected.

Khurram

By: Greg Rahn

Greg Rahn — Tue, 13 Dec 2011 00:45:16 +0000

The degree parameter for dbms_stats.gather_table_stats has nothing to do with any knowledge of data distribution in the table — it is for how many parallel servers should execute this work. It’s all in the documentation:
http://docs.oracle.com/cd/E11882_01/appdev.112/e25788/d_stats.htm#r8c1-t49

By: Khurram

Khurram — Mon, 12 Dec 2011 18:55:07 +0000

Hi Greg,

How did you know the degree of uneven distribution? I mean you used degree=>8 , how come you know the skewness for which you used degree=>8 , is it documented by oracle that what degree we need to use for what sort of data? Its not clear to me degree=>8 why not 9 and 10 …n?

Khurram

By: Greg Rahn

Greg Rahn — Thu, 08 Sep 2011 16:46:18 +0000

Have you actually read my prior responses? This has already been discussed.

By: Greg Rahn

Greg Rahn — Thu, 08 Sep 2011 16:44:50 +0000

Have you actually read my prior response? The part where I say:”You should recognize the examples are not about full table scan or not.”

By: GP

GP — Wed, 07 Sep 2011 15:50:30 +0000

why bother with cardinality when full table scanning, unless histograms store physical addresses and allow a query to determine which rows are read based on physical addresses stored in histogram buckets? cardinality helps indexing not full scans. full scans read disk in contiguous blocks in physical order, random access, why would cardinality be an issue. And warehouses without indexes are are unindexed because they read all the data anyway and it’s faster to full scan the tables rather than read index + tables. In my experience, the only reason to index a warehouse is PKs on dimensions (could be uniques maybe) and non-constrained indexes on FK inversions in facts – all for kjoining and sometimes bitmaps on fact FKs (not really FKs) can help depending on data volatility. If there are no dimensions and/or there are mutliple facts and joins between them then the only thing that generally helps is partitioning under the assumption that data is read in full tables or full partitions. However, the next time I build a warehouse I will experiment with histograms on non keyed columns just to see what they do with optimized WHERE clauses, i do know for a fact that index searches on histogramm’ed indexed columns can make huge differences, but again, my overall strategy with a warehouse is often to remove all indexing and use partition keys (usually).

By: GP

GP — Wed, 07 Sep 2011 15:42:40 +0000

dynamic sampling not used for bind variables is incorrect? I am inclined to agree. It doesn’t make any sense.