The fix hasn’t been included in any official patch sets yet, but there are a lot of one-off patches already available and the special patch sets for the Windows platform include them already in 11.2.0.2 releases.

It would be interesting to see if the patch changes the result of the test case here.

Randolf

I can’t reply to your reply … probably too nested already. Anyway, thanks a lot for the list of pointers to the MOS notes. Some of them I already knew but I’ll certainly go through them when preparing the remaining Dynamic Sampling articles.

Thanks!

Randolf

Bug 12399886 is an interesting find. The 11.2.0.3 patchset information found in MOS list several dynamic sampling related fixes. The 11.2.0.2 patch for Bug 12399886 seems to be Solaris specific (if someone running 11.2.0.2 on Solaris is interested in performing some tests):
https://updates.oracle.com/Orion/PatchDetails/process_form?aru=13818718

While looking through MOS I found a couple of articles that might be of interest for one of your future dynamic sampling articles. Some of these problems have been fixed in (or before)11.2.0.3, while some of the problems are listed in MOS as still existing in 11.2.0.3:
Bug 13682550 (cardinality feedback)
Bug 12828479 (multi-column join)
Bug 13104618 (user functions)
Bug 12942119 (index statistics, no table statistics)
Bug 12569713 (sub-partition)
Bug 9362218 (literals replaced with bind variables when CURSOR_SHARING=EXACT)
Bug 12569713 (partition pruning)

Thank you for taking the time to look through the test case results, and summarizing the results into a meaningful explanation of what is happening.

thanks for all the experiments you’ve done. It looks like you’ve identified an interesting change in behaviour between 11.2 and previous releases:

- Whereas previous releases do not generate index statistics when the CREATE INDEX is done on an empty table, 11.2 does so – as consequence the index statistics show 0 for all relevant values, whereas in pre-11.2 no statistics for the index are there

This can be seen from your snippets above:

10.2.0.5:

Index Stats::
Index: IND_T6_C2 Col#: 2 (NOT ANALYZED)
LVLS: 1 #LB: 25 #DK: 100 LB/K: 1.00 DB/K: 1.00 CLUF: 800.00

11.2.0.2:

Index Stats::
Index: IND_T6_C2 Col#: 2
LVLS: 0 #LB: 0 #DK: 0 LB/K: 0.00 DB/K: 0.00 CLUF: 0.00

The 11.2.0.2 version shows 0 for all values, but the 10.2.0.5 version shows “(NOT ANALYZED)” along with the hard coded defaults assumed in such a case.

- This has severe consequences on the costing: Without index statistics some clustering factor (I assume the default of 800, possibly depending in the default block size) gets used for calculating the cost of the table access, whereas with index statistics in place the optimizer unfortunately uses an inconsistent approach: For the index access part the leaf blocks statistics get actually overridden by Dynamic Sampling even in the presence of the “0″ statistics gathered in 11.2.0.2. You’ll find something similar to the following in the 11.2.0.2 10053 trace file for the scenario where table stats are missing but index stats have been gathered:

** Dynamic sampling updated index stats.: IND_T6_C2, blocks=244

This is clearly an inconsistent behaviour because by default Dynamic Sampling is not supposed to override existing statistics. This is only to be done when the DYNAMIC_SAMPLING_EST_CDN hint is explicitly added for a particular table.

But the clustering factor is not overridden in the same way and therefore for the table access part of the plan the clustering factor is taken from the existing index statistics, in this case 0, which means that the table access is costed as 0 (formula is clustering_factor * table_selectivity)

This explains the odd results. By deleting the index statistics some clustering factor is assumed and the costing for the table access changes to something more reasonable.

- Just to add the final wrinkle: Enter 11.2.0.3 and check V$SYSTEM_FIX_CONTROL for bugno 12399886. In 11.2.0.3 the Dynamic Sampling code has been modified and a different clustering factor (probably derived from the estimated cardinality or blocks) will be used when the index stats are missing (11.2.0.3 still shows the same inconsistent behaviour in case table stats are missing but index stats are there).

This means potential plan changes for anyone who is using indexes and Dynamic Sampling…

Randolf

