dbms_stats.gather_table_stats gererates two full scans, why?
Hi,
We are trying to help a customer facing IO issue and non homogeneous performance results between some of its environments and for this we made a testcase using stats gathering for a single, large table. This is an eBS R12 customer running 11gR2 11.2.0.3.
We are seeing a behavior with dbms_stats that we do not see documented or leave us with a good explanation.
The table is 2M rows and get 310 columns, is not partitioned. The scan takes around 2 hours.
Looking at the AWR reports that the customer pulled when the stats were gathered on two environments:
- On the DEV environment, copy of the production, the FND_STATS => DBMS_STATS command generate a SELECT statement SELECT /*+ parallel ... */ COUNT(*), COUNT('.. ) FROM table sample (30) which includes 165 columns
We are trying to help a customer facing IO issue and non homogeneous performance results between some of its environments and for this we made a testcase using stats gathering for a single, large table. This is an eBS R12 customer running 11gR2 11.2.0.3.
We are seeing a behavior with dbms_stats that we do not see documented or leave us with a good explanation.
The table is 2M rows and get 310 columns, is not partitioned. The scan takes around 2 hours.
Looking at the AWR reports that the customer pulled when the stats were gathered on two environments:
- On the DEV environment, copy of the production, the FND_STATS => DBMS_STATS command generate a SELECT statement SELECT /*+ parallel ... */ COUNT(*), COUNT('.. ) FROM table sample (30) which includes 165 columns
0