Very nice test case!

I think that I need to better clarify this statement:
“or can it also be helpful if during the last statistics collection a table contained 0 rows, and that table (at the time of a SQL statement execution) now contains 220 rows (such a problem was mentioned in the “Expert Oracle Practices” book)?”

What I meant by the above is that statistics were collected on the table when it last contained 0 rows (a victim of the automatic nightly stale statistics collection procedure). If statistics exist for a table, the default level of dynamic sampling will not cause a dynamic sample of the table to take place when parsing a SQL statement that accesses the table, and that could be a significant problem when the table contains 220 rows later in the day (there is a Metalink article that describes this behavior, but I cannot find it at the moment – the referenced problem/case study starts on page 306 of the “Expert Oracle Practices” book). Based on tests that I performed, it is still possible that dynamic sampling might take place if parallel query is enabled for the SQL statement and the query is executed in a recent Oracle Database release (see http://hoopercharles.wordpress.com/2010/11/12/dynamic-sampling-changes/ and Metalink ID 1102413.1) – and that agrees with your comment statement.

You supplied a very helpful comment, Centinul.

I would say no. I say it’s helpful in the cases as defined by Oracle:

“Dynamic sampling augments missing or insufficient optimizer statistics. The optimizer can improve plans by making better estimates for predicate selectivity. Dynamic sampling can supplement statistics such as table block counts, applicable index block counts, table cardinalities (estimated number of rows), and relevant join column statistics.”

Source: http://download.oracle.com/docs/cd/E11882_01/server.112/e16638/stats.htm#CHDBIGII

- can it also be helpful if during the last statistics collection a table contained 0 rows, and that table (at the time of a SQL statement execution) now contains 220 rows (such a problem was mentioned in the “Expert Oracle Practices” book)

I would say it is not helpful in this case either. The documentation states:

“In both the serial and parallel cases, the database performs dynamic sampling when existing statistics are not sufficient:

* Missing statistics

When one or more of the tables in the query do not have statistics, the optimizer gathers basic statistics on these tables before optimization. In this case, the statistics are not as high-quality or as complete as the statistics gathered using the DBMS_STATS package. This tradeoff is made to limit the impact on the compile time of the statement.

* Collected statistics cannot be used or are likely to lead to poor estimates

For example, a statement may contain a complex predicate expression, but extended statistics are not available (see “Extended Statistics”). Extended statistics help the optimizer get good quality cardinality estimates for complex predicate expressions. Dynamic sampling can compensate for the lack of extended statistics.”

In this case the table has statistics, even though they are not correct, therefore dynamic sampling won’t kick in in the general case. I imagine there are some exceptions depending on query complexity and such. I did a single table test that agreed with the Oracle documentation:

SQL > SELECT * FROM V$VERSION;

BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
PL/SQL Release 11.2.0.1.0 - Production
CORE    11.2.0.1.0      Production
TNS for 32-bit Windows: Version 11.2.0.1.0 - Production
NLSRTL Version 11.2.0.1.0 - Production

SQL> CREATE TABLE T AS SELECT * FROM DUAL WHERE 1=0;

Table created.

SQL> SELECT /*+ gather_plan_statistics FINDME1 */ * FROM T;

no rows selected

SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL,'ALLSTATS LAST'));

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

SQL_ID  9k684tyna45bn, child number 0
-------------------------------------
SELECT /*+ gather_plan_statistics FINDME1 */ * FROM T

Plan hash value: 1601196873

--------------------------------------------------------------------------
| Id  | Operation         | Name | Starts | E-Rows | A-Rows |   A-Time   |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |      1 |        |      0 |00:00:00.01 |
|   1 |  TABLE ACCESS FULL| T    |      1 |      1 |      0 |00:00:00.01 |
--------------------------------------------------------------------------

Note
-----
   - dynamic sampling used for this statement (level=2)


17 rows selected.

SQL> EXEC DBMS_STATS.GATHER_TABLE_STATS(USER,'T');

PL/SQL procedure successfully completed.

SQL> INSERT INTO T SELECT DUMMY FROM DUAL CONNECT BY LEVEL <= 200;

200 rows created.

SQL> COMMIT;

Commit complete.

SQL> SELECT /*+ gather_plan_statistics FINDME2 */ * FROM T;

<snipped>

200 rows selected.

SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL,'ALLSTATS LAST'));

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

SQL_ID  7kc7qr4satk2n, child number 0
-------------------------------------
SELECT /*+ gather_plan_statistics FINDME2 */ * FROM T

Plan hash value: 1601196873

------------------------------------------------------------------------------------
| Id  | Operation         | Name | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |      1 |        |    200 |00:00:00.01 |      21 |
|   1 |  TABLE ACCESS FULL| T    |      1 |      1 |    200 |00:00:00.01 |      21 |
------------------------------------------------------------------------------------


13 rows selected.

SQL>

SQL> SELECT /*+ gather_plan_statistics dynamic_sampling(t 10) FINDME3 */ * FROM T;

<snipped>

200 rows selected.

SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL,'ALLSTATS LAST'));

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

SQL_ID  dcg54c4fmdh9h, child number 0
-------------------------------------
SELECT /*+ gather_plan_statistics dynamic_sampling(t 10) FINDME3 */ *
FROM T

Plan hash value: 1601196873

------------------------------------------------------------------------------------
| Id  | Operation         | Name | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |      1 |        |    200 |00:00:00.01 |      21 |
|   1 |  TABLE ACCESS FULL| T    |      1 |      1 |    200 |00:00:00.01 |      21 |
------------------------------------------------------------------------------------


14 rows selected.

SQL>

- what is a “large SQL workload”? SQL is a language, so would a large SQL workload be a SQL statement that is 10,000 characters long?

I think a “large SQL workload” is a relative term that is dependent on the hardware capabilities, software, as well as the user application running.

Very nice research.

One final thought. Is dynamic sampling only helpful in cases involving “large SQL workloads”, or can it also be helpful if during the last statistics collection a table contained 0 rows, and that table (at the time of a SQL statement execution) now contains 220 rows (such a problem was mentioned in the “Expert Oracle Practices” book)? For that matter, what is a “large SQL workload”? SQL is a language, so would a large SQL workload be a SQL statement that is 10,000 characters long?

The way I interpret that quote is that it is as if dynamic sampling and dbms_stats were new to 10g.

However, I found references to dynamic sampling as far back as 9.2:

http://download.oracle.com/docs/cd/B10501_01/server.920/a96533/sql_1016.htm#33071

I also found references to dbms_stats as far back as 8.1.7:

http://download.oracle.com/docs/cd/A87860_01/doc/appdev.817/a76936/toc.htm

It doesn’t look like Oracle added the gather_system_stats procedure until 9.0.1:

http://download.oracle.com/docs/cd/A91202_01/901_doc/appdev.901/a89852/dbms_sta.htm#1000574

Impressive answer. Reading from the start of the quote I identified a couple of other problems with the quote – I will let someone else mention those problems (hint: are those items Oracle Database 10g enhancements?).

Adding to your root cause list, another root cause might be using a different Database edition (or release version) in production than what was used in test (see the four part series http://hoopercharles.wordpress.com/2010/11/21/different-performance-from-standard-edition-and-enterprise-edition-1/ for more information).