Index Usage

Hi All,
Using Oracle 11.2.0.3 on a TEST server
create index emp_job_sal_idx on emp(job,sal) ;
SQL> create or replace view test1 as select d.deptno, d.dname, e.empno, e.job, e.sal from dept d, emp e where d.deptno=e.deptno and
(e.job='CLERK' and e.sal > 1000) OR
(e.job='ANALYST' and e.sal >= 3000) OR
(e.job='SALESMAN' and e.sal >=1500);
SQL> set autotrace on explain
SQL> select * from test1;
18 rows selected.
Execution Plan
Plan hash value: 4192419542
| Id | Operation        | Name | Rows | Bytes | Cost (%CPU)| Time       |
|   0 | SELECT STATEMENT   |       |     1 |    67 |    10   (0)| 00:00:01 |
|   1 | NESTED LOOPS        |       |     1 |    67 |    10   (0)| 00:00:01 |
|   2 |   TABLE ACCESS FULL| DEPT |     4 |    88 |     3   (0)| 00:00:01 |
|* 3 |   TABLE ACCESS FULL| EMP |     1 |    45 |     2   (0)| 00:00:01 |
---------------------------------------------------------------------------The index is not used, mostly due to a OR condition. How can we make the index use without using hints ?

sb92075 wrote:
post EXPLAIN PLAN for problem SQL
Execution Plan
Plan hash value: 3466901445
| Id | Operation          | Name        | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT   |             |     1 |   331 |   383K (7)| 01:16:40 |
|* 1 | HASH JOIN         |             |     1 |   331 |   383K (7)| 01:16:40 |
|* 2 |   TABLE ACCESS FULL| ENT_TRAN|     1 |   165 |   205K (9)| 00:41:07 |
|   3 |   TABLE ACCESS FULL| ENT_MAST         |    19M| 3111M|   177K (3)| 00:35:31 |
1 - access(NLSSORT("ENT_MAST"."ID",'nls_sort=''BINARY_CI''')=NLSSORT(
              "ENT_TRAN"."RID",'nls_sort=''BINARY_CI'''))
   2 - filter(NLSSORT("ENT_TRAN"."NAME",'nls_sort=''BINARY_CI'''
              )=HEXTORAW('616D616E616820736168616D206E6173696F6E616C2062657268616400')
              AND NLSSORT("ENT_TRAN"."PP_NO",'nls_sort=''BINARY_CI''')=HEXTORAW('343
              73435377600') OR NLSSORT("ENT_TRAN"."NAME",'nls_sort=''BINARY_C
              I''')=HEXTORAW('74656E616761206E6173696F6E616C2062657268616400') AND
              NLSSORT("ENT_TRAN"."PP_NO",'nls_sort=''BINARY_CI''')=HEXTORAW('3230303
              836367700') OR NLSSORT("ENT_TRAN"."NAME",'nls_sort=''BINARY_CI'
              '')=HEXTORAW('74656C656B6F6D206D616C61797369612062657268616400') AND
              NLSSORT("ENT_TRAN"."PP_NO",'nls_sort=''BINARY_CI''')=HEXTORAW('3132383
              734307000') OR NLSSORT("ENT_TRAN"."NAME",'nls_sort=''BINARY_CI'
              '')=HEXTORAW('6167726F2062616E6B00') AND
              NLSSORT("ENT_TRAN"."PP_NO",'nls_sort=''BINARY_CI''')=HEXTORAW('3831313
              831307500') OR NLSSORT("ENT_TRAN"."NAME",'nls_sort=''BINARY_CI'
              '')=HEXTORAW('6272756365206C656520796565206C616D00') AND
              NLSSORT("ENT_TRAN"."PP_NO",'nls_sort=''BINARY_CI''')=HEXTORAW('3530333
              333373100') OR NLSSORT("ENT_TRAN"."NAME",'nls_sort=''BINARY_CI'
              '')=HEXTORAW('616B6261722074726164696E6700') AND
              NLSSORT("ENT_TRAN"."PP_NO",'nls_sort=''BINARY_CI''')=HEXTORAW('3030313
              438383037397500') OR NLSSORT("ENT_TRAN"."NAME",'nls_sort=''BINA
              RY_CI''')=HEXTORAW('372D656C6576656E206D616C61797369612073646E2062686400')
                AND NLSSORT("ENT_TRAN"."PP_NO",'nls_sort=''BINARY_CI''')=HEXTORAW('3
              132303936327000') OR NLSSORT("ENT_TRAN"."NAME",'nls_sort=''BINA
              RY_CI''')=HEXTORAW('6368616E20796F6B65206368656E6700') AND
              NLSSORT("ENT_TRAN"."PP_NO",'nls_sort=''BINARY_CI''')=HEXTORAW('3637303
              532372D30362D3534393600') OR NLSSORT("ENT_TRAN"."NAME",'nls_sor
              t=''BINARY_CI''')=HEXTORAW('646B7368206D616C61797369612073646E2062686400')
                AND NLSSORT("ENT_TRAN"."PP_NO",'nls_sort=''BINARY_CI''')=HEXTORAW('3
              030343437367500') OR NLSSORT("ENT_TRAN"."NAME",'nls_sort=''BINA
              RY_CI''')=HEXTORAW('626574746572207B267D206265737420656E746572707269736500
              ') AND NLSSORT("ENT_TRAN"."PP_NO",'nls_sort=''BINARY_CI''')=HEXTORAW(
              '3030313632353132347000') OR NLSSORT("ENT_TRAN"."NAME",'nls_sor
              t=''BINARY_CI''')=HEXTORAW('6C696D20656E672073696F65206A756E6B657400')
              AND NLSSORT("ENT_TRAN"."PP_NO",'nls_sort=''BINARY_CI''')=HEXTORAW('743
              5353138393300') OR NLSSORT("ENT_TRAN"."NAME",'nls_sort=''BINARY
              _CI''')=HEXTORAW('712E712E206A756E6B657400') AND
              NLSSORT("ENT_TRAN"."PP_NO",'nls_sort=''BINARY_CI''')=HEXTORAW('7331373
              233363200') OR NLSSORT("ENT_TRAN"."NAME",'nls_sort=''BINARY_CI'
              '')=HEXTORAW('6572206B696D206B656F6E6700') AND
              NLSSORT("ENT_TRAN"."PP_NO",'nls_sort=''BINARY_CI''')=HEXTORAW('3539303
              932302D31302D3538333700') OR NLSSORT("ENT_TRAN"."NAME",'nls_sor
              t=''BINARY_CI''')=HEXTORAW('726963686C616E64206C6569737572652067726F757000
              ') AND NLSSORT("ENT_TRAN"."PP_NO",'nls_sort=''BINARY_CI''')=HEXTORAW(
              '3538303532382D30312D3539383500') OR
              NLSSORT("ENT_TRAN"."NAME",'nls_sort=''BINARY_CI''')=HEXTORAW('74
              69656E2079756E20656E74657270726973652073646E2E206268642E00') AND
              NLSSORT("ENT_TRAN"."PP_NO",'nls_sort=''BINARY_CI''')=HEXTORAW('3637303
              332382D31302D3534363700') OR NLSSORT("ENT_TRAN"."NAME",'nls_sor
              t=''BINARY_CI''')=HEXTORAW('73686172696B617420686F636B2068696E00') AND
              NLSSORT("ENT_TRAN"."PP_NO",'nls_sort=''BINARY_CI''')=HEXTORAW('3030303
              234323136397000') OR NLSSORT("ENT_TRAN"."NAME",'nls_sort=''BINA
              RY_CI''')=HEXTORAW('6D7964696E206D6F68616D656420686F6C64696E67732062686420
              28666F726D65726C79206B6E6F776E206173206D7964696E206D6F68616D656420686F6C64
              696E67732073646E206268642900') AND NLSSORT("ENT_TRAN"."PP_NO",'nls_so
              rt=''BINARY_CI''')=HEXTORAW('3232313434386100') OR
              NLSSORT("ENT_TRAN"."NAME",'nls_sort=''BINARY_CI''')=HEXTORAW('65
              7665726973652076656E74757265732073646E2062686400') AND
              NLSSORT("ENT_TRAN"."PP_NO",'nls_sort=''BINARY_CI''')=HEXTORAW('3239353
              137377000') OR NLSSORT("EN)
Statistics
          1 recursive calls
          0 db block gets
    1353887 consistent gets
    1353339 physical reads
          0 redo size
    1204784 bytes sent via SQL*Net to client
       4989 bytes received via SQL*Net from client
        408 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
       6092 rows processed
{code}

Similar Messages

UNUSED EXISTING INDEXES / Index usage

We are using CRM 2007, Netweaver 7.0 with DB2 UDB v9.1 fixpack4 on AIX.
Is there a way to find out UNUSED EXISTING INDEXES for tables ? We have close 12 indexes on the crmd_order_index table and want to find out if some of them can safely deleted. Is there any way to monitor index usage in SAP ? Is there any toold to aid this ?
Pls advise.
thank you
regards
Laxmi

Laxmi,
I am not aware of any such tools with DB2 9.1. However, "last_used" columns are being added to various catalog tables in DB2 9.7. Below is an excerpt from a slide presented in the TLU2008A "DB2 LUW V9.7 Cobra u2013 Storage is Charmed" session.
The last reference time of an object will now be maintained in the LASTUSED column of
the corresponding catalog table for the object
u2013 SYSCAT.INDEXES.LASTUSED (prior to V9.7 db2pd u2013tcbstats indexes)
u2013 SYSCAT.TABLES.LASTUSED
u2013 SYSCAT.DATAPARTITIONS.LASTUSED
u2013 SYSCAT.PACKAGE.LASTUSED
The LASTUSED column is of type DATE (default value is 1/1/0001)
Use Cases:
u2013 Detach table partitions that are no longer actively used (esp. when not partitioned by time)
u2013 Determine inactive or infrequently used indexes
u2013 Easily identify tables which are no longer in use
u2013 Get rid of unused packages
The presenter said the code will begin populating these columns in an upcoming fixpack.
Regards,
Rick

'IS NOT NULL' & Index Usage

Hi,
there are many queries my one of my packages, which has the SQL as follows:
Update table XYZ
Set Column A = NULL
Where Colum B IS NOT NULL;
Column B has NUMBER datatype.
Due to 'IS NOT NULL' the index (existing for Column B' is not being used in the above query, leading to Full table scan. Is there any ways of forcing teh index to be picked/used by the query?
Thanks,
Rosalin

thansk again for response. Checked the % of the data
fetched by this query and it ranges from 20% to 50
%(varies due to teh fact the table data content could
have different set of data depending on the days
transactions done). So for sure index usage would
help.
Additionally this sql(used in multiple places) come
up in the v$longsops output.
so definitely needs tuning.
Any suggestions?That's not really true though if you understand the mechanisms employed for a full table scan vs an index scan / table lookup (by rowid since the table must also be visited).
Here's something good for you to read
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:4433887271030
A full tablescan reads the table using large sequential reads -- many blocks at a time.
Sequential reads are the fastest type of IO you can do on a disk in general.
An index read will do single block, random IO's. These are generally the slowest you can
do.
I would suggest to you that if you have statistics on the table/indexes that are representative of the data, the Optimizer will be smarter than you (most cases, not all).
Message was edited by:
Tubby

SQL INDEX USAGE

hi,
I have a procedure which took 15-20 minutes in the past to execute.Suddently it is taking 2 hours.When i examined i came to know that the sql statement is not using one of the index.I dropped the index and created it.The explain plan is generated but still the index is not being used.I forced the index usage by using the index hint
SELECT /*+ INDEX(test_his test_hist_idx )*/ column 1.....
But still it does not use the index.Please suggest me some advice on this?
Thanks

user589320 wrote:
I have a procedure which took 15-20 minutes in the past to execute.Suddently it is taking 2 hours.When i examined i came to know that the sql statement is not using one of the index.I dropped the index and created it.The explain plan is generated but still the index is not being used.I forced the index usage by using the index hint
SELECT /*+ INDEX(test_his test_hist_idx )*/ column 1.....
I think you're going to have to post the entire text of your query if you want an answer, or people will simply be trying to guess what you've done wrong.
Do you also have the full execution plan from before and after the change in performance ?
If you do post the text, and plans, please use the 'code' tags to make the text readable.
p.s. My shot in the dark guess, based on the text you've supplied, is that you've used the table name in the hint, rather than the table alias.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
"The temptation to form premature theories upon insufficient data is the bane of our profession."
Sherlock Holmes (Sir Arthur Conan Doyle) in "The Valley of Fear".
To post code, statspack/AWR report, execution plans or trace files, start and end the section with the tag {noformat}{noformat} (lowercase, curly brackets, no spaces) so that the text appears in fixed format.

Index Usage in 9i changed when used rownum

Hi List,My Application is in RBO
Here is one more brain twister ?
Assume following I Have table SHRI with a single column
COL I have created Index on COL column say IND_COL.
Now when I run Following query on 8i with AUTOTRACE ON
I can see that 8i Uses the Index IND_COL Clearly .
select * from shri where (h_name='ABC' or h_name='BOM')
or (h_name ='BOM' or h_name='MOM')
and rownum=1
select * from shri where (COL='ABC' or COL='BOM')
or (COL='ABC' or COL='BOM')
and rownum=1
(Note:Above example is just for ur understanding plz.dont see the usage)
Now my problem is when I see the explain plan for above query in 8i I can see that Query uses IND_COL .
But when I run the same in 9i It does not uses IND_COL Index (Strange!!!) .
However when I remove "and rownum=1" clause then It again uses the index in 9i.
Assume that such queries are existing many places .
I am badly stuck because of this problem can anybody suggest the best way (Other than changing RBO to CBO) ?
Regards
Sripad.

Run below query, you will get all the details of tablespaces.
col "Tablespace" for a22
col "Used MB" for 99,999,999
col "Free MB" for 99,999,999
col "Total MB" for 99,999,999
select df.tablespace_name "Tablespace",
totalusedspace "Used MB",
(df.totalspace - tu.totalusedspace) "Free MB",
df.totalspace "Total MB",
round(100 * ( (df.totalspace - tu.totalusedspace)/ df.totalspace))
"Pct. Free"
from
(select tablespace_name,
round(sum(bytes) / 1048576) TotalSpace
from dba_data_files
group by tablespace_name) df,
(select round(sum(bytes)/(1024*1024)) totalusedspace, tablespace_name
from dba_segments
group by tablespace_name) tu
where df.tablespace_name = tu.tablespace_name ;

LIKE, LIKEC and Index usage

I've table that contains about 20 million rows, and I've created index for varchar2(100) column. It works well if I do
SELECT * FROM MY_TABLE WHERE MY_COL LIKE 'FOO%';
But if I change query to use LIKEC (to make unicode escaped strings work):
SELECT * FROM MY_TABLE WHERE MY_COL LIKEC 'FOO%';
I always get full table scan in explain plan.
I tried to use NVARCHAR, or index created by TO_NCHAR but I always end up hitting full table scan.
Should I create index some special way or do something else before I get index working?

Just a gut feeling : is the database using character semantics or byte semantics?
My gut feeling, after looking up the documentation, is it should be character semantics.
BTW: Not posting version info decreases the chance you get an adequate reply.
Sybrand Bakker
Senior Oracle DBA

Index usage error

i am having a table in my schema named provider_rate_history
PROVIDER_RATE_HISTORY_ID      NOT NULL      NUMBER
WORK_ORDER_HISTORY_ID      NOT NULL      NUMBER
PROVIDER_RATE_TYPE_ID      NOT NULL      NUMBER
CREATED_BY      NOT NULL      NUMBER
DATE_CREATED      NOT NULL      DATE
MODIFIED_BY           NUMBER
DATE_MODIFIED           DATE
I created an index named provider_rate_type_idx on the provider_rate_type_id column of the table, but when i am using the following query index is used, but if i replace count(*) keyword in the select statement with any of the column name of the table a ful table scan is performed. What could be the reason for this error and how to correct it
select count(*) from provider_rate_history
where rate_type_id=7;
Index is used, if we replace count(*) with any column name of the table index is not used
select work_order_history_id from provider_rate_history
where rate_type_id=7;
Index is not used

Hi,
Why count(*) will lead to full table scan?
APC have clearly told reason for not using Index.
Hope this illustration helps to clear the situation.
SQL> create table test111 as select * from all_objects where rownum < 1001;
Table created.
SQL> desc test111
Name Null? Type
OWNER NOT NULL VARCHAR2(30)
OBJECT_NAME NOT NULL VARCHAR2(30)
SUBOBJECT_NAME VARCHAR2(30)
OBJECT_ID NOT NULL NUMBER
DATA_OBJECT_ID NUMBER
OBJECT_TYPE VARCHAR2(19)
CREATED NOT NULL DATE
LAST_DDL_TIME NOT NULL DATE
TIMESTAMP VARCHAR2(19)
STATUS VARCHAR2(7)
TEMPORARY VARCHAR2(1)
GENERATED VARCHAR2(1)
SECONDARY VARCHAR2(1)
SQL> create index test111_indx1 on test111 (object_id);
Index created.
SQL>
SQL> set autotrace on
SQL> select count(1) from test111;
COUNT(1)
1000
Execution Plan
Plan hash value: 1326770390
| Id | Operation | Name | Rows | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 3 (0)| 00:00:01 |
| 1 | SORT AGGREGATE | | 1 | | |
| 2 | INDEX FAST FULL SCAN| TEST111_INDX1 | 1000 | 3 (0)| 00:00:01 |
Note
- dynamic sampling used for this statement
Statistics
5 recursive calls
0 db block gets
23 consistent gets
3 physical reads
0 redo size
206 bytes sent via SQL*Net to client
239 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
SQL>
SQL> select count(distinct owner) from test111;
COUNT(DISTINCTOWNER)
3
Execution Plan
Plan hash value: 991123090
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 17 | 5 (0)| 00:00:01 |
| 1 | SORT GROUP BY | | 1 | 17 | | |
| 2 | TABLE ACCESS FULL| TEST111 | 1000 | 17000 | 5 (0)| 00:00:01 |
Note
- dynamic sampling used for this statement
Statistics
27 recursive calls
0 db block gets
33 consistent gets
0 physical reads
0 redo size
233 bytes sent via SQL*Net to client
239 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
1 rows processed
SQL>

Index usage depends on columns selected

Hi, somehow cannot understand why index is not used, please help.
in Oracle Database 11g Release 11.2.0.3.0 - 64bit Production
1.     Included only indexed column and got a perfect plan
explain plan for2 select s.x_cnt
3 from reported_summary s
4 where s.x_cnt>0;
PLAN_TABLE_OUTPUT
Plan hash value: 2674489506
| Id | Operation | Name | Cost (%CPU)|
| 0 | SELECT STATEMENT | | 306 (8)|
|* 1 | INDEX FAST FULL SCAN| S_NUI01 | 306 (8)|
Predicate Information (identified by operation id):
1 - filter("s"."x_CNT">0)
2.     Included some other column and got TABLE ACCESS FULL
explain plan for2 select s.x_cnt,s.ru_id
3 from reported_summary s
4 where s.x_cnt>0;
PLAN_TABLE_OUTPUT
Plan hash value: 2142873335
| Id | Operation | Name | Cost (%CPU)|
| 0 | SELECT STATEMENT | | 2421 (3)|
|* 1 | TABLE ACCESS FULL| REPORTED_SUMMARY | 2421 (3)|
Predicate Information (identified by operation id):
1 - filter("s"."x_CNT">0)
3.     Included all other columns and got TABLE ACCESS FULL as well
explain plan for2 select s.x_cnt,s.*
3 from reported_summary s
4 where s.x_cnt>0;
PLAN_TABLE_OUTPUT
Plan hash value: 2142873335
| Id | Operation | Name | Cost (%CPU)|
| 0 | SELECT STATEMENT | | 2421 (3)|
|* 1 | TABLE ACCESS FULL| REPORTED_SUMMARY | 2421 (3)|
Predicate Information (identified by operation id):
1 - filter("s"."x_CNT">0)
Thanks a lot

Thanks all, just to clarify
"select s.x_cnt from reported_summary s..." is using index;
"select 'Y' y from reported_summary s..." is using index;
"select <any ohter column> from reported_summary s..." is causing TABLE ACCESS FULL;
no differences in where clause, no order by at all
the index script is
CREATE INDEX S_NUI01 ON REPORTED_SUMMARY (OFFSET_CNT) TABLESPACE X_INDEXES;
jgarry, thanks for the answer, the only problem that I have clone of the database (32 bit) with same CBO parameters
where it does not behave this way:
explain plan for2 select s.offset_cnt
3 from reported_summary s
4 where s.offset_cnt>0;
PLAN_TABLE_OUTPUT
Plan hash value: 2359470296
| Id | Operation | Name | Cost (%CPU)|
| 0 | SELECT STATEMENT | | 9 (0)|
|* 1 | INDEX RANGE SCAN| S_NUI01 | 9 (0)|
Predicate Information (identified by operation id):
1 - access("s"."OFFSET_CNT">0)
explain plan for2 select s.offset_cnt,s.ru_id
3 from reported_summary s
4 where s.offset_cnt>0;
PLAN_TABLE_OUTPUT
Plan hash value: 3732627180
| Id | Operation | Name | Cost (%CPU)|
| 0 | SELECT STATEMENT | | 67 (0)|
| 1 | TABLE ACCESS BY INDEX ROWID| REPORTED_SUMMARY | 67 (0)|
|* 2 | INDEX RANGE SCAN | S_NUI01 | 9 (0)|
Predicate Information (identified by operation id):
2 - access("s"."OFFSET_CNT">0)
Thanks again.

Index usage making SQL slower.

Hello,
While working on a performance tuning activity on Oracle 10.2.0.4 on Solaris 10, I encountered a problem wherein one of our DBA's suggested indexing 2 columns of a certain table. One of the queries which is being run on that table has a RULE hint, and it is seen to be making use of this newly created index. Before the index was created, this query was running fine and getting completed within 30 mins or so. However after the index is created, it is now taking 12 hours on average to complete. Please note that in both the above cases, the CURSOR_SHARING parameter was set to EXACT. Yes, after the index was created its statistics were computed, and for both the index and the base table statistics were gathered. The query is making use of bind variables and is being run via the SQR engine of PeopleSoft.
Please advice what can be the possible reasons for such delays being caused?
For any information, please let me know and I would provide the same in this forum/
Note for moderators: I could not find the section for Performance tuning, so I am asking this question in the general forum. Apologies.
Thank You,
Prashant.

Index scans are not always faster.
Full table scans are not always bad.
I doubt that the RULE hint is necessary.
In general, [url http://www.centrexcc.com/Tuning%20by%20Cardinality%20Feedback.pdf]the CBO does an excellent job of finding the best access plan for a given sql provided it is able to accurately estimate the cardinalities of the row sources in the plan.
See advice and information required in the template tuning threads:
[url https://forums.oracle.com/forums/thread.jspa?threadID=863295]How to post a sql tuning request
[url https://forums.oracle.com/forums/thread.jspa?messageID=1812597]When your query takes too long

Index usage in depending on where clause changes.

Hello Friends,
I need your help for one issue.
I have one query , which is using two table Say T1 and T2, where C1 is common column using which both are joined.
C1 is primary key in T1, but no index available in T2 for C1. T1C2 is the column which we want to select.
(Note that Either of table can be a Master table)
Now see the query:
Select T1C2
From T1, T2
where T2.C1 = T1.C1
Here where clause may have other conditions and From clause may have others tables as per requirements.
I want to know that, if, I change the query like following to let my query use the available index of T1.C1.
Select T1C2
from T1, T2
where T1.C1 = T2.C1
Then, Will the query use the available index of T1. and Will i get better performance. Even a little improvement in performance may help me a lot as this kind of query is being used within a where loop (so it is going to be executed multiple times).
Please advise on this..
Regards,
Dipali..

Hi,
18:43:17 rel15_real_p>create table t1(c1 number primary key, c2 number);
Table created.
18:43:26 rel15_real_p>create table t2(c1 number, c2 number);
18:45:08 rel15_real_p>
18:45:09 rel15_real_p>begin
18:45:09   2 for i in 1..100
18:45:09   3 loop
18:45:09   4        insert into t1(c1,c2) values (i,i+100);
18:45:09   5 end loop;
18:45:09   6 commit;
18:45:09   7 end;
18:45:09   8 /
PL/SQL procedure successfully completed.
18:45:09 rel15_real_p>
18:45:09 rel15_real_p>
18:45:09 rel15_real_p>begin
18:45:09   2 for i in 1..100
18:45:09   3 loop
18:45:09   4        insert into t2(c1,c2) values (i,i+200);
18:45:09   5 end loop;
18:45:09   6 commit;
18:45:09   7 end;
18:45:09   8 /
18:45:23 rel15_real_p>select count(*) from t1;
COUNT(*)
       100
18:45:30 rel15_real_p>select count(*) from t2;
COUNT(*)
       100
18:45:49 rel15_real_p>select index_name,index_type from user_indexes where table
_name='T1';
INDEX_NAME                     INDEX_TYPE
SYS_C0013059                   NORMAL
18:48:21 rel15_real_p>set autotrace on
18:52:25 rel15_real_p>Select T1.C2
18:52:29   2 From T1, T2
18:52:29   3 where T2.C1 = T1.C1
18:52:29   4 /
        C2
       101
       102
       103
       104
       105
        C2
       200
100 rows selected.
Execution Plan
   0      SELECT STATEMENT Optimizer=ALL_ROWS (Cost=7 Card=100 Bytes=
          900)
   1    0   HASH JOIN (Cost=7 Card=100 Bytes=3900)
   2    1     TABLE ACCESS (FULL) OF 'T1' (TABLE) (Cost=3 Card=100 By
          es=2600)
   3    1     TABLE ACCESS (FULL) OF 'T2' (TABLE) (Cost=3 Card=100 By
          es=1300)
Statistics
          0 recursive calls
          0 db block gets
         21 consistent gets
          0 physical reads
          0 redo size
       1393 bytes sent via SQL*Net to client
        562 bytes received via SQL*Net from client
          8 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
        100 rows processed
18:52:31 rel15_real_p>analyze table t1 compute statistics;
Table analyzed.
18:55:35 rel15_real_p>analyze table t2 compute statistics;
18:55:38 rel15_real_p>set autotrace on
18:55:42 rel15_real_p>Select T1.C2
18:55:43   2 From T1, T2
18:55:45   3 where T2.C1 = T1.C1
18:55:46   4 /
        C2
       101
       102
       103
       104
       105
        C2
       200
100 rows selected.
Execution Plan
   0      SELECT STATEMENT Optimizer=ALL_ROWS (Cost=6 Card=100 Bytes=7
          00)
   1    0   MERGE JOIN (Cost=6 Card=100 Bytes=700)
   2    1     TABLE ACCESS (BY INDEX ROWID) OF 'T1' (TABLE) (Cost=2 Ca
          rd=100 Bytes=500)
   3    2       INDEX (FULL SCAN) OF 'SYS_C0013059' (INDEX (UNIQUE)) (
          Cost=1 Card=100)
   4    1     SORT (JOIN) (Cost=4 Card=100 Bytes=200)
   5    4       TABLE ACCESS (FULL) OF 'T2' (TABLE) (Cost=3 Card=100 B
          ytes=200)
Statistics
          1 recursive calls
          0 db block gets
         23 consistent gets
          0 physical reads
          0 redo size
       1393 bytes sent via SQL*Net to client
        562 bytes received via SQL*Net from client
          8 SQL*Net roundtrips to/from client
          1 sorts (memory)
          0 sorts (disk)
        100 rows processed
18:56:56 rel15_real_p>Select T1.C2
18:56:56   2 From T1, T2
18:56:56   3 where T1.C1 = T2.C1
18:56:58   4 /
        C2
       101
       102
       103
       104
       105
        C2
       200
100 rows selected.
Execution Plan
   0      SELECT STATEMENT Optimizer=ALL_ROWS (Cost=6 Card=100 Bytes=7
          00)
   1    0   MERGE JOIN (Cost=6 Card=100 Bytes=700)
   2    1     TABLE ACCESS (BY INDEX ROWID) OF 'T1' (TABLE) (Cost=2 Ca
          rd=100 Bytes=500)
   3    2       INDEX (FULL SCAN) OF 'SYS_C0013059' (INDEX (UNIQUE)) (
          Cost=1 Card=100)
   4    1     SORT (JOIN) (Cost=4 Card=100 Bytes=200)
   5    4       TABLE ACCESS (FULL) OF 'T2' (TABLE) (Cost=3 Card=100 B
          ytes=200)
Statistics
          1 recursive calls
          0 db block gets
         23 consistent gets
          0 physical reads
          0 redo size
       1393 bytes sent via SQL*Net to client
        562 bytes received via SQL*Net from client
          8 SQL*Net roundtrips to/from client
          1 sorts (memory)
          0 sorts (disk)
        100 rows processed- Pavan Kumar N

Index usage problem..

I got an requirement stating to get a max value of column b for given value for column a. Since to avoid a table scan, I created a composite Index on (a, b).
I tried with the query
select max(b) from table where a = invalue
Since the index is already been sorted the max(b) for value of a should be direct. But the explain plan for this query says, a range scan on the index and a sort and then the output of value.
But I like to have a single row fetch directly. Pls help me in modifying the query to get the max value directly without any scans.
Thanks
Suriya.

I'm not sure whether it is work, but you can try :
(1) Using single select statement
select x.b
from ( select b from table
where a = invalue
order by b desc
where rownum = 1;
OR
(2) PL/SQL program
begin
for c1rec in ( select b from table
where a = invalue
order by b desc ) loop
dbms_output.put_line(c1rec.b);
exit;
end loop;
end;
null

Index Usage from SQL query in Oracle Forms

Would using LIKE/OR in where clause (of an indexed column) will force the the query to NOT use INDEX. We have these where clause in Oracle Forms Records Group.
Below are two examples...
1. If we have a where clause with LIKE would that NOT use the index?
Example: ColumnName like :block.Column||%
2. How about having an OR clause?
Example: and (ColumnName = :block.column or :block.column is null)
Thanks

Hi
Answer 1: Where with like clause WOULD use the index.
In this example index on ColumnName
Answer 2: Write better where:
Example: and (:block.column is null or ColumnName = :block.column)
When :block column is null then statement after 'or' is not used. Index will not be used with RBO, i think.
The best way to be sure is to look at explain plan on the original query.
Regards
Kuba

Index usage for retrieving data without filter predicate

Hi,
does someone have a explanation for the following scenario:
I have a table T1 with an index OID_IX on column ( object_id ) - The table is a CTAS from dba_objects just to populate it with data.
There are no other Indexes present. The table and the index are analyzed !
When I run the following query the table is accessed FULL ( not using the index )
SELECT OBJECT_ID FROM T1;
SQL> select object_id from t1;
485984 rows selected.
Elapsed: 00:00:01.76
Execution Plan
Plan hash value: 3617692013
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 485K| 2372K| 1528 (1)| 00:00:19 |
| 1 | TABLE ACCESS FULL| T1 | 485K| 2372K| 1528 (1)| 00:00:19 |
Statistics
1 recursive calls
0 db block gets
7396 consistent gets
0 physical reads
0 redo size
2887158 bytes sent via SQL*Net to client
5684 bytes received via SQL*Net from client
487 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
485984 rows processed
But if I add a predicate ( even though it is useless in this case ) the index is taken and the query runs faster:
JDBC@toekb> select object_id from t1 where object_id != -999;
485960 rows selected.
Elapsed: 00:00:01.40
Execution Plan
Plan hash value: 3555700789
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 485K| 2372K| 242 (3)| 00:00:03 |
|* 1 | INDEX FAST FULL SCAN| OID_IX | 485K| 2372K| 242 (3)| 00:00:03 |
Predicate Information (identified by operation id):
1 - filter("OBJECT_ID"<>(-999))
Statistics
1 recursive calls
0 db block gets
1571 consistent gets
0 physical reads
0 redo size
2766124 bytes sent via SQL*Net to client
5684 bytes received via SQL*Net from client
487 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
485960 rows processed
here my setup:
sqlsql--
drop table t1 purge ;
create table t1 tablespace users as select * from dba_objects;
insert into t1 ( select * from t1);
commit;
insert into t1 ( select * from t1);
commit;
insert into t1 ( select * from t1);
commit;
create index oid_ix on t1 (object_id) tablespace users ;
exec dbms_stats.gather_table_stats(null,'t1',cascade=>true, estimate_percent=>100);
sqlsql--
In my case the Table and Index looks this way:
JDBC@toekb> select table_name, NUM_ROWS,BLOCKS,AVG_SPACE from user_tables;
TABLE_NAME NUM_ROWS BLOCKS AVG_SPACE
=======================================
T1 485984 6944 0
Elapsed: 00:00:00.11
JDBC@toekb> select INDEX_NAME,BLEVEL,LEAF_BLOCKS,DISTINCT_KEYS,NUM_ROWS from user_indexes;
INDEX_NAME BLEVEL LEAF_BLOCKS DISTINCT_KEYS NUM_ROWS
===================================================
OID_IX 2 1074 60745 485960
Elapsed: 00:00:00.07
The table holds 7 times more blocks than the index !
any reply welcome
best regards
Edited by: guenterp on Aug 12, 2010 2:44 PM

guenterp wrote:
Hi,
does someone have a explanation for the following scenario:
I have a table T1 with an index OID_IX on column ( object_id ) - The table is a CTAS from dba_objects just to populate it with data.
There are no other Indexes present. The table and the index are analyzed !
When I run the following query the table is accessed FULL ( not using the index )
SELECT OBJECT_ID FROM T1;
SQL> select object_id from t1;
485984 rows selected.
Elapsed: 00:00:01.76
Execution Plan
Plan hash value: 3617692013
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 485K| 2372K| 1528 (1)| 00:00:19 |
| 1 | TABLE ACCESS FULL| T1 | 485K| 2372K| 1528 (1)| 00:00:19 |
Statistics
1 recursive calls
0 db block gets
7396 consistent gets
0 physical reads
0 redo size
2887158 bytes sent via SQL*Net to client
5684 bytes received via SQL*Net from client
487 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
485984 rows processed
But if I add a predicate ( even though it is useless in this case ) the index is taken and the query runs faster:
JDBC@toekb> select object_id from t1 where object_id != -999;
485960 rows selected.
Elapsed: 00:00:01.40
Execution Plan
Plan hash value: 3555700789
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 485K| 2372K| 242 (3)| 00:00:03 |
|* 1 | INDEX FAST FULL SCAN| OID_IX | 485K| 2372K| 242 (3)| 00:00:03 |
Predicate Information (identified by operation id):
1 - filter("OBJECT_ID"<>(-999))
Statistics
1 recursive calls
0 db block gets
1571 consistent gets
0 physical reads
0 redo size
2766124 bytes sent via SQL*Net to client
5684 bytes received via SQL*Net from client
487 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
485960 rows processed
here my setup:
sqlsql--
drop table t1 purge ;
create table t1 tablespace users as select * from dba_objects;
insert into t1 ( select * from t1);
commit;
insert into t1 ( select * from t1);
commit;
insert into t1 ( select * from t1);
commit;
create index oid_ix on t1 (object_id) tablespace users ;
exec dbms_stats.gather_table_stats(null,'t1',cascade=>true, estimate_percent=>100);
sqlsql--
In my case the Table and Index looks this way:
JDBC@toekb> select table_name, NUM_ROWS,BLOCKS,AVG_SPACE from user_tables;
TABLE_NAME NUM_ROWS BLOCKS AVG_SPACE
=======================================
T1 485984 6944 0
Elapsed: 00:00:00.11
JDBC@toekb> select INDEX_NAME,BLEVEL,LEAF_BLOCKS,DISTINCT_KEYS,NUM_ROWS from user_indexes;
INDEX_NAME BLEVEL LEAF_BLOCKS DISTINCT_KEYS NUM_ROWS
===================================================
OID_IX 2 1074 60745 485960
Elapsed: 00:00:00.07
The table holds 7 times more blocks than the index !
any reply welcome
best regards
Edited by: guenterp on Aug 12, 2010 2:44 PMSorry, but I am in doubt with your statists:
Statistics
1 recursive calls
0 db block gets
7396 consistent gets
0 physical reads ---->>>>>>>>>>>> Why it is 0 in any case(bnoth full scan and index FFS)
0 redo size
2887158 bytes sent via SQL*Net to client
5684 bytes received via SQL*Net from client
487 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
485984 rows processedCould you pls retry below operation before execuion of each sql:
alter system flush buffer_cache;In my case with 10.2.0.4 on HPUX:
SQL> exec dbms_stats.gather_table_stats(null,'t1',cascade=>true, estimate_percent=>100);
PL/SQL procedure successfully completed.
Elapsed: 00:00:03.61
SQL> alter system flush buffer_cache;
System altered.
Elapsed: 00:00:14.00
SQL> select * from t1;
82016 rows selected.
Elapsed: 00:00:06.48
Execution Plan
Plan hash value: 838529891
| Id | Operation         | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |      | 82016 | 6888K|   394   (1)| 00:00:05 |
|   1 | TABLE ACCESS FULL| T1   | 82016 | 6888K|   394   (1)| 00:00:05 |
Statistics
          0 recursive calls
          0 db block gets
       6455 consistent gets
       1039 physical reads
          0 redo size
    3480570 bytes sent via SQL*Net to client
      38508 bytes received via SQL*Net from client
       5469 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
      82016 rows processed
SQL> alter system flush buffer_cache;
System altered.
Elapsed: 00:00:18.26
SQL> select * from t1 where object_id !=999;
81976 rows selected.
Elapsed: 00:00:07.09
Execution Plan
Plan hash value: 838529891
| Id | Operation         | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |      | 81976 | 6884K|   394   (1)| 00:00:05 |
|* 1 | TABLE ACCESS FULL| T1   | 81976 | 6884K|   394   (1)| 00:00:05 |
Predicate Information (identified by operation id):
   1 - filter("OBJECT_ID"<>999)
Statistics
          0 recursive calls
          0 db block gets
       6443 consistent gets
       1039 physical reads
          0 redo size
    3478961 bytes sent via SQL*Net to client
      38494 bytes received via SQL*Net from client
       5467 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
      81976 rows processed
SQL>

Index usage with nls_sort and nls_comp

Hi,
I have created a logon trigger
CREATE OR REPLACE TRIGGER "SYS"."ON_LOGON_SET__SCHEMA" AFTER
LOGON ON DATABASE BEGIN
EXECUTE IMMEDIATE 'alter session set NLS_SORT=BINARY_CI';
EXECUTE IMMEDIATE 'alter session set NLS_COMP=LINGUISTIC';
EXCEPTION
WHEN OTHERS THEN NULL;
END;
because the user does not want case sensitive searches in the database.
However, when using this, Indexes on text fields are no longer used. What should I do with those indexes?
Regards

Possible answers explained in MOS GENERIC_BASELETTER Linguistic Definition [ID 109118.1] and Linguistic Sorting - Frequently Asked Questions [ID 227335.1] depending on what your users want to happen.

Index usage and nested views

We've got some performance problems when using a complex view that queries against a couple nested views.
We need to use views because we have two outer joins against the same table.
Here's a simplified version:
create or replace view_b as
select a1, b1, c1, d1
from table_c, table_d, view_a
where table_c.c1 = view_a.a1(+)
and table_c.c2= table_d.d1
create or replace view_a as
select a1
from table_a, table_b
where table_a.a1 = table_b.b1(+)
A query that may present problems with large amounts of data is:
select a1, b1
from view_b
where a1 = 1234;
Do indexes of nested views get utilized? Any suggestions?
Thanks

How selective is INSTRUMENT_ID? Is that a primary key? Or are there many rows in the INSTRUMENT table with an INSTRUMENT_ID of 1?
Are the statistics on your table and your index up to date? How, precisely, were statistics gathered?
What version of Oracle are you using? If you are using something earlier than 11.1, it's entirely possible that you have a bind variable peeking problem.
Realistically, you would want Oracle to use two different query plans for this statement depending on the value of the bind variable. If you pass in a NULL, you'd want Oracle to do a table scan. If you pass in a value, you'd want Oracle to do an index scan. Prior to 11.1, when this statement is first parsed, Oracle looks at the bind variable you passed in and picks the best plan for that bind variable value. When you subsequently execute this statement with other bind variable values, that first query plan is used. Thus, if the first time this code was executed you passed in a NULL, it would have made sense for Oracle to choose the table scan and all subsequent executions (until the query was aged out of the shared pool) would continue to use that query plan.
Oracle 11.1 introduced the ability to have multiple query plans for the same query depending on the bind variable values that were passed in which may well alleviate the problem you're seeing.
Justin

Index Usage

Similar Messages

Maybe you are looking for