I am not sure about how much one can expect dynamic sampling (as a concept) to do. Since Dynamic Sampling is expected to “help” in the event of absence of statistics or stale statistics, one could argue that, in theory, dynamic sampling should try to generate accurate data for table as well as all indexes relevant to the query. But I also think that might make parse step so expensive and/or time-consuming that the original benifit will be lost. I must admit I am still not sure I understand how it (dynamic sampling) works actually, especially when it comes to indexes (B*Tree or Bitmap).
As for the “results did not change” comment, I was only focussing on the plan changes and not costing, in particular.

I started to wonder if maybe deferred segment creation on 11.2.0.1/11.2.0.2 combined with creating the index immediately after creating the table structure might be contributing to the LVLS: 0 #LB: 0 #DK: 0 LB/K: 0.00 DB/K: 0.00 CLUF: 0.00 index statistics that are found in the 11.2.0.2 trace file, while LVLS: 1 #LB: 25 #DK: 100 LB/K: 1.00 DB/K: 1.00 CLUF: 800.00 appears in the 10.2.0.5 trace file. 10.2.0.5, of course, did not support deferred segment creation (link to the documentation http://docs.oracle.com/cd/E11882_01/server.112/e17120/tables002.htm#CHDGJAGB ). I tested that theory with the following test script:

/* Deferred segment creation version */
DROP TABLE T6 PURGE;
 
CREATE TABLE T6 (
  C1 NUMBER NOT NULL,
  C2 NUMBER NOT NULL,
  C3 VARCHAR2(300) NOT NULL);
 
CREATE INDEX IND_T6_C2 ON T6(C2);
 
INSERT INTO
  T6
SELECT
  ROWNUM C1,
  DECODE(MOD(ROWNUM,5),0,0,ROWNUM) C2,
  RPAD('A',300,'A') C3
FROM
  DUAL
CONNECT BY
  LEVEL<=100000;
 
COMMIT; 
 
ALTER SESSION SET TRACEFILE_IDENTIFIER = '1005310046TraceDef';
ALTER SESSION SET EVENTS '10053 TRACE NAME CONTEXT FOREVER, LEVEL 1';
ALTER SESSION SET EVENTS '10046 TRACE NAME CONTEXT FOREVER, LEVEL 8';
 
SET LINESIZE 120
SET PAGESIZE 1000
VAR V2 NUMBER
 
EXEC :V2:=0
 
SELECT /*+ GATHER_PLAN_STATISTICS */
  C1
FROM
  T6
WHERE
  C2=:V2;
 
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL,'ALLSTATS LAST +PEEKED_BINDS +COST'));
 
ALTER SESSION SET EVENTS '10046 TRACE NAME CONTEXT OFF';
ALTER SESSION SET EVENTS '10053 TRACE NAME CONTEXT OFF';

/* Non-deferred segment creation version */
DROP TABLE T6 PURGE;
 
CREATE TABLE T6 (
  C1 NUMBER NOT NULL,
  C2 NUMBER NOT NULL,
  C3 VARCHAR2(300) NOT NULL)
 SEGMENT CREATION IMMEDIATE;
 
CREATE INDEX IND_T6_C2 ON T6(C2);
 
INSERT INTO
  T6
SELECT
  ROWNUM C1,
  DECODE(MOD(ROWNUM,5),0,0,ROWNUM) C2,
  RPAD('A',300,'A') C3
FROM
  DUAL
CONNECT BY
  LEVEL<=100000;
 
COMMIT; 

ALTER SESSION SET TRACEFILE_IDENTIFIER = '1005310046TraceNotDef';
ALTER SESSION SET EVENTS '10053 TRACE NAME CONTEXT FOREVER, LEVEL 1';
ALTER SESSION SET EVENTS '10046 TRACE NAME CONTEXT FOREVER, LEVEL 8';
 
SET LINESIZE 120
SET PAGESIZE 1000
VAR V2 NUMBER
 
EXEC :V2:=0
 
SELECT /*+ GATHER_PLAN_STATISTICS */
  C1
FROM
  T6
WHERE
  C2=:V2;
 
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL,'ALLSTATS LAST +PEEKED_BINDS +COST'));
 
ALTER SESSION SET EVENTS '10046 TRACE NAME CONTEXT OFF';
ALTER SESSION SET EVENTS '10053 TRACE NAME CONTEXT OFF';

Disabling deferred segment creation made no difference. This is the execution plan when deferred segment creation is disabled for the table:

SQL_ID  bxnurhc1nmq2g, child number 0
-------------------------------------
SELECT /*+ GATHER_PLAN_STATISTICS */   C1 FROM   T6 WHERE   C2=:V2
 
Plan hash value: 4242288932
 
----------------------------------------------------------------------------------------------------------------
| Id  | Operation                   | Name      | Starts | E-Rows | Cost (%CPU)| A-Rows |   A-Time   | Buffers |
----------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |           |      1 |        |    49 (100)|  20000 |00:00:00.02 |    6974 |
|   1 |  TABLE ACCESS BY INDEX ROWID| T6        |      1 |  17609 |    49   (0)|  20000 |00:00:00.02 |    6974 |
|*  2 |   INDEX RANGE SCAN          | IND_T6_C2 |      1 |  17609 |    49   (0)|  20000 |00:00:00.01 |    1404 |
----------------------------------------------------------------------------------------------------------------
 
Peeked Binds (identified by position):
--------------------------------------
   1 - (NUMBER): 0
 
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - access("C2"=:V2)
 
Note
-----
   - dynamic sampling used for this statement (level=2)

Standard Edition, of course, does not support deffered segment creation, so I decided to repeat the test on 11.2.0.2 Standard Edition – the results certainly are different, but not better (the Cost column value for the index access is shown as 1):

SQL_ID  bxnurhc1nmq2g, child number 0
-------------------------------------
SELECT /*+ GATHER_PLAN_STATISTICS */   C1 FROM   T6 WHERE   C2=:V2
 
Plan hash value: 4242288932
 
----------------------------------------------------------------------------------------------------------------
| Id  | Operation                   | Name      | Starts | E-Rows | Cost (%CPU)| A-Rows |   A-Time   | Buffers |
----------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |           |      1 |        |     1 (100)|  20000 |00:00:00.05 |    6977 |
|   1 |  TABLE ACCESS BY INDEX ROWID| T6        |      1 |  16675 |     1   (0)|  20000 |00:00:00.05 |    6977 |
|*  2 |   INDEX RANGE SCAN          | IND_T6_C2 |      1 |    336 |     1   (0)|  20000 |00:00:00.02 |    1412 |
----------------------------------------------------------------------------------------------------------------
 
Peeked Binds (identified by position):
--------------------------------------
   1 - (NUMBER): 0
 
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - access("C2"=:V2)
 
Note
-----
   - dynamic sampling used for this statement (level=2)

Thanks for the comments – always helpful. I still on occasion have a bit of difficulty making sense of portions of 10053 trace files (and working with dynamic sampling).

The comment about the CLUSTERING_FACTOR seems to be relevant. This is from the 11.2.0.2 10053 trace file:

***************************************
BASE STATISTICAL INFORMATION
***********************
Table Stats::
  Table: T6  Alias: T6  (NOT ANALYZED)
    #Rows: 82  #Blks:  1  AvgRowLen:  100.00  ChainCnt:  0.00
Index Stats::
  Index: IND_T6_C2  Col#: 2
    LVLS: 0  #LB: 0  #DK: 0  LB/K: 0.00  DB/K: 0.00  CLUF: 0.00
Access path analysis for T6

This is the same section from the 10.2.0.5 trace file when executing exactly the same script:

***************************************
BASE STATISTICAL INFORMATION
***********************
Table Stats::
  Table: T6  Alias: T6  (NOT ANALYZED)
    #Rows: 82  #Blks:  1  AvgRowLen:  100.00
Index Stats::
  Index: IND_T6_C2  Col#: 2    (NOT ANALYZED)
    LVLS: 1  #LB: 25  #DK: 100  LB/K: 1.00  DB/K: 1.00  CLUF: 800.00
***************************************

As I mentioned in the added section at the end of the blog article, 10.2.0.5 and 11.1.0.7 seem to be less negatively affected in this test case due to dynamic sampling. As shown above, 11.2.0.2 shows a CLUSTERING_FACTOR of 0 for the index, while 10.2.0.5 shows a CLUSTING_FACTOR of 800. The other index statistics on 11.2.0.2 are also displayed as 0, while that is not the case on 10.2.0.5.

After statistics collection on 11.2.0.2:

***********************
Table Stats::
  Table: T6  Alias: T6
    #Rows: 100000  #Blks:  4528  AvgRowLen:  310.00  ChainCnt:  0.00
Index Stats::
  Index: IND_T6_C2  Col#: 2
    LVLS: 1  #LB: 198  #DK: 80001  LB/K: 1.00  DB/K: 1.00  CLUF: 9052.00
Access path analysis for T6
***************************************

After statistics collection on 10.2.0.5:

***************************************
BASE STATISTICAL INFORMATION
***********************
Table Stats::
  Table: T6  Alias: T6
    #Rows: 100000  #Blks:  4528  AvgRowLen:  310.00
Index Stats::
  Index: IND_T6_C2  Col#: 2
    LVLS: 1  #LB: 198  #DK: 80001  LB/K: 1.00  DB/K: 1.00  CLUF: 9052.00
***************************************

—

For completeness, this is the dynamic sampling section from the 10.2.0.5 10053 trace file:

** Performing dynamic sampling initial checks. **
  Column (#2): C2(NUMBER)  NO STATISTICS (using defaults)
    AvgLen: 13.00 NDV: 3 Nulls: 0 Density: 0.39024
** Dynamic sampling initial checks returning TRUE (level = 2).
** Dynamic sampling updated index stats.: IND_T6_C2, blocks=244
** Dynamic sampling index access candidate : IND_T6_C2
** Dynamic sampling updated table stats.: blocks=4528
*** 2012-02-14 18:19:16.531
** Generated dynamic sampling query:
    query text : 
SELECT /* OPT_DYN_SAMP */ /*+ ALL_ROWS IGNORE_WHERE_CLAUSE NO_PARALLEL(SAMPLESUB) opt_param('parallel_execution_enabled', 'false') NO_PARALLEL_INDEX(SAMPLESUB) NO_SQL_TUNE */ NVL(SUM(C1),0), NVL(SUM(C2),0) FROM (SELECT /*+ IGNORE_WHERE_CLAUSE NO_PARALLEL("T6") FULL("T6") NO_PARALLEL_INDEX("T6") */ 1 AS C1, CASE WHEN "T6"."C2"=:B1 THEN 1 ELSE 0 END AS C2 FROM "T6" SAMPLE BLOCK (1.391343 , 1) SEED (1) "T6") SAMPLESUB
=====================
PARSING IN CURSOR #19 len=418 dep=1 uid=164 oct=3 lid=164 tim=368717503 hv=4142090939 ad='fc89f0a0'
SELECT /* OPT_DYN_SAMP */ /*+ ALL_ROWS IGNORE_WHERE_CLAUSE NO_PARALLEL(SAMPLESUB) opt_param('parallel_execution_enabled', 'false') NO_PARALLEL_INDEX(SAMPLESUB) NO_SQL_TUNE */ NVL(SUM(C1),0), NVL(SUM(C2),0) FROM (SELECT /*+ IGNORE_WHERE_CLAUSE NO_PARALLEL("T6") FULL("T6") NO_PARALLEL_INDEX("T6") */ 1 AS C1, CASE WHEN "T6"."C2"=:B1 THEN 1 ELSE 0 END AS C2 FROM "T6" SAMPLE BLOCK (1.391343 , 1) SEED (1) "T6") SAMPLESUB
END OF STMT
PARSE #19:c=0,e=340,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=1,tim=368717502
EXEC #19:c=0,e=845,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=1,tim=368718399
FETCH #19:c=0,e=560,p=0,cr=73,cu=0,mis=0,r=1,dep=1,og=1,tim=368718979
*** 2012-02-14 18:19:16.533
** Executed dynamic sampling query:
    level : 2
    sample pct. : 1.391343
    actual sample size : 1438
    filtered sample card. : 286
    orig. card. : 82
    block cnt. table stat. : 4528
    block cnt. for sampling: 4528
    max. sample block cnt. : 64
    sample block cnt. : 63
    min. sel. est. : 0.01000000
STAT #19 id=1 cnt=1 pid=0 pos=1 obj=0 op='SORT AGGREGATE (cr=73 pr=0 pw=0 time=562 us)'
STAT #19 id=2 cnt=1438 pid=1 pos=1 obj=52702 op='TABLE ACCESS SAMPLE T6 (cr=73 pr=0 pw=0 time=33 us)'
** Using recursive dynamic sampling card. est. : 103353.396825
*** 2012-02-14 18:19:16.549
** Generated dynamic sampling query:
    query text : 
SELECT /* OPT_DYN_SAMP */ /*+ ALL_ROWS opt_param('parallel_execution_enabled', 'false') NO_PARALLEL(SAMPLESUB) NO_PARALLEL_INDEX(SAMPLESUB) NO_SQL_TUNE */ NVL(SUM(C1),0), NVL(SUM(C2),0), NVL(SUM(C3),0) FROM (SELECT /*+ NO_PARALLEL("T6") INDEX("T6" IND_T6_C2) NO_PARALLEL_INDEX("T6") */ 1 AS C1, 1 AS C2, 1 AS C3  FROM "T6" "T6" WHERE "T6"."C2"=:B1 AND ROWNUM <= 2500) SAMPLESUB
=====================
PARSING IN CURSOR #18 len=377 dep=1 uid=164 oct=3 lid=164 tim=368735909 hv=102564777 ad='fc89e868'
SELECT /* OPT_DYN_SAMP */ /*+ ALL_ROWS opt_param('parallel_execution_enabled', 'false') NO_PARALLEL(SAMPLESUB) NO_PARALLEL_INDEX(SAMPLESUB) NO_SQL_TUNE */ NVL(SUM(C1),0), NVL(SUM(C2),0), NVL(SUM(C3),0) FROM (SELECT /*+ NO_PARALLEL("T6") INDEX("T6" IND_T6_C2) NO_PARALLEL_INDEX("T6") */ 1 AS C1, 1 AS C2, 1 AS C3  FROM "T6" "T6" WHERE "T6"."C2"=:B1 AND ROWNUM <= 2500) SAMPLESUB
END OF STMT
PARSE #18:c=0,e=273,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=1,tim=368735908
EXEC #18:c=0,e=548,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=1,tim=368736505
FETCH #18:c=0,e=794,p=0,cr=7,cu=0,mis=0,r=1,dep=1,og=1,tim=368737317
*** 2012-02-14 18:19:16.551
** Executed dynamic sampling query:
    level : 2
    sample pct. : 100.000000
    actual sample size : 103353
    filtered sample card. : 2500
    filtered sample card. (index IND_T6_C2): 2500
    orig. card. : 103353
    block cnt. table stat. : 4528
    block cnt. for sampling: 4528
    max. sample block cnt. : 4294967295
    sample block cnt. : 4528
    min. sel. est. : 0.01000000
** Increasing dynamic sampling selectivity
   for predicate 0 from 0.024189 to 0.198887.
** Increasing dynamic sampling selectivity
   for predicate 1 from 0.024189 to 0.198887.
    index IND_T6_C2 selectivity est.: 0.19888734
STAT #18 id=1 cnt=1 pid=0 pos=1 obj=0 op='SORT AGGREGATE (cr=7 pr=0 pw=0 time=797 us)'
STAT #18 id=2 cnt=2500 pid=1 pos=1 obj=0 op='VIEW  (cr=7 pr=0 pw=0 time=15 us)'
STAT #18 id=3 cnt=2500 pid=2 pos=1 obj=0 op='COUNT STOPKEY (cr=7 pr=0 pw=0 time=15 us)'
STAT #18 id=4 cnt=2500 pid=3 pos=1 obj=52703 op='INDEX RANGE SCAN IND_T6_C2 (cr=7 pr=0 pw=0 time=14 us)'
** Using dynamic sampling card. : 103353
** Dynamic sampling updated table card.
** Using single table dynamic sel. est. : 0.19888734
  Table: T6  Alias: T6     
    Card: Original: 103353  Rounded: 20556  Computed: 20555.68  Non Adjusted: 20555.68
  -----------------------------------------
  END   Single Table Cardinality Estimation
  -----------------------------------------
  Access Path: TableScan
    Cost:  357.58  Resp: 357.58  Degree: 0
      Cost_io: 355.00  Cost_cpu: 54983730
      Resp_io: 355.00  Resp_cpu: 54983730
  Access Path: index (AllEqRange)
    Index: IND_T6_C2
    resc_io: 209.00  resc_cpu: 1673491
    ix_sel: 0.19889  ix_sel_with_filters: 0.19889
    Cost: 209.08  Resp: 209.08  Degree: 1
  Best:: AccessPath: IndexRange  Index: IND_T6_C2
         Cost: 209.08  Degree: 1  Resp: 209.08  Card: 20555.68  Bytes: 0

I just thought about this again, and the clustering factor of the index is 0 in this case, so according to the formula for index range scan costs the table access part will be calculated as 0… So probably not a bug, but simply applying the general arithmetic rules.

Randolf

> Then, just to be sure, I delete index statistics and re-run the test. But, to my surprise, the results did not change

I couldn’t reproduce this: When I delete the index stats I get an execution plan where the table access is costed. You still might end up with an index range scan since the optimizer doesn’t have a clue about the clustering factor of the index (this information is not determined by Dynamic Sampling), but the plan is definitely showing more realistic cost estimates and considers the table access.

So the optimizer seems to be confused by the existing index statistics and in this case simply omits the table access costs from the calculation, clearly a bug I think.

Reproduced on 11.2.0.2 and 11.2.0.3. Interestingly with index statistics deleted the table aceess is costed much higher when using 11.2.0.3 optimizer features which can lead to a plan change – and it did in my case switch to a full table scan whereas 11.2.0.2 still preferred the index range scan plan.

By the way: I believe the purpose of the additional query performed by Dynamic Sampling in case a suitable index is taking advantage of a very cheap way to get improved cardinality estimates for rare values. Therefore the query is hard-coded to be limited to 2,500 rows – if the query returns 2,500 rows, its result will be ignored. If it returns less than 2,500 rows then Oracle has a very precise cardinality / selectivity estimate by using the index. Without a suitable index the Dynamic Sampling code will refuse the result when the sample query returns 0 or only a few hits for the predicate assuming that the sample is not representative (too small sample size). Only with very high levels / sample block counts these results will not be rejected. Having an index in place therefore improves the Dynamic Sampling results when using (default) small samples.

Randolf

I added some additional information at the end of the blog article. The problem appears to be two-fold:
* The optimizer is not calculating the cost of the table access as part of the index access path.
* While the optimizer’s estimates are close, it is calculating a very small index access cost when dynamic sampling is used.

The second dynamic sampling query appears to be attempting to determine the number of NULL values, even though all of the columns are declared as NOT NULL:
SELECT /* OPT_DYN_SAMP */ /*+ ALL_ROWS opt_param(‘parallel_execution_enabled’, ‘false’) NO_PARALLEL(SAMPLESUB) NO_PARALLEL_INDEX(SAMPLESUB) NO_SQL_TUNE */ NVL(SUM(C1),0), NVL(SUM(C2),0), NVL(SUM(C3),0) FROM (SELECT /*+ NO_PARALLEL(“T6″) INDEX(“T6″ IND_T6_C2) NO_PARALLEL_INDEX(“T6″) */ 1 AS C1, 1 AS C2, 1 AS C3 FROM “TESTUSER”.”T6″ “T6″ WHERE “T6″.”C2″=:B1 AND ROWNUM <= 2500) SAMPLESUB

The full dynamic sampling section from my 11.2.0.2 (most recent) 10053 trace:

** Performing dynamic sampling initial checks. **
  Column (#2): C2(  NO STATISTICS (using defaults)
    AvgLen: 13 NDV: 3 Nulls: 0 Density: 0.390244
** Dynamic sampling initial checks returning TRUE (level = 2).
** Dynamic sampling updated index stats.: IND_T6_C2, blocks=244
** Dynamic sampling index access candidate : IND_T6_C2
** Dynamic sampling updated table stats.: blocks=4528

*** 2012-02-14 17:41:26.512
** Generated dynamic sampling query:
    query text : 
SELECT /* OPT_DYN_SAMP */ /*+ ALL_ROWS IGNORE_WHERE_CLAUSE NO_PARALLEL(SAMPLESUB) opt_param('parallel_execution_enabled', 'false') NO_PARALLEL_INDEX(SAMPLESUB) NO_SQL_TUNE */ NVL(SUM(C1),0), NVL(SUM(C2),0) FROM (SELECT /*+ IGNORE_WHERE_CLAUSE NO_PARALLEL("T6") FULL("T6") NO_PARALLEL_INDEX("T6") */ 1 AS C1, CASE WHEN "T6"."C2"=:B1 THEN 1 ELSE 0 END AS C2 FROM "TESTUSER"."T6" SAMPLE BLOCK (1.391343 , 1) SEED (1) "T6") SAMPLESUB
=====================
PARSING IN CURSOR #388723216 len=429 dep=1 uid=64 oct=3 lid=64 tim=189525484065 hv=2741378272 ad='3ead44e70' sqlid='2m4nm7fjqc770'
SELECT /* OPT_DYN_SAMP */ /*+ ALL_ROWS IGNORE_WHERE_CLAUSE NO_PARALLEL(SAMPLESUB) opt_param('parallel_execution_enabled', 'false') NO_PARALLEL_INDEX(SAMPLESUB) NO_SQL_TUNE */ NVL(SUM(C1),0), NVL(SUM(C2),0) FROM (SELECT /*+ IGNORE_WHERE_CLAUSE NO_PARALLEL("T6") FULL("T6") NO_PARALLEL_INDEX("T6") */ 1 AS C1, CASE WHEN "T6"."C2"=:B1 THEN 1 ELSE 0 END AS C2 FROM "TESTUSER"."T6" SAMPLE BLOCK (1.391343 , 1) SEED (1) "T6") SAMPLESUB
END OF STMT
PARSE #388723216:c=0,e=421,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=1,plh=0,tim=189525484064
EXEC #388723216:c=0,e=712,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=1,plh=2403212413,tim=189525484863
FETCH #388723216:c=0,e=476,p=0,cr=66,cu=0,mis=0,r=1,dep=1,og=1,plh=2403212413,tim=189525485360
STAT #388723216 id=1 cnt=1 pid=0 pos=1 obj=0 op='SORT AGGREGATE (cr=66 pr=0 pw=0 time=475 us)'
STAT #388723216 id=2 cnt=1282 pid=1 pos=1 obj=102954 op='TABLE ACCESS SAMPLE T6 (cr=66 pr=0 pw=0 time=612 us cost=2 size=25 card=1)'

*** 2012-02-14 17:41:26.512
** Executed dynamic sampling query:
    level : 2
    sample pct. : 1.391343
    actual sample size : 1282
    filtered sample card. : 256
    orig. card. : 82
    block cnt. table stat. : 4528
    block cnt. for sampling: 4528
    max. sample block cnt. : 64
    sample block cnt. : 63
    min. sel. est. : 0.01000000
CLOSE #388723216:c=0,e=8,dep=1,type=0,tim=189525485505
** Using recursive dynamic sampling card. est. : 92141.206349

*** 2012-02-14 17:41:26.512
** Generated dynamic sampling query:
    query text : 
SELECT /* OPT_DYN_SAMP */ /*+ ALL_ROWS opt_param('parallel_execution_enabled', 'false') NO_PARALLEL(SAMPLESUB) NO_PARALLEL_INDEX(SAMPLESUB) NO_SQL_TUNE */ NVL(SUM(C1),0), NVL(SUM(C2),0), NVL(SUM(C3),0) FROM (SELECT /*+ NO_PARALLEL("T6") INDEX("T6" IND_T6_C2) NO_PARALLEL_INDEX("T6") */ 1 AS C1, 1 AS C2, 1 AS C3  FROM "TESTUSER"."T6" "T6" WHERE "T6"."C2"=:B1 AND ROWNUM <= 2500) SAMPLESUB
=====================
PARSING IN CURSOR #388723216 len=388 dep=1 uid=64 oct=3 lid=64 tim=189525485910 hv=1703431641 ad='3ed6b8ed0' sqlid='5c3hsnpkshmft'
SELECT /* OPT_DYN_SAMP */ /*+ ALL_ROWS opt_param('parallel_execution_enabled', 'false') NO_PARALLEL(SAMPLESUB) NO_PARALLEL_INDEX(SAMPLESUB) NO_SQL_TUNE */ NVL(SUM(C1),0), NVL(SUM(C2),0), NVL(SUM(C3),0) FROM (SELECT /*+ NO_PARALLEL("T6") INDEX("T6" IND_T6_C2) NO_PARALLEL_INDEX("T6") */ 1 AS C1, 1 AS C2, 1 AS C3  FROM "TESTUSER"."T6" "T6" WHERE "T6"."C2"=:B1 AND ROWNUM <= 2500) SAMPLESUB
END OF STMT
PARSE #388723216:c=0,e=340,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=1,plh=0,tim=189525485909
EXEC #388723216:c=0,e=714,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=1,plh=3369105306,tim=189525486686
FETCH #388723216:c=0,e=777,p=0,cr=7,cu=0,mis=0,r=1,dep=1,og=1,plh=3369105306,tim=189525487482
STAT #388723216 id=1 cnt=1 pid=0 pos=1 obj=0 op='SORT AGGREGATE (cr=7 pr=0 pw=0 time=781 us)'
STAT #388723216 id=2 cnt=2500 pid=1 pos=1 obj=0 op='VIEW  (cr=7 pr=0 pw=0 time=517 us cost=1 size=9 card=1)'
STAT #388723216 id=3 cnt=2500 pid=2 pos=1 obj=0 op='COUNT STOPKEY (cr=7 pr=0 pw=0 time=516 us)'
STAT #388723216 id=4 cnt=2500 pid=3 pos=1 obj=102955 op='INDEX RANGE SCAN IND_T6_C2 (cr=7 pr=0 pw=0 time=390 us cost=1 size=13 card=1)'

*** 2012-02-14 17:41:26.512
** Executed dynamic sampling query:
    level : 2
    sample pct. : 100.000000
    actual sample size : 92141
    filtered sample card. : 2500
    filtered sample card. (index IND_T6_C2): 2500
    orig. card. : 92141
    block cnt. table stat. : 4528
    block cnt. for sampling: 4528
    max. sample block cnt. : 4294967295
    sample block cnt. : 4528
    min. sel. est. : 0.01000000
** Increasing dynamic sampling selectivity
   for predicate 0 from 0.027132 to 0.199688.
** Increasing dynamic sampling selectivity
   for predicate 1 from 0.027132 to 0.199688.
    index IND_T6_C2 selectivity est.: 0.19968799
CLOSE #388723216:c=0,e=7,dep=1,type=0,tim=189525487659
** Using dynamic sampling card. : 92141
** Dynamic sampling updated table card.
** Using single table dynamic sel. est. : 0.19968799
  Table: T6  Alias: T6
    Card: Original: 92141.206349  Rounded: 18399  Computed: 18399.49  Non Adjusted: 18399.49
  Access Path: TableScan
    Cost:  1579.31  Resp: 1579.31  Degree: 0
      Cost_io: 1511.00  Cost_cpu: 52517081
      Resp_io: 1511.00  Resp_cpu: 52517081
  Access Path: index (AllEqRange)
    Index: IND_T6_C2
    resc_io: 49.00  resc_cpu: 349151
    ix_sel: 0.199688  ix_sel_with_filters: 0.199688 
    Cost: 49.45  Resp: 49.45  Degree: 1
  Best:: AccessPath: IndexRange
  Index: IND_T6_C2
         Cost: 49.45  Degree: 1  Resp: 49.45  Card: 18399.49  Bytes: 0

I am still trying to work through the above information.
The second STAT line for the first dynamic sampling query begins like this:

STAT #388723216 id=2 cnt=1282

That probably explains this entry:

actual sample size : 1282

In the lines at the start of the dynamic sampling section is this entry:

** Dynamic sampling updated table stats.: blocks=4528

It appears that the above is carried through to these entries:

block cnt. table stat. : 4528
block cnt. for sampling: 4528

It is getting late here (and I am not making too much sense out of this 10053 trace), and I am having a bit of difficulty seeing where the 256 number (filtered sample card. : 256) is obtained, but:
256 / 1282 = 0.19968799
That is the same index selectivity that appears later:

index IND_T6_C2 selectivity est.: 0.19968799