Can you give your comments on these questions:
Certainly –
1) It is easy to build models to discover the answers to all four questions – and the experience will help you practice your skills at identifying, analysing and solving problems.
2) This isn’t a forum – it’s a blog. I don’t answer readers’ questions unless they happen to raise interesting points that are specifically related to the blog note that they’ve been attached to.
3) If you want to make a special point of irritating me when you ask a question, make sure you don’t bother to get my name right.

We have a Datawarehouse environment and are running incremental ETL’s as well as Reports from the same. We know that this is not an ideal thing to do and will move to separate reporting environments in future. I have couple of questions, which came up again and again as developers are complaining of the locking issues which are due to reports and etl at the same time. Can you give your comments on these questions:

1) If a query is running and it access a table and at the same point a refresh job tries to truncate the same table will the truncate job wait till the query completes ?

2) If a query is running and it access a table and at the same point a refresh job tries to drop an index that is used in the explain plan by the will the drop index job wait till the query completes ?

3) If a query is running and it access a table and at the same point a refresh job tries to create an index on the same table that query is accessing will the create index statement wait till the query completes ?

4) If a query is running and it access a table and at the same point a refresh job tries to recreate an index that is used n the explain plan by the query will the create index statement wait till the query completes ?

Thanks,
Gary

yes I do realize that Arul mentioned system stats (sreadtim, mreadtim, cpuspeed, etc.). I’ve just focused on incorrectly reported cardinality as a self-contained problem (sorry if that distracts from your original points).

By the way – looks like the index cardinality also depends on how stats were collected in term of histograms…

SQL> begin
  2   dbms_stats.gather_table_stats(
  3    ownname => user,
  4    tabname => 't1',
  5    method_opt => 'for all columns size 1',
  6    cascade => true
  7   );
  8  end;
  9  /

PL/SQL procedure successfully completed.

SQL> select /*+ first_rows */ padding
 2   from t1
 3   where n1 = 2
 4    and ind_pad = rpad('x',40,'x')
 5    and n2 = 2;

xecution Plan
---------------------------------------------------------
lan hash value: 1429545322

------------------------------------------------------------------------------------
 Id  | Operation                   | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------
   0 | SELECT STATEMENT            |       |    10 |  2470 |   168   (0)| 00:00:03 |
   1 |  TABLE ACCESS BY INDEX ROWID| T1    |    10 |  2470 |   168   (0)| 00:00:03 |
*  2 |   INDEX RANGE SCAN          | T1_I1 |   200 |       |    25   (0)| 00:00:01 |
------------------------------------------------------------------------------------

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

  2 - access("N1"=2 AND "IND_PAD"='xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
              AND "N2"=2)

SQL> begin
  2   dbms_stats.gather_table_stats(
  3    ownname => user,
  4    tabname => 't1',
  5    method_opt => 'for all columns size 254',
  6    cascade => true
  7   );
  8  end;
  9  /

PL/SQL procedure successfully completed.

SQL> select /*+ first_rows */ padding
  2   from t1
  3   where n1 = 2
  4    and ind_pad = rpad('x',40,'x')
  5    and n2 = 2;

Execution Plan
----------------------------------------------------------
Plan hash value: 1429545322

-------------------------------------------------------------------------------------
| Id  | Operation                   | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |       |    10 |  2470 |    12   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| T1    |    10 |  2470 |    12   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN          | T1_I1 |    10 |       |     4   (0)| 00:00:01 |
-------------------------------------------------------------------------------------

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

   2 - access("N1"=2 AND "IND_PAD"='xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
               AND "N2"=2)

picking up the relative section from the 10053 trace:

Access Path: index (AllEqRange)
    Index: T1_I1
    resc_io: 168.00  resc_cpu: 1278402
    ix_sel: 0.05  ix_sel_with_filters: 0.05
    Cost: 168.08  Resp: 168.08  Degree: 1

Access Path: index (AllEqRange)
    Index: T1_I1
    resc_io: 12.00  resc_cpu: 89557
    ix_sel: 0.0024997  ix_sel_with_filters: 0.0024997
    Cost: 12.01  Resp: 12.01  Degree: 1

Alex, I believe Arul was thinking of the statistics created by calls to dbms_stats.gather_system_stats() – i.e. the CPU speed, and disk I/O speeds.

DJ/Alex: the question of dynamic sampling does depend on which problem you are trying to solve. The fact that you can get 10g to calculate the correct table selectivity by dynamic sampling isn’t (necessarily) an advantage in this case.

The point I was making was that after an upgrade there was a reason why some of your execution plans could change. As a consequence of the incomplete treatment, though, the new cost and cardinality are not self-consistent. Making 10g work out the correct cardinality isn’t necessarily going to get you back to the 9i execution plan – because now the optimizer has two reasons for doing something different.

Arul, in fact the problem is in the _presence_ of statistics (for _this specific_ example) and default optimizer_dynamic_sampling (which is 2).

Dynamic sampling at level 2 _without_ stats picks cardinality quite right:

SQL> select
  2   padding
  3  from
  4   t1
  5  where
  6   n1 = 2
  7  and ind_pad = rpad('x',40,'x')
  8  and n2 = 2
  9  ;

Execution Plan
----------------------------------------------------------
Plan hash value: 3617692013

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |   200 | 30000 |    33   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| T1   |   200 | 30000 |    33   (0)| 00:00:01 |
--------------------------------------------------------------------------

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

   1 - filter("N1"=2 AND "IND_PAD"='xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
              xxxx' AND "N2"=2)

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

“Is this a case of correlated columns? Would dynamic sampling help?”

With stats and dynamic sampling at level 4 the reporting cardinality were 188 (much better than 10 but still a little incorrect). The correct cardinality (200) were reported only at level 7.

P.S. 10.2.0.3