Using Index Vs dbms_stats.gather_table_stats

Hello All,
I would like to know in what situation would we benefit from using index and not analyse table as it takes time and in what situation analysing table is more beneficial then indexes.
I have a task which creates 14 tables CATS, 2nd table is depended on 1st table for eg create table as t2 as select * from t1 so on and so forth. I am indexing all the 14 tables and gathering statistics.. my colleague says that if tables are indexed then gathering statistics is not required. So table1 - table14 need not have gather statistics. This module is used for large volume of data extract.
My task is like
1. create table t1 as select * from <table_name>
create index
gather_table_stats
2. create table t2 as select * from t1
create index
gather_table_stats
3. create table t3 as select * from t2
create index
gather_table_stats
Regards,
Rashida

Rashida wrote:
Hello All,
I would like to know in what situation would we benefit from using index and not analyse table as it takes time and in what situation analysing table is more beneficial then indexes. You are comparing Apples and Oranges. They are different. They cant be compared.
ANALYSE is done on a table to collect statistics of the table. CBO needs this information to get the best execution plan. INDEX is a data structure like your table. They help you in searching your data in your table in a faster way.
For the optimizer to use your INDEX you need to have statistics of your TABLE and INDEX collected.
I have a task which creates 14 tables CATS, 2nd table is depended on 1st table for eg create table as t2 as select * from t1 so on and so forth. I am indexing all the 14 tables and gathering statistics.. my colleague says that if tables are indexed then gathering statistics is not required. That is a totally wrong statement. This only means your colleague does not know about both INDEX and Statistics. And also how CBO works.

Similar Messages

How Can I speed the progress of analyze/dbms_stats.GATHER_TABLE_STATS

When I analyze a table and its index or dbms_stats.GATHER_TABLE_STATS .The speed is very low,and I can not see the progress of it ? How can I speed it ? or how can I see the progress of it ? Thanks !!

v$session_longops is the table that contains information about long-running processes. You should be able to query that table to see how your analyze is going.
The easiest way to speed this sort of thing up is to have it do less work. If you're computing statistics, you may be able to use estimate statistics instead, depending on how homogenous your table is. If you're generating histograms for all the columns, you may be able to get away with fewer well-chosen histograms.
Justin
Distributed Database Consulting, Inc.
www.ddbcinc.com/askDDBC

Dbms_stats.gather_table_stats; What are the parameters you gurus use?

DB Version :10.2.0.1.0
Sometimes i want to collect the stats of just few tables. I use the following script to gather individual table stats. Are these parameters OK?
begin
dbms_stats.gather_table_stats(user, upper('table_name'), estimate_percent=>100,
no_invalidate=>false);
end;
/

Hi,
Check this links
[GATHER_TABLE_STATS Procedure|http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14258/d_stats.htm#i1036461]
[Using the DBMS_STATS-package|http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:735625536552]
[Analyze and DBMS_STATS|http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:4347359891525]
Regards,

How oracle decide whetehr to use index or full scan (statistics)

Hi Guys,
Let say i have a index on a column.
The table and index statistics has been gathered. (without histograms).
Let say i perform a select * from table where a=5;
Oracle will perform a full scan.
But from which statistics it will be able to know indeed most of the column = 5? (histograms not used)
After analyzing, we get the below:
Table Statistics :
(NUM_ROWS)
(BLOCKS)
(EMPTY_BLOCKS)
(AVG_SPACE)
(CHAIN_COUNT)
(AVG_ROW_LEN)
Index Statistics :
(BLEVEL)
(LEAF_BLOCKS)
(DISTINCT_KEYS)
(AVG_LEAF_BLOCKS_PER_KEY)
(AVG_DATA_BLOCKS_PER_KEY)
(CLUSTERING_FACTOR)
thanks
Index Column (A)
======
1
1
2
2
5
5
5
5
5
5

I have prepared some explanation and have not noticed that the topic has been marked as answered.
This my sentence is not completely true.
A column "without histograms" means that the column has only one bucket. More correct: even without histograms there are data in dba_tab_histograms which we can consider as one bucket for whole column. In fact these data are retrieved from hist_head$, not from histgrm$ as usual buckets.
Technically there is no any buckets without gathered histograms.
Let's create a table with skewed data distribution.
SQL> create table t as
2 select least(rownum,3) as val, '*' as pad
3    from dual
4 connect by level <= 1000000;
Table created
SQL> create index idx on t(val);
Index created
SQL> select val, count(*)
2    from t
3   group by val;
       VAL   COUNT(*)
         1          1
         2          1
         3     999998So, we have table with very skewed data distribution.
Let's gather statistics without histograms.
SQL> exec dbms_stats.gather_table_stats( user, 'T', estimate_percent => 100, method_opt => 'for all columns size 1', cascade => true);
PL/SQL procedure successfully completed
SQL> select blocks, num_rows from dba_tab_statistics
2   where table_name = 'T';
    BLOCKS   NUM_ROWS
      3106    1000000
SQL> select blevel, leaf_blocks, clustering_factor
2    from dba_ind_statistics t
3   where table_name = 'T'
4     and index_name = 'IDX';
    BLEVEL LEAF_BLOCKS CLUSTERING_FACTOR
         2        4017              3107
SQL> select column_name,
2         num_distinct,
3         density,
4         num_nulls,
5         low_value,
6         high_value
7    from dba_tab_col_statistics
8   where table_name = 'T'
9     and column_name = 'VAL';
COLUMN_NAME NUM_DISTINCT    DENSITY NUM_NULLS      LOW_VALUE      HIGH_VALUE
VAL                     3 0,33333333          0           C102            C104So, Oracle suggests that values between 1 and 3 (raw C102 and C104) are distributed uniform and the density of the distribution is 0.33.
Let's try to explain plan
SQL> explain plan for
2 select --+ no_cpu_costing
3         *
4    from t
5   where val = 1
6 ;
Explained
SQL> @plan
| Id | Operation         | Name | Rows | Cost |
|   0 | SELECT STATEMENT |      |   333K|   300 |
|* 1 | TABLE ACCESS FULL| T    |   333K|   300 |
Predicate Information (identified by operation id):
   1 - filter("VAL"=1)
Note
   - cpu costing is off (consider enabling it)Below is an excerpt from trace 10053
BASE STATISTICAL INFORMATION
Table Stats::
Table: T Alias: T
    #Rows: 1000000 #Blks: 3106 AvgRowLen: 5.00
Index Stats::
Index: IDX Col#: 1
    LVLS: 2 #LB: 4017 #DK: 3 LB/K: 1339.00 DB/K: 1035.00 CLUF: 3107.00
SINGLE TABLE ACCESS PATH
BEGIN Single Table Cardinality Estimation
Column (#1): VAL(NUMBER)
    AvgLen: 3.00 NDV: 3 Nulls: 0 Density: 0.33333 Min: 1 Max: 3
Table: T Alias: T
    Card: Original: 1000000 Rounded: 333333 Computed: 333333.33 Non Adjusted: 333333.33
END   Single Table Cardinality Estimation
Access Path: TableScan
    Cost: 300.00 Resp: 300.00 Degree: 0
      Cost_io: 300.00 Cost_cpu: 0
      Resp_io: 300.00 Resp_cpu: 0
Access Path: index (AllEqRange)
    Index: IDX
    resc_io: 2377.00 resc_cpu: 0
    ix_sel: 0.33333 ix_sel_with_filters: 0.33333
    Cost: 2377.00 Resp: 2377.00 Degree: 1
Best:: AccessPath: TableScan
         Cost: 300.00 Degree: 1 Resp: 300.00 Card: 333333.33 Bytes: 0Cost of FTS here is 300 and cost of Index Range Scan here is 2377.
I have disabled cpu costing, so selectivity does not affect the cost of FTS.
cost of Index Range Scan is calculated as
blevel + (leaf_blocks * selectivity + clustering_factor * selecivity) = 2 + (4017*0.33333 + 3107*0.33333) = 2377.
Oracle considers that it has to read 2 root/branch blocks of the index, 1339 leaf blocks of the index and 1036 blocks of the table.
Pay attention that selectivity is the major component of the cost of the Index Range Scan.
Let's try to gather histograms:
SQL> exec dbms_stats.gather_table_stats( user, 'T', estimate_percent => 100, method_opt => 'for columns val size 3', cascade => true);
PL/SQL procedure successfully completedIf you look at dba_tab_histograms you will see following
SQL> select endpoint_value,
2         endpoint_number
3    from dba_tab_histograms
4   where table_name = 'T'
5     and column_name = 'VAL'
6 ;
ENDPOINT_VALUE ENDPOINT_NUMBER
             1               1
             2               2
             3         1000000ENDPOINT_VALUE is the column value (in number for any type of data) and ENDPOINT_NUMBER is cumulative number of rows.
Number of rows for any ENDPOINT_VALUE = ENDPOINT_NUMBER for this ENDPOINT_VALUE - ENDPOINT_NUMBER for the previous ENDPOINT_VALUE.
explain plan and 10053 trace of the same query:
| Id | Operation                   | Name | Rows | Cost |
|   0 | SELECT STATEMENT            |      |     1 |     4 |
|   1 | TABLE ACCESS BY INDEX ROWID| T    |     1 |     4 |
|* 2 |   INDEX RANGE SCAN          | IDX |     1 |     3 |
Predicate Information (identified by operation id):
   2 - access("VAL"=1)
Note
   - cpu costing is off (consider enabling it)
BASE STATISTICAL INFORMATION
Table Stats::
Table: T Alias: T
    #Rows: 1000000 #Blks: 3106 AvgRowLen: 5.00
Index Stats::
Index: IDX Col#: 1
    LVLS: 2 #LB: 4017 #DK: 3 LB/K: 1339.00 DB/K: 1035.00 CLUF: 3107.00
SINGLE TABLE ACCESS PATH
BEGIN Single Table Cardinality Estimation
Column (#1): VAL(NUMBER)
    AvgLen: 3.00 NDV: 3 Nulls: 0 Density: 5.0000e-07 Min: 1 Max: 3
    Histogram: Freq #Bkts: 3 UncompBkts: 1000000 EndPtVals: 3
Table: T Alias: T
    Card: Original: 1000000 Rounded: 1 Computed: 1.00 Non Adjusted: 1.00
END   Single Table Cardinality Estimation
Access Path: TableScan
    Cost: 300.00 Resp: 300.00 Degree: 0
      Cost_io: 300.00 Cost_cpu: 0
      Resp_io: 300.00 Resp_cpu: 0
Access Path: index (AllEqRange)
    Index: IDX
    resc_io: 4.00 resc_cpu: 0
    ix_sel: 1.0000e-06 ix_sel_with_filters: 1.0000e-06
    Cost: 4.00 Resp: 4.00 Degree: 1
Best:: AccessPath: IndexRange Index: IDX
         Cost: 4.00 Degree: 1 Resp: 4.00 Card: 1.00 Bytes: 0Pay attention on selectivity, ix_sel: 1.0000e-06
Cost of the FTS is still the same = 300,
but cost of the Index Range Scan is 4 now: 2 root/branch blocks + 1 leaf block + 1 table block.
Thus, conclusion: histograms allows to calculate selectivity more accurate. The aim is to have more efficient execution plans.
Alexander Anokhin
http://alexanderanokhin.wordpress.com/

Query not using index when using 'or' clause

I have a problem with something I can't understand about indexes in Oracle 11g.
We can create test data with:
create table test2(field1 varchar2(100),field2 varchar2(100),field3 number,field4 varchar2(100));
create index test2_idx1 on test2(upper(field1));
create index test2_idx1b on test2(field1);
create index test2_idx2 on test2(field3);
DECLARE
j NUMBER :=1;
BEGIN
FOR i IN 1..500000
LOOP
INSERT
INTO test2
(field1,field2, field3, field4)
VALUES
('field1='||i,'a', j, 'i' );
IF (i mod 1000)=0 THEN
j := j+1;
END IF;
END LOOP;
COMMIT;
END;
EXEC DBMS_STATS.GATHER_TABLE_STATS ('system', 'test2');
Then I make some explain plans which result I can't understand
Query 1:
SELECT * FROM test2 WHERE field3=1;
Explain plan:
Explain plan for query 01
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1003 | 28084 | 10 (0)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| TEST2 | 1003 | 28084 | 10 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | TEST2_IDX2 | 1003 | | 5 (0)| 00:00:01 |
Everything OK here. Index is used.
Query 2:
SELECT * FROM test2 WHERE upper(field1)='FIELD1=1';
Explain plan
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 28 | 4 (0)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| TEST2 | 1 | 28 | 4 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | TEST2_IDX1 | 1 | | 3 (0)| 00:00:01 |
Everything OK again. Index is used.
Query 3:
SELECT /*+ USE_CONCAT */ * FROM test2 WHERE field1='FIELD1=1' OR field3=1;
Explain plan
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1004 | 28112 | 14 (0)| 00:00:01 |
| 1 | CONCATENATION | | | | | |
| 2 | TABLE ACCESS BY INDEX ROWID| TEST2 | 1 | 28 | 4 (0)| 00:00:01 |
|* 3 | INDEX RANGE SCAN | TEST2_IDX1B | 1 | | 3 (0)| 00:00:01 |
|* 4 | TABLE ACCESS BY INDEX ROWID| TEST2 | 1003 | 28084 | 10 (0)| 00:00:01 |
|* 5 | INDEX RANGE SCAN | TEST2_IDX2 | 1003 | | 5 (0)| 00:00:01 |
Indenxes are used in concatenation. No problem again.
Query 4:
SELECT /*+ USE_CONCAT */ * FROM test2 WHERE upper(field1)='FIELD1=1' OR field3=1;
Explain plan
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1004 | 28112 | 641 (4)| 00:00:08 |
| 1 | CONCATENATION | | | | | |
|* 2 | TABLE ACCESS FULL | TEST2 | 1 | 28 | 631 (4)| 00:00:08 |
|* 3 | TABLE ACCESS BY INDEX ROWID| TEST2 | 1003 | 28084 | 10 (0)| 00:00:01 |
|* 4 | INDEX RANGE SCAN | TEST2_IDX2 | 1003 | | 5 (0)| 00:00:01 |
Here my problem arises. Why is test2_idx1 not being used? Is it because it is a function index? Is there any workaround in this cases?
Thanks a lot in advance.

Interesting. A "workaround" which I thought first was:
SELECT /*+ USE_CONCAT */ * FROM test2 WHERE upper(field1)='FIELD1=1'
UNION ALL
SELECT /*+ USE_CONCAT */ * FROM test2 WHERE field3=1;
| Id | Operation                    | Name       | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT             |            | 1001 | 28042 |    15 (74)| 00:00:01 |
|   1 | UNION-ALL                   |            |       |       |            |          |
|   2 |   TABLE ACCESS BY INDEX ROWID| TEST2      |     1 |    42 |     4   (0)| 00:00:01 |
|* 3 |    INDEX RANGE SCAN          | TEST2_IDX1 |     1 |       |     3   (0)| 00:00:01 |
|   4 |   TABLE ACCESS BY INDEX ROWID| TEST2      | 1000 | 28000 |    11   (0)| 00:00:01 |
|* 5 |    INDEX RANGE SCAN          | TEST2_IDX2 | 1000 |       |     5   (0)| 00:00:01 |
-------------------------------------------------------------------------------------------   But I do not like using UNION for such tricks. So I thought, what would ORACLE do without hint?
SELECT * FROM test2 WHERE upper(field1)='FIELD1=1' or field3=1;
| Id | Operation                        | Name       | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT                 |            | 1001 | 42042 |   176   (0)| 00:00:03 |
|   1 | TABLE ACCESS BY INDEX ROWID     | TEST2      | 1001 | 42042 |   176   (0)| 00:00:03 |
|   2 |   BITMAP CONVERSION TO ROWIDS    |            |       |       |            |          |
|   3 |    BITMAP OR                     |            |       |       |            |          |
|   4 |     BITMAP CONVERSION FROM ROWIDS|            |       |       |            |          |
|* 5 |      INDEX RANGE SCAN            | TEST2_IDX2 |       |       |     5   (0)| 00:00:01 |
|   6 |     BITMAP CONVERSION FROM ROWIDS|            |       |       |            |          |
|* 7 |      INDEX RANGE SCAN            | TEST2_IDX1 |       |       |     3   (0)| 00:00:01 |
----------------------------------------------------------------------------------------------- Thist looks perfect to me. (Please ignore the "higher" cost on the second plan. On your real data, it should be faster. Is it?)

View with renamed column does not use index

Is there any reason why a view that renames the columns presented to the users would ignore an index?
For example:
CREATE OR REPLACE VIEW ENROLLMENT
(ENROLLMENT_ID, ENROLLMENT_DATE, FIRST_NAME)
AS
select distinct
a.col1 as enrollment_id,
a.col2 as enrollment_date,
a.col3 as first_name
from t1 a
When a user queries the view, with a WHERE FIRST_NAME = 'TOM", it results in a FTS. However, if you run the query against the base table (using col1, col2, and col3), it uses the index against t1 on (col3, col2, col1).

Well, I tried to create the supporting evidence afterwards (sigh, why do I keep doing that ...), it seems that Oracle has addressed this problem already:
SQL> create table t1
2 as
3 select l col1, sysdate - l/86400 col2, decode(l,1,'TOM',to_char(l)) col3
4    from (select level l from dual connect by level <= 100000)
5 /
Tabel is aangemaakt.
SQL> create index i1 on t1 (col3, col2, col1)
2 /
Index is aangemaakt.
SQL> exec dbms_stats.gather_table_stats(user,'T1',method_opt=>'FOR ALL INDEXED COLUMNS')
PL/SQL-procedure is geslaagd.
SQL> create view enrollment
2 (enrollment_id, enrollment_date, first_name)
3 as
4 select distinct
5 a.col1 as enrollment_id,
6 a.col2 as enrollment_date,
7 a.col3 as first_name
8 from t1 a
9 /
View is aangemaakt.
SQL> set autotrace on explain
SQL> select * from enrollment where first_name = 'TOM'
2 /
                         ENROLLMENT_ID ENROLLMENT_DATE     FIRST_NAME
                                     1 16-01-2007 14:41:25 TOM
1 rij is geselecteerd.
Uitvoeringspan
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=3 Card=1 Bytes=44)
   1    0   VIEW OF 'ENROLLMENT' (Cost=3 Card=1 Bytes=44)
   2    1     SORT (UNIQUE NOSORT) (Cost=3 Card=1 Bytes=18)
   3    2       INDEX (RANGE SCAN) OF 'I1' (NON-UNIQUE) (Cost=3 Card=1
           Bytes=18)I'm on 9.2.0.7.0 here, what's your version ?
Regards,
Rob.

Slow Query Using index. Fast with full table Scan.

Hi;
(Thanks for the links)
Here's my question correctly formated.
The query:
SELECT count(1)
from ehgeoconstru ec
where ec.TYPE='BAR'
AND ( ec.birthDate <= TO_DATE('2009-10-06 11:52:12', 'YYYY-MM-DD HH24:MI:SS') )
and deathdate is null
and substr(ec.strgfd, 1, length('[CIMText')) <> '[CIMText'Runs on 32 seconds!
Same query, but with one extra where clause:
SELECT count(1)
from ehgeoconstru ec
where ec.TYPE='BAR'
and ( (ec.contextVersion = 'REALWORLD')     --- ADDED HERE
AND ( ec.birthDate <= TO_DATE('2009-10-06 11:52:12', 'YYYY-MM-DD HH24:MI:SS') ) )
and deathdate is null
and substr(ec.strgfd, 1, length('[CIMText')) <> '[CIMText'This runs in 400 seconds.
It should return data from one table, given the conditions.
The version of the database is Oracle9i Release 9.2.0.7.0
These are the parameters relevant to the optimizer:
SQL> show parameter optimizer
NAME                                 TYPE        VALUE
optimizer_dynamic_sampling           integer     1
optimizer_features_enable            string      9.2.0
optimizer_index_caching              integer     99
optimizer_index_cost_adj             integer     10
optimizer_max_permutations           integer     2000
optimizer_mode                       string      CHOOSE
SQL> Here is the output of EXPLAIN PLAN for the first fast query:
PLAN_TABLE_OUTPUT
| Id | Operation                     | Name               | Rows | Bytes | Cost |
|   0 | SELECT STATEMENT     |                         |           |       |       |
|   1 | SORT AGGREGATE       |                         |           |       |       |
|* 2 |   TABLE ACCESS FULL   | EHCONS            |       |       |       |
Predicate Information (identified by operation id):
PLAN_TABLE_OUTPUT
   2 - filter(SUBSTR("EC"."strgfd",1,8)<>'[CIMText' AND "EC"."DEATHDATE"
              IS NULL AND "EC"."BIRTHDATE"<=TO_DATE('2009-10-06 11:52:12', 'yyyy
-mm-dd
              hh24:mi:ss') AND "EC"."TYPE"='BAR')
Note: rule based optimizationHere is the output of EXPLAIN PLAN for the slow query:
PLAN_TABLE_OUTPUT
   |       |
|   1 | SORT AGGREGATE              |                             |       |
   |       |
|* 2 |   TABLE ACCESS BY INDEX ROWID| ehgeoconstru      |       |
   |       |
|* 3 |    INDEX RANGE SCAN          | ehgeoconstru_VSN |       |
   |       |
PLAN_TABLE_OUTPUT
Predicate Information (identified by operation id):
2 - filter(SUBSTR("EC"."strgfd",1,8)<>'[CIMText' AND "EC"."DEATHDATE" IS
NULL AND "EC"."TYPE"='BAR')
PLAN_TABLE_OUTPUT
   3 - access("EC"."CONTEXTVERSION"='REALWORLD' AND "EC"."BIRTHDATE"<=TO_DATE('2
009-10-06
              11:52:12', 'yyyy-mm-dd hh24:mi:ss'))
       filter("EC"."BIRTHDATE"<=TO_DATE('2009-10-06 11:52:12', 'yyyy-mm-dd hh24:
mi:ss'))
Note: rule based optimizationThe TKPROF output for this slow statement is:
TKPROF: Release 9.2.0.7.0 - Production on Tue Nov 17 14:46:32 2009
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
Trace file: gen_ora_3120.trc
Sort options: prsela exeela fchela
count    = number of times OCI procedure was executed
cpu      = cpu time in seconds executing
elapsed = elapsed time in seconds executing
disk     = number of physical reads of buffers from disk
query    = number of buffers gotten for consistent read
current = number of buffers gotten in current mode (usually for update)
rows     = number of rows processed by the fetch or execute call
SELECT count(1)
from ehgeoconstru ec
where ec.TYPE='BAR'
and ( (ec.contextVersion = 'REALWORLD')
AND ( ec.birthDate <= TO_DATE('2009-10-06 11:52:12', 'YYYY-MM-DD HH24:MI:SS') ) )
and deathdate is null
and substr(ec.strgfd, 1, length('[CIMText')) <> '[CIMText'
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        2      0.00     538.12     162221    1355323          0           1
total        4      0.00     538.12     162221    1355323          0           1
Misses in library cache during parse: 0
Optimizer goal: CHOOSE
Parsing user id: 153
Rows     Row Source Operation
      1 SORT AGGREGATE
27747   TABLE ACCESS BY INDEX ROWID OBJ#(73959)
2134955    INDEX RANGE SCAN OBJ#(73962) (object id 73962)
alter session set sql_trace=true
call     count       cpu    elapsed       disk      query    current        rows
Parse        0      0.00       0.00          0          0          0           0
Execute      1      0.00       0.02          0          0          0           0
Fetch        0      0.00       0.00          0          0          0           0
total        1      0.00       0.02          0          0          0           0
Misses in library cache during parse: 0
Misses in library cache during execute: 1
Optimizer goal: CHOOSE
Parsing user id: 153
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      2      0.00       0.02          0          0          0           0
Fetch        2      0.00     538.12     162221    1355323          0           1
total        5      0.00     538.15     162221    1355323          0           1
Misses in library cache during parse: 0
Misses in library cache during execute: 1
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call     count       cpu    elapsed       disk      query    current        rows
Parse        0      0.00       0.00          0          0          0           0
Execute      0      0.00       0.00          0          0          0           0
Fetch        0      0.00       0.00          0          0          0           0
total        0      0.00       0.00          0          0          0           0
Misses in library cache during parse: 0
    2 user SQL statements in session.
    0 internal SQL statements in session.
    2 SQL statements in session.
Trace file: gen_ora_3120.trc
Trace file compatibility: 9.02.00
Sort options: prsela exeela fchela
       2 sessions in tracefile.
       2 user SQL statements in trace file.
       0 internal SQL statements in trace file.
       2 SQL statements in trace file.
       2 unique SQL statements in trace file.
      94 lines in trace file.Edited by: PauloSMO on 17/Nov/2009 4:21
Edited by: PauloSMO on 17/Nov/2009 7:07
Edited by: PauloSMO on 17/Nov/2009 7:38 - Changed title to be more correct.

Although your optimizer_mode is choose, it appears that there are no statistics gathered on ehgeoconstru. The lack of cost estimate and estimated row counts from each step of the plan, and the "Note: rule based optimization" at the end of both plans would tend to confirm this.
Optimizer_mode choose means that if statistics are gathered then it will use the CBO, but if no statistics are present in any of the tables in the query, then the Rule Based Optimizer will be used. The RBO tends to be index happy at the best of times. I'm guessing that the index ehgeoconstru_VSN has contextversion as the leading column and also includes birthdate.
You can either gather statistics on the table (if all of the other tables have statistics) using dbms_stats.gather_table_stats, or hint the query to use a full scan instead of the index. Another alternative would be to apply a function or operation against the contextversion to preclude the use of the index. something like this:
SELECT COUNT(*)
FROM ehgeoconstru ec
WHERE ec.type='BAR' and
      ec.contextVersion||'' = 'REALWORLD'
      ec.birthDate <= TO_DATE('2009-10-06 11:52:12', 'YYYY-MM-DD HH24:MI:SS') and
      deathdate is null and
      SUBSTR(ec.strgfd, 1, LENGTH('[CIMText')) <> '[CIMText'or perhaps UPPER(ec.contextVersion) if that would not change the rows returned.
John

Optimizer not using indexes

DBAs,
I have a select query which is using index scan when quired in prod. database and is executing in 20secs.and is using full table scan in non prod. db and is taking 48 secs.I rebuilded indexes & took stats in non-prod db but even it is taking 47 secs.
Please advice......

Here are the details
EXECUTE DBMS_STATS.GATHER_SCHEMA_STATS( -ownname => 'TCD_PRD_STG', -
estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, -
method_opt => 'for all columns size AUTO' -
SQL> EXECUTE DBMS_STATS.GATHER_SCHEMA_STATS (‘JOE’,’EMPLOYEE’);
EXECUTE DBMS_STATS.GATHER_SCHEMA_STATS('TCD_PRD_STG',DBMS_STATS.AUTO_SAMPLE_SIZE);
1)Oracle versions are 10.2.0.2 in both prod & non-prod.
2)Explain plan of prod. db
SQL> SELECT ITEM_REFERENCE_ID FROM (SELECT DISTINCT * FROM ITEMS WHERE PUBLICATION_ID=20 AND ITEM_T
YPE=16 AND ( ( ( SCHEMA_ID=31 ) ) AND ( ( (ITEM_REFERENCE_ID IN (SELECT ITEM_REFERENCE_ID FROM
( SELECT ITEM_REFERENCE_ID, COUNT(KEYWORD) AS tempkeywordcount FROM ITEM_CATEGORIES_AND_KEYWORDS WHE
RE KEYWORD IN ('Africa') AND CATEGORY = 'Region' AND PUBLICATION_ID=20 GROUP BY ITEM_REFERENCE_ID) t
empselectholder WHERE tempkeywordcount=1)) OR (ITEM_REFERENCE_ID IN (SELECT ITEM_REFERENCE_ID FROM (
SELECT ITEM_REFERENCE_ID, COUNT(KEYWORD) AS tempkeywordcount FROM ITEM_CATEGORIES_AND_KEYWORDS WHER
E KEYWORD IN ('Aig') AND CATEGORY = 'Region' AND PUBLICATION_ID=20 GROUP BY ITEM_REFERENCE_ID) temps
electholder WHERE tempkeywordcount=1)) ) ) ) ORDER BY LAST_PUBLISHED_DATE DESC) WHERE ROWNUM<51;
no rows selected
Elapsed: 00:00:21.74
Execution Plan
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=192 Card=50 Bytes=
650)
1 0 COUNT (STOPKEY)
2 1 VIEW (Cost=192 Card=79 Bytes=1027)
3 2 SORT (ORDER BY STOPKEY) (Cost=192 Card=79 Bytes=92272)
4 3 HASH (UNIQUE) (Cost=191 Card=79 Bytes=92272)
5 4 FILTER
6 5 TABLE ACCESS (BY INDEX ROWID) OF 'ITEMS' (TABLE)
(Cost=190 Card=808 Bytes=943744)
7 6 INDEX (RANGE SCAN) OF 'IDX_ITEMS_PUB_URL' (IND
EX) (Cost=107 Card=17024)
8 5 FILTER
9 8 HASH (GROUP BY) (Cost=42 Card=1 Bytes=540)
10 9 TABLE ACCESS (BY INDEX ROWID) OF 'ITEM_CATEG
ORIES_AND_KEYWORDS' (TABLE) (Cost=41 Card=1 Bytes=540)
11 10 INDEX (RANGE SCAN) OF 'IX_ITEM_KEYWORDS' (
INDEX) (Cost=35 Card=7403)
12 5 FILTER
13 12 HASH (GROUP BY) (Cost=3 Card=1 Bytes=540)
14 13 TABLE ACCESS (BY INDEX ROWID) OF 'ITEM_CATEG
ORIES_AND_KEYWORDS' (TABLE) (Cost=2 Card=1 Bytes=540)
15 14 INDEX (RANGE SCAN) OF 'IX_ITEM_KEYWORDS' (
INDEX) (Cost=1 Card=50)
Statistics
21 recursive calls
0 db block gets
4950582 consistent gets
4060 physical reads
13100 redo size
240 bytes sent via SQL*Net to client
333 bytes received via SQL*Net from client
1 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
0 rows processed
explain plan of non-prod db
1* SELECT ITEM_REFERENCE_ID FROM (SELECT DISTINCT * FROM ITEMS WHERE PUBLICATION_ID=20 AND ITEM_T
SQL> /
ITEM_REFERENCE_ID
96672
96680
Elapsed: 00:00:47.74
Execution Plan
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=502 Card=50 Bytes=
650)
1 0 COUNT (STOPKEY)
2 1 VIEW (Cost=502 Card=255 Bytes=3315)
3 2 SORT (ORDER BY STOPKEY) (Cost=502 Card=255 Bytes=40035
4 3 HASH (UNIQUE) (Cost=501 Card=255 Bytes=40035)
5 4 FILTER
6 5 TABLE ACCESS (FULL) OF 'ITEMS' (TABLE) (Cost=500
Card=2618 Bytes=411026)
7 5 FILTER
8 7 HASH (GROUP BY) (Cost=881 Card=1 Bytes=29)
9 8 TABLE ACCESS (FULL) OF 'ITEM_CATEGORIES_AND_
KEYWORDS' (TABLE) (Cost=880 Card=11 Bytes=319)
10 5 FILTER
11 10 HASH (GROUP BY) (Cost=881 Card=1 Bytes=29)
12 11 TABLE ACCESS (FULL) OF 'ITEM_CATEGORIES_AND_
KEYWORDS' (TABLE) (Cost=880 Card=1 Bytes=29)
Statistics
0 recursive calls
0 db block gets
5912606 consistent gets
0 physical reads
0 redo size
387 bytes sent via SQL*Net to client
435 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
2 rows processed

Queries not using indexes

We installed and configured a new environment of OBIEE and are trying to run a simple query in our data warehouse. This simple query takes only 7 seconds to complete in our previous data warehouse using TOAD but is taking 8+ minutes to complete in our new environment also using TOAD.
Looking at the explain plans, the query in the new environment is not using indexes. Does anyone have an idea why it is not using the indexes? We checked and all of the indexes have been created and still exist. We also ran Analyze again on the two tables used n the query but the query still did not use the indexes.
Please let me know if anyone has ideas ASAP since we are baffled.

- Are the object statistics identical? The ANALYZE statement has been depricated for a while, particularly for data warehouse environments where there may be partitioning. Were you not using the DBMS_STATS package to gather statistics in the previous environment? Were statistics computed on the indexes?
- Can you post the two query plans (formatted via DBMS_XPLAN and including the filter conditions)? It is not immediately obvious to me what index(es) might be useful here unless one of the two conditions is particularly selective which doesn't seem terribly likely based on just the table names involved.
- When you do post the query plans, please use the \[code\] and \[code\] tags to preserve the white space so that the output is readable.
Justin

How to make sql to use index/make to query to perform better

Hi,
I have 2 sql query which results the same.
But both has difference in SQL trace.
create table test_table
(u_id number(10),
u_no number(4),
s_id number(10),
s_no number(4),
o_id number(10),
o_no number(4),
constraint pk_test primary key(u_id, u_no));
insert into test_table(u_id, u_no, s_id, s_no, o_id, o_no)
values (2007030301, 1, 1001, 1, 2001, 1);
insert into test_table(u_id, u_no, s_id, s_no, o_id, o_no)
values (2007030302, 1, 1001, 1, 2001, 2);
insert into test_table(u_id, u_no, s_id, s_no, o_id, o_no)
values (2007030303, 1, 1001, 1, 2001, 3);
insert into test_table(u_id, u_no, s_id, s_no, o_id, o_no)
values (2007030304, 1, 1001, 1, 2001, 4);
insert into test_table(u_id, u_no, s_id, s_no, o_id, o_no)
values (2007030305, 1, 1002, 1, 1001, 2);
insert into test_table(u_id, u_no, s_id, s_no, o_id, o_no)
values (2007030306, 1, 1002, 1, 1002, 1);
commit;
CREATE INDEX idx_test_s_id ON test_table(s_id, s_no);
set autotrace on
select s_id, s_no, o_id, o_no
from test_table
where s_id <> o_id
and s_no <> o_no
union all
select o_id, o_no, s_id, s_no
from test_table
where s_id <> o_id
and s_no <> o_no;
Execution Plan
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=6 Card=8 Bytes=416)
1 0 UNION-ALL
2 1 TABLE ACCESS (FULL) OF 'TEST_TABLE' (TABLE) (Cost=3 Card=4 Bytes=208)
3 1 TABLE ACCESS (FULL) OF 'TEST_TABLE' (TABLE) (Cost=3 Card=4 Bytes=208)
Statistics
223 recursive calls
2 db block gets
84 consistent gets
0 physical reads
0 redo size
701 bytes sent via SQL*Net to client
508 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
5 sorts (memory)
0 sorts (disk)
8 rows processed
-- i didnt understand why the above query is not using the index idx_test_s_id.
-- But still it is faster
select s_id, s_no, o_id, o_no
from test_table
where (u_id, u_no) in
(select u_id, u_no from test_table
minus
select u_id, u_no from test_table
where s_id = o_id
or s_no = o_no)
union all
select o_id, o_no, s_id, s_no
from test_table
where (u_id, u_no) in
(select u_id, u_no from test_table
minus
select u_id, u_no from test_table
where s_id = o_id
or s_no = o_no);
Execution Plan
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=16 Card=2 Bytes=156)
1 0 UNION-ALL
2 1 FILTER
3 2 TABLE ACCESS (FULL) OF 'TEST_TABLE' (TABLE) (Cost=3 Card=6 Bytes=468)
4 2 MINUS
5 4 INDEX (UNIQUE SCAN) OF 'PK_TEST' (INDEX (UNIQUE)) (Cost=1 Card=1 Bytes=26)
6 4 TABLE ACCESS (BY INDEX ROWID) OF 'TEST_TABLE' (TABLE) (Cost=2 Card=1 Bytes=78)
7 6 INDEX (UNIQUE SCAN) OF 'PK_TEST' (INDEX (UNIQUE)) (Cost=1 Card=1)
8 1 FILTER
9 8 TABLE ACCESS (FULL) OF 'TEST_TABLE' (TABLE) (Cost=3 Card=6 Bytes=468)
10 8 MINUS
11 10 INDEX (UNIQUE SCAN) OF 'PK_TEST' (INDEX (UNIQUE)) (Cost=1 Card=1 Bytes=26)
12 10 TABLE ACCESS (BY INDEX ROWID) OF 'TEST_TABLE' (TABLE) (Cost=2 Card=1 Bytes=78)
13 12 INDEX (UNIQUE SCAN) OF 'PK_TEST' (INDEX (UNIQUE)) (Cost=1 Card=1)
Statistics
53 recursive calls
8 db block gets
187 consistent gets
0 physical reads
0 redo size
701 bytes sent via SQL*Net to client
508 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
4 sorts (memory)
0 sorts (disk)
8 rows processed
-- The above query is using index PK_TEST. But still it has FULL SCAN to the
-- table two times it has the more cost.
1st query --> SELECT STATEMENT Optimizer=ALL_ROWS (Cost=6 Card=8 Bytes=416)
2nd query --> SELECT STATEMENT Optimizer=ALL_ROWS (Cost=16 Card=2 Bytes=156)
My queries are:
1) performance wise which query is better?
2) how do i make the 1st query to use an index
3) is there any other method to get the same result by using any index
Appreciate your immediate help.
Best regards
Muthu

Hi William
Nice...it works.. I have added "o_id" and "o_no" are in part of the index
and now the query uses the index
Execution Plan
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=2 Card=8 Bytes=416)
1 0 UNION-ALL
2 1 INDEX (FULL SCAN) OF 'IDX_TEST_S_ID' (INDEX) (Cost=1 Card=4 Bytes=208)
3 1 INDEX (FULL SCAN) OF 'IDX_TEST_S_ID' (INDEX) (Cost=1 Card=4 Bytes=208)
Statistics
7 recursive calls
0 db block gets
21 consistent gets
0 physical reads
0 redo size
701 bytes sent via SQL*Net to client
507 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
8 rows processed
But my questions are:
1) In a where clause, if "<>" condition is used, then, whether the system will use the index. Because I have observed in several situations even though the column in where clause is indexed, since the where condition is "like" or "is null/is not null"
then the index is not used. Same as like this, i assumed, if we use <> then indexes will not be used. Is it true?
2) Now, after adding "o_id" and "o_no" columns to the index, the Execution plan is:
Execution Plan
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=2 Card=8 Bytes=416)
1 0 UNION-ALL
2 1 INDEX (FULL SCAN) OF 'IDX_TEST_S_ID' (INDEX) (Cost=1 Card=4 Bytes=208)
3 1 INDEX (FULL SCAN) OF 'IDX_TEST_S_ID' (INDEX) (Cost=1 Card=4 Bytes=208)
Before it was :
Execution Plan
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=6 Card=8 Bytes=416)
1 0 UNION-ALL
2 1 TABLE ACCESS (FULL) OF 'TEST_TABLE' (TABLE) (Cost=3 Card=4 Bytes=208)
3 1 TABLE ACCESS (FULL) OF 'TEST_TABLE' (TABLE) (Cost=3 Card=4 Bytes=208)
Difference only in Cost (reduced), not in Card, Bytes.
Can you explain, how can i decide which makes the performace better (Cost / Card / Bytes). Full Scan / Range Scan?
On statistics also:
Before:
Statistics
52 recursive calls
0 db block gets
43 consistent gets
0 physical reads
0 redo size
701 bytes sent via SQL*Net to client
507 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
8 rows processed
After:
Statistics
7 recursive calls
0 db block gets
21 consistent gets
0 physical reads
0 redo size
701 bytes sent via SQL*Net to client
507 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
8 rows processed
Difference in recursive calls & consistent gets.
Which one shows the query with better performance?
Please explain..
Regards
Muthu

Using index and NULL

Hi,
I have the following issue (10.2.0.4)
I have index on NO0_SESSION_ID and TBNAME
how can I force using index ?
Thanks for your help
UPDATE BXAT.no5
   SET TBNAME = :p0,
       REPLICATION_METHOD = :p1,
       STATUS = :p2,
       STARTING_TIME = :p3,
       ENDING_TIME = :p4,
       REC_INSERTED = :p5,
       REC_UPDATED = :p6,
       REC_UNCHANGED = :p7,
       REC_IN_ERROR = :p8,
       REC_CONFLICTS = :p9,
       TOTAL_REC = :p10,
       REC_CONF_UPDATED = :p11,
       REC_CONF_UNCHANGED = :p12,
       MASTER_TABLE = :p13,
       MASTER_SQ0_NRID = :p14,
       NO0_SESSION_ID = :p15,
       REC_PURGED = :p16,
       SQ0_NRID = :p17
WHERE     (NO0_SESSION_ID = :wp18 OR :wp18 IS NULL)
       AND (TBNAME = :wp19 OR :wp19 IS NULL)
| Id | Operation          | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | UPDATE STATEMENT   |      | 1723 | 96488 | 1361   (1)| 00:00:17 |
|   1 | UPDATE            | NO5 |       |       |            |          |
|* 2 |   TABLE ACCESS FULL| NO5 | 1723 | 96488 | 1361   (1)| 00:00:17 |
Predicate Information (identified by operation id):
   2 - filter((:WP19 IS NULL OR "TBNAME"=:WP19) AND (:WP18 IS NULL OR
              "NO0_SESSION_ID"=TO_NUMBER(:WP18)))

user12045475 wrote:
Hi,
I have the following issue (10.2.0.4)
I have index on NO0_SESSION_ID and TBNAME
how can I force using index ?
Thanks for your help
UPDATE BXAT.no5
SET TBNAME = :p0,
REPLICATION_METHOD = :p1,
STATUS = :p2,
STARTING_TIME = :p3,
ENDING_TIME = :p4,
REC_INSERTED = :p5,
REC_UPDATED = :p6,
REC_UNCHANGED = :p7,
REC_IN_ERROR = :p8,
REC_CONFLICTS = :p9,
TOTAL_REC = :p10,
REC_CONF_UPDATED = :p11,
REC_CONF_UNCHANGED = :p12,
MASTER_TABLE = :p13,
MASTER_SQ0_NRID = :p14,
NO0_SESSION_ID = :p15,
REC_PURGED = :p16,
SQ0_NRID = :p17
WHERE     (NO0_SESSION_ID = :wp18 OR :wp18 IS NULL)
AND (TBNAME = :wp19 OR :wp19 IS NULL)
| Id | Operation          | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | UPDATE STATEMENT   |      | 1723 | 96488 | 1361   (1)| 00:00:17 |
|   1 | UPDATE            | NO5 |       |       |            |          |
|* 2 |   TABLE ACCESS FULL| NO5 | 1723 | 96488 | 1361   (1)| 00:00:17 |
Predicate Information (identified by operation id):
2 - filter((:WP19 IS NULL OR "TBNAME"=:WP19) AND (:WP18 IS NULL OR
"NO0_SESSION_ID"=TO_NUMBER(:WP18)))
It has already been pointed out that the FTS is probably due to the OR whatever IS NULL predicates.
A hack that might/might not work - assuming indexes on the columns exist - is to use the syntax
--'' is an empty string, interpreted by Oracle as null
+column+ > ''A better way is to create a function-based index using NVL() or COALECSE on the affected column.

How can i use index in select query.. facing problem with the select query.

Hi Friends,
I am facing a serious problem in one of the select query. It is taking a lot of time to fetch data in Production Scenario.
Here is the query:
SELECT * APPENDING CORRESPONDING FIELDS OF TABLE tbl_summary
    FROM ztftelat LEFT JOIN ztfzberep
     ON ztfzberep~gjahr = st_input-gjahr
     AND ztfzberep~poper = st_input-poper
     AND ztfzberepcntr = ztftelatrprctr
    WHERE rldnr = c_telstra_accounting
      AND rrcty = c_actual
      AND rvers = c_ver_001
      AND rbukrs = st_input-bukrs
      AND racct = st_input-saknr
      AND ryear = st_input-gjahr
      And rzzlstar in r_lstar
      AND rpmax = c_max_period.
There are 5 indices present for Table ZTFTELAT.
Indices of ZTFTELAT:
Name   Description
0        Primary key( RCLNT,RLDNR,RRCTY,RVERS,RYEAR,ROBJNR,SOBJNR,RTCUR,RUNIT,DRCRK,RPMAX)
005    Profit (RCLNT,RPRCTR)
1        Ledger, company code, account (RLDNR,RBUKRS, RACCT)
2        Ledger, company code, cost center (RLDNR, RBUKRS,RCNTR)
3        Account, cost center (RACCT,RCNTR)
4        RCLNT/RLDNR/RRCTY/RVERS/RYEAR/RZZAUFNR
Z01    Activity Type, Account (RZZLSTAR,RACCT)
Z02    RYEAR-RBUKRS- RZZZBER-RLDNR
Can anyone help me out why it is taking so much time and how we can reduce it ? and also tell me if I want to use index number 1 then how can I use?
Thanks in advance.

Hi Shiva,
I am using two more select queries with the same manner ....
here are the other two select query :
***************1************************
SELECT * APPENDING CORRESPONDING FIELDS OF TABLE tbl_summary
    FROM ztftelpt LEFT JOIN ztfzberep
     ON ztfzberep~gjahr = st_input-gjahr
     AND ztfzberep~poper = st_input-poper
     AND ztfzberepcntr = ztftelptrprctr
    WHERE rldnr = c_telstra_projects
      AND rrcty = c_actual
      AND rvers = c_ver_001
      AND rbukrs = st_input-bukrs
      AND racct = st_input-saknr
      AND ryear = st_input-gjahr
      and rzzlstar in r_lstar
      AND rpmax = c_max_period.
and the second one is
*************************2************************
SELECT * APPENDING CORRESPONDING FIELDS OF TABLE tbl_summary
    FROM ztftelnt LEFT JOIN ztfzberep
     ON ztfzberep~gjahr = st_input-gjahr
     AND ztfzberep~poper = st_input-poper
     AND ztfzberepcntr = ztftelntrprctr
    WHERE rldnr = c_telstra_networks
      AND rrcty = c_actual
      AND rvers = c_ver_001
      AND rbukrs = st_input-bukrs
      AND racct = st_input-saknr
      AND ryear = st_input-gjahr
      and rzzlstar in r_lstar
      AND rpmax = c_max_period.
for both the above table program is taking very less time .... although both the table used in above queries have similar amount of data. And i can not remove the APPENDING CORRESPONDING. because i have to append the data after fetching from the tables. if i will not use it will delete all the data fetched earlier.
Thanks on advanced......
Sourabh

Error while trying to run DBMS_STAT.GATHER_TABLE_STATS

Hi Gurus,
I am trying to run DBMS_STAT.GATHER_TABLE_STATS from a procedure from a DBA role granted user I am getting the folowing error:
ORA-20000: Unable to analyze TABLE "<SCHEMA_NAME>"."<TABLE_NAME>", insufficient privileges or does not exist
ORA-06512: at "SYS.DBMS_STATS", line 13046
ORA-06512: at "SYS.DBMS_STATS", line 13076
ORA-06512: at line 2
Is I am missing something?
Please help...
//saby

It's a quite common problem...
Privileges granted through roles doesn't work inside stored procedures. So the DBA role it's not working inside procedure.
See Metalink Note 168168.1.
If you want to run dbms_stats.gather_table_stats from inside procedure,
you need to grant "ANALYZE ANY" directly to this user.
Thanks
Tomasz K.

Best way of Using Index on a Table.

I am trying to understand the phenomena of using INDEX on a Table
need some guidance!!!
Let us take this scenario
I have a table "MYRECORD" which has 4 attributes(or coulombs)
1. "STATE" (varchar) // this can have 49 different values like newyork, dehli etc
2. "YEAR" //a year like 2007
3. "MONTH" //a month like JAN,FEB etc
4. "CAT" (int) // type(category) of data represented by values 0 to 40
with a PRIMARY KEY(STATE,YEAR,MONTH,CAT)
now i will create index
1. INX_myrecord (STATE,YEAR,MONTH) on table MYRECORD
so now my question is
1. what is the effect on performance of DB it makes?
2. when I use a query
SELECT * FROM MYRECORD WHERE STATE="dehli" AND YEAR=2007 AND MONTH="JAN";
how will it get processed if index is created and not created.
3. how can I refer a index by name in a query if so possible?
Cheers,
UD
Message was edited by:
UDAY

You have edited your post. Now you have a primary key consisting of state, year, month and cat which makes an index on state, year and month useless as the already existing primary key can provide for retrieval of rows by index. If you don't have other columns - or just few other not being large varchar2 columns - you should have created the table as an IOT (Index Organized Table - avoiding to have separate table and index containing - nearly - the same data) in the first place.
As a primary key by definition can contain only unique non null values, a query like SELECT * FROM MYRECORD WHERE STATE='dehli' AND YEAR=2007 AND MONTH='JAN' cannot give you more than the number of distinct cat values (0 .. 40) + 1 (if cat can be null - presumed one/some of the corresponding state, year and month is not null)
The information processing depends principally of the query, the mere presence of an index does not make sure it will be used. If an index is used it means the index will be searched first then the table rows will be accessed by rowids contained in the index (usually a single row or a range of rows - a rather small number of them - is retrieved this way, your select for example). Submitting something like SELECT * FROM MYRECORD WHERE YEAR=2007 AND cat=33 would most likely produce a full table scan of myrecord table ignoring the primary key.
Regards
Etbin

Not Using Index on File Server When Accessing User Files Directly on Server

It appears to me that on a server with an indexed network share (Desktop Experience and Search Indexing roles/features installed), if you access the share directly on the server using its drive path, you can search the folders using the index, which
is much faster and supports finding words inside of the files in seconds). However, if you access the same shared folder via its network path from the server itself, the server ignores the index. I have this experience/problem across all shared folders on
the Windows 2012 R2 Server. Details and my most specific goal follows.
In addition to a laptop, I frequently work directly on a Windows Server 2012 R2 computer. We have Redirected Folders set up on DFS (for failover redundancy) so that my Documents folder is in:
\\network\redirections\user\documents. This all works fine on Windows 7 and 8 client computers connected to the network via Offline Files.
The problem is on the server itself. The server has Desktop Experience enabled and Windows Search is installed. If I navigate manually through the DFS root folder to my documents folder, I can search and it properly uses the index. This proves the location
is properly indexed. However, if I access the folders through the official "Documents" folder from the Folder Redirection (a network share pointing to the same server computer I'm working on), it performs an un-indexed search (slow and ignores file
contents, but does find files eventually if the search term is in their filename). Is there a way to force the server to use the indexed search on the Redirected Folders (my Documents folder in particular) when working on that server when logged in locally
on that server?
I suspect a workaround would be to go into the Registry and manually change the HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders to point to the local DFS folder instead of the network share name, but at least one problem
with this is then if I save files with links to other files (e.g., a linked Excel table in a PowerPoint, a mail merge to Access database in Word, etc.) on the server computer, those links will point to d:\DFSroot\... (a physical drive on the computer) instead
of \\network\redirections\user\... (a universally accessible network path) and so none of the other computers will be able to find the linked files, defeating one of the
major benefits of using Redirected Folders.
I can't believe that I need to choose between indexed searching and proper path names in saved files. Surely there is a way to use an indexed search on the server itself?
If you need any more info to help me troubleshoot, please let me know.
Thanks for any help,
Colin

Hi Colin,
It seems that we can not use indexed search on DFS shares. Windows Search works well when users directly access the server. That is, the server is not made available through Distributed File System (DFS).
For more detailed information, you could refer to the links below:
Windows Search Service, Clustered File Services, DFS, Win7 Libraries
https://social.technet.microsoft.com/Forums/windowsserver/en-US/31ac4c16-948b-4ca4-b18f-3a339cdfd5b9/windows-search-service-clustered-file-services-dfs-win7-libraries?forum=winserverfiles
Windows Browse and Organize Features
https://technet.microsoft.com/en-us/library/dd744693(WS.10).aspx
Best Regards,
Mandy
Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact [email protected]

Using Index Vs dbms_stats.gather_table_stats

Similar Messages

Maybe you are looking for