Using Index

I am running a query against the table that has few million records using a column in where clause.The column has got low cardinality values (only 19 ) unique values of the millions of rows. i created a bit map index on the column. For what so ever reason the query does not use the index at all and the cost is way high in the Explain plan. I used hints to use index to improve the query which on the other hand increased the cost instead of reducing it. It looks like full table scans are lot better than indexed scans. Any suggestions on what could be done. It is a report and it needs to be tuned to reduced the execution time.
-- Bala

If the 19 distinct values are roughly equally likely, so any query is going to retrieve roughly 5% of the rows from the table, the CBO is likely to prefer a full-table scan because it is generally going to be quicker than doing single-block reads to get that volume of data back. If, on the other hand, the data is skewed so some values are more common that others, gathering histograms on the column and using literals rather than bind variables should allow the CBO to use an index where appropriate (i.e. to retrieve the less common results)
Presumably, you're not presenting 5% of a few million rows to users. You're probably aggregating those results somehow. In that case, you may be able to create a materialized view that does the aggregation and is refreshed after each load (ideally it would be fast-refreshable, but that depends on logistics).
Note as well that I'm assuming that you have some sort of data warehouse type system since you've created a bitmap index and bitmap indexes are generally incompatible with OLTP systems.
Justin

Similar Messages

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 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.

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

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]

How to know whether query is using Indexes in oracle?

Please let me know necessary steps to check whether query using indexes.

Try the below and check the explain plan.. See below explain plan using index marked as "RED" font
SET AUTOTRACE TRACEONLY EXPLAIN
SELECT * FROM emp WHERE empno = 7839;
Execution Plan
Plan hash value: 2949544139
| Id | Operation                   | Name   | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT            |        |     1 |    38 |     1   (0)| 00:00:01 |
|   1 | TABLE ACCESS BY INDEX ROWID| EMP    |     1 |    38 |     1   (0)| 00:00:01 |
|* 2 |   INDEX UNIQUE SCAN         | PK_EMP |     1 |       |     0   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - access("EMPNO"=7839)

Query not using indexes

select *
          from hrm_career x
          WHERE x.begin_date = ( SELECT MAX(begin_date)
                         FROM hrm_career y
                         WHERE y.employee_id = x.employee_id AND
                              begin_date <= SYSDATE AND
                              primary_job = 'Y') AND
               x.primary_job = 'Y'
I have the above query which is not using the index created on the BEGIN_DT column
I tried to force using still not using
but when i apply a value say
select *
          from hrm_career x
          WHERE x.begin_date ='10-20-2007'
It is using index and resulting in very fast response
Can some throw some ideas on it...
Where should i look into here ..

SQL> set autotrace traceonly
SQL> select *
2 from hrm_career x
3 WHERE x.begin_date = ( SELECT MAX(begin_date)
4 FROM hrm_career y
5 WHERE y.employee_id = x.employee_id AND
6 begin_date <= SYSDATE AND
7 primary_job = 'Y') AND
8 x.primary_job = 'Y';
13454 rows selected.
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=1417 Card=152 Bytes=
35568)
1 0 FILTER
2 1 SORT (GROUP BY) (Cost=1417 Card=152 Bytes=35568)
3 2 HASH JOIN (Cost=254 Card=47127 Bytes=11027718)
4 3 INDEX (FAST FULL SCAN) OF 'HRM_CAREER_PK' (UNIQUE) (
Cost=12 Card=25026 Bytes=500520)
5 3 TABLE ACCESS (FULL) OF 'HRM_CAREER' (Cost=81 Card=25
335 Bytes=5421690)
Statistics
3671 recursive calls
9 db block gets
1758 consistent gets
2130 physical reads
0 redo size
2217762 bytes sent via SQL*Net to client
10359 bytes received via SQL*Net from client
898 SQL*Net roundtrips to/from client
128 sorts (memory)
1 sorts (disk)
13454 rows processed
TKPROF
TKPROF: Release 9.2.0.6.0 - Production on Wed Dec 12 18:40:56 2007
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
Trace file: qnhg_ora_500.trc
Sort options: default
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
ALTER SESSION SET EVENTS '10046 trace name context forever, level 8'
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 0 0.00 0.00 0 0 0 0
total 1 0.00 0.00 0 0 0 0
Misses in library cache during parse: 0
Misses in library cache during execute: 1
Optimizer goal: CHOOSE
Parsing user id: 30 (ADMIN)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 1 0.00 0.00
SQL*Net message from client 1 34.45 34.45
select condition
from
cdef$ where rowid=:1
call count cpu elapsed disk query current rows
Parse 4 0.00 0.00 0 0 0 0
Execute 4 0.00 0.00 0 0 0 0
Fetch 4 0.00 0.00 0 8 0 4
total 12 0.00 0.00 0 8 0 4
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: SYS (recursive depth: 1)
Rows Row Source Operation
1 TABLE ACCESS BY USER ROWID CDEF$
select *
from hrm_career x
WHERE x.begin_date = ( SELECT MAX(begin_date)
FROM hrm_career y
WHERE y.employee_id = x.employee_id AND
begin_date <= SYSDATE AND
primary_job = 'Y') AND
x.primary_job = 'Y'
call count cpu elapsed disk query current rows
Parse 1 0.00 0.07 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 898 0.00 2.39 2038 946 9 13454
total 900 0.00 2.46 2038 946 9 13454
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 30 (ADMIN)
Rows Row Source Operation
13454 FILTER
25335 SORT GROUP BY
67496 HASH JOIN
25333 INDEX FAST FULL SCAN HRM_CAREER_PK (object id 25292)
25336 TABLE ACCESS FULL HRM_CAREER
Rows Execution Plan
0 SELECT STATEMENT GOAL: CHOOSE
13454 FILTER
25335 SORT (GROUP BY)
67496 HASH JOIN
25333 INDEX GOAL: ANALYZED (FAST FULL SCAN) OF 'HRM_CAREER_PK'
(UNIQUE)
25336 TABLE ACCESS GOAL: ANALYZED (FULL) OF 'HRM_CAREER'
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 898 0.00 0.00
SQL*Net more data to client 877 0.00 0.05
db file sequential read 1 0.01 0.01
db file scattered read 60 0.00 0.14
direct path write 9 0.00 0.00
direct path read 125 0.05 0.13
SQL*Net message from client 898 0.02 1.47
DELETE FROM PLAN_TABLE
WHERE
STATEMENT_ID=:1
call count cpu elapsed disk query current rows
Parse 2 0.00 0.00 0 0 0 0
Execute 2 0.00 0.00 0 6 6 6
Fetch 0 0.00 0.00 0 0 0 0
total 4 0.00 0.00 0 6 6 6
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 30 (ADMIN)
Rows Row Source Operation
0 DELETE
0 TABLE ACCESS FULL PLAN_TABLE
Rows Execution Plan
0 DELETE STATEMENT GOAL: CHOOSE
0 DELETE OF 'PLAN_TABLE'
0 TABLE ACCESS (FULL) OF 'PLAN_TABLE'
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 2 0.00 0.00
SQL*Net message from client 2 14.77 14.79
select o.owner#,o.name,o.namespace,o.remoteowner,o.linkname,o.subname,
o.dataobj#,o.flags
from
obj$ o where o.obj#=:1
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 1 0.00 0.00 0 3 0 1
total 3 0.00 0.00 0 3 0 1
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: SYS (recursive depth: 1)
EXPLAIN PLAN SET STATEMENT_ID='PLUS74964' FOR select *
from hrm_career x
WHERE x.begin_date = ( SELECT MAX(begin_date)
FROM hrm_career y
WHERE y.employee_id = x.employee_id AND
begin_date <= SYSDATE AND
primary_job = 'Y') AND
x.primary_job = 'Y'
call count cpu elapsed disk query current rows
Parse 1 0.00 0.01 0 4 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 0 0.00 0.00 0 0 0 0
total 2 0.00 0.01 0 4 0 0
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 30 (ADMIN)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 1 0.00 0.00
SQL*Net message from client 1 0.00 0.00
insert into plan_table (statement_id, timestamp, operation, options,
object_node, object_owner, object_name, object_instance, object_type,
search_columns, id, parent_id, position, other,optimizer, cost, cardinality,
bytes, other_tag, partition_start, partition_stop, partition_id,
distribution, cpu_cost, io_cost, temp_space, access_predicates,
filter_predicates )
values
(:1,SYSDATE,:2,:3,:4,:5,:6,:7,:8,:9,:10,:11,:12,:13,:14,:15,:16,:17,:18,:19,
:20,:21,:22,:23,:24,:25,:26,:27)
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 6 0.00 0.00 0 3 6 6
Fetch 0 0.00 0.00 0 0 0 0
total 7 0.00 0.00 0 3 6 6
Misses in library cache during parse: 1
Misses in library cache during execute: 2
Optimizer goal: CHOOSE
Parsing user id: 30 (ADMIN) (recursive depth: 1)
Rows Execution Plan
0 INSERT STATEMENT GOAL: CHOOSE
select o.name, u.name
from
sys.obj$ o, sys.user$ u where obj# = :1 and owner# = user#
call count cpu elapsed disk query current rows
Parse 1 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 1 0.00 0.00 0 0 0 0
Misses in library cache during parse: 1
Parsing user id: SYS (recursive depth: 1)
SELECT ID ID_PLUS_EXP,PARENT_ID PARENT_ID_PLUS_EXP,LPAD(' ',2*(LEVEL-1))
||OPERATION||DECODE(OTHER_TAG,NULL,'','*')||DECODE(OPTIONS,NULL,'','
('||OPTIONS||')')||DECODE(OBJECT_NAME,NULL,'',' OF '''||OBJECT_NAME||'''')
||DECODE(OBJECT_TYPE,NULL,'',' ('||OBJECT_TYPE||')')||DECODE(ID,0,
DECODE(OPTIMIZER,NULL,'',' Optimizer='||OPTIMIZER))||DECODE(COST,NULL,'','
(Cost='||COST||DECODE(CARDINALITY,NULL,'',' Card='||CARDINALITY)
||DECODE(BYTES,NULL,'',' Bytes='||BYTES)||')') PLAN_PLUS_EXP,OBJECT_NODE
OBJECT_NODE_PLUS_EXP
FROM
PLAN_TABLE START WITH ID=0 AND STATEMENT_ID=:1 CONNECT BY PRIOR ID=PARENT_ID
AND STATEMENT_ID=:1 ORDER BY ID,POSITION
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 0.00 0 22 0 6
total 4 0.00 0.00 0 22 0 6
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 30 (ADMIN)
Rows Row Source Operation
6 SORT ORDER BY
6 CONNECT BY WITH FILTERING
1 NESTED LOOPS
1 TABLE ACCESS FULL PLAN_TABLE
1 TABLE ACCESS BY USER ROWID PLAN_TABLE
5 NESTED LOOPS
6 BUFFER SORT
6 CONNECT BY PUMP
5 TABLE ACCESS FULL PLAN_TABLE
Rows Execution Plan
0 SELECT STATEMENT GOAL: CHOOSE
6 SORT (ORDER BY)
6 CONNECT BY (WITH FILTERING)
1 NESTED LOOPS
1 TABLE ACCESS (FULL) OF 'PLAN_TABLE'
1 TABLE ACCESS (BY USER ROWID) OF 'PLAN_TABLE'
5 NESTED LOOPS
6 BUFFER (SORT)
6 CONNECT BY PUMP
5 TABLE ACCESS (FULL) OF 'PLAN_TABLE'
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 2 0.00 0.00
SQL*Net message from client 2 0.09 0.09
SELECT ID ID_PLUS_EXP,OTHER_TAG OTHER_TAG_PLUS_EXP,OTHER OTHER_PLUS_EXP
FROM
PLAN_TABLE WHERE STATEMENT_ID=:1 AND OTHER_TAG IS NOT NULL ORDER BY ID
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 1 0.00 0.00 0 3 0 0
total 3 0.00 0.00 0 3 0 0
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 30 (ADMIN)
Rows Row Source Operation
0 SORT ORDER BY
0 TABLE ACCESS FULL PLAN_TABLE
Rows Execution Plan
0 SELECT STATEMENT GOAL: CHOOSE
0 SORT (ORDER BY)
0 TABLE ACCESS (FULL) OF 'PLAN_TABLE'
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 2 0.00 0.00
SQL*Net message from client 2 0.00 0.00
ALTER SESSION SET EVENTS '10046 trace name context off'
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 0 0.00 0.00 0 0 0 0
total 2 0.00 0.00 0 0 0 0
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 30 (ADMIN)
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 7 0.00 0.09 0 4 0 0
Execute 8 0.00 0.00 0 6 6 6
Fetch 901 0.00 2.39 2038 971 9 13460
total 916 0.00 2.49 2038 981 15 13466
Misses in library cache during parse: 6
Misses in library cache during execute: 1
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 906 0.00 0.00
SQL*Net message from client 906 34.45 50.82
SQL*Net more data to client 877 0.00 0.05
db file sequential read 1 0.01 0.01
db file scattered read 60 0.00 0.14
direct path write 9 0.00 0.00
direct path read 125 0.05 0.13
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 7 0.00 0.00 0 0 0 0
Execute 11 0.00 0.00 0 3 6 6
Fetch 5 0.00 0.00 0 11 0 5
total 23 0.00 0.00 0 14 6 11
Misses in library cache during parse: 4
Misses in library cache during execute: 2
9 user SQL statements in session.
6 internal SQL statements in session.
15 SQL statements in session.
5 statements EXPLAINed in this session.
Trace file: qnhg_ora_500.trc
Trace file compatibility: 9.02.00
Sort options: default
3 sessions in tracefile.
12 user SQL statements in trace file.
8 internal SQL statements in trace file.
15 SQL statements in trace file.
11 unique SQL statements in trace file.
5 SQL statements EXPLAINed using schema:
ADMIN.prof$plan_table
Default table was used.
Table was created.
Table was dropped.
3945 lines in trace file.
Message was edited by:
Maran Viswarayar

Creating a script for a PRIMARY KEY USING INDEX SORT doesn't work

Probably a bug.
h1. Environment
Application: Oracle SQL Developer Data Modeler
Version: 3.0.0.655
h1. Test Case:
1. Create a new table TRANSACTIONS with some columns.
2. Mark one of numeric columns as the primary key - PK_TRANSACTIONS.
3. Go to Physical Models and create new Oracle Database 11g.
4. Go to Physical Models -> Oracle Database 11g -> Tables -> TRANSACTIONS -> Primary Keys -> PK_TRANSACTIONS -> Properties:
a) on General tab set Using Index to BY INDEX NAME
b) on Using Index tab choose a tablespace
c) on Using Index tab set Index Sort to SORTED.
5. Export the schema to DDL script. For the primary key you will get something like this:
ALTER TABLE TRANSACTION
ADD CONSTRAINT PK_TRANSACTION PRIMARY KEY ( TRAN_ID ) DEFERRABLE
USING INDEX
PCTFREE 10
MAXTRANS 255
TABLESPACE TBSPC_INDX
LOGGING
STORAGE (
INITIAL 65536
NEXT 1048576
PCTINCREASE 0
MINEXTENTS 1
MAXEXTENTS 2147483645
FREELISTS 1
FREELIST GROUPS 1
BUFFER_POOL DEFAULT
) SORTED
h1. Reason of failure
The script will fail because SORTED is not allowed here. It should be SORT.
Additionally, the default behaviour for Data Modeler is to set Index Sort to NO but default setting for Oracle database 11g is SORT. Shouldn't Data Modeler use SORT as the default value?
Edited by: user7420841 on 2011-05-07 03:15

Hi,
Thanks for reporting this problem. As you say, it should be SORT rather than SORTED. I have logged a bug on this.
I also agree that, for consistency with the database default, it would be better to have SORT as the default in Data Modeler.
David

Query Uses Index in 8i but not in 9i

I have simple query which runs good in Oracle 8i. It uses index ,if i use = or in clause.
Same query is not using Index in Oracle 9i,(We made the the optimizer as choose) . If i remove in clause and make it = ,it is using index
select * from DWFE_ELE_CAT_ACC_HISTORY
where udc_acct_num in (Select z.LAH_CURR_LDC_ACCT_NUM
from DWFE_LDC_ACCT_HISTORY B,DWFE_LDC_ACCT_HISTORY z
Where B.LAH_CURR_LDC_ACCT_NUM ='0382900397'
and B.cpa_prem_num = Z.cpa_prem_num );

Plan for Oracle 8i
Execution Plan
0 SELECT STATEMENT Optimizer=RULE
1 0 NESTED LOOPS
2 1 VIEW OF 'VW_NSO_1'
3 2 REMOTE* RSSCP_DB
LINK
4 1 TABLE ACCESS (BY INDEX ROWID) OF 'CAT_TRANS_HISTORY'
5 4 INDEX (RANGE SCAN) OF 'IDX3_CAT_TRANS_HISTORY' (NON-UN
IQUE)
3 SERIAL_FROM_REMOTE SELECT /*+ */ DISTINCT "A1"."LAH_CURR_LDC_AC
CT_NUM" FROM "RSSC"."LDC_ACCT_HISTOR
Statistics
0 recursive calls
0 db block gets
8 consistent gets
0 physical reads
0 redo size
7827 bytes sent via SQL*Net to client
316 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
6 rows processed
Plan for Oracle 9i
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=12018 Card=67728 Byt
es=9752832)
1 0 HASH JOIN (Cost=12018 Card=67728 Bytes=9752832)
2 1 VIEW OF 'VW_NSO_1' (Cost=707 Card=17041 Bytes=238574)
3 2 REMOTE* RSSCP_DB
LINK
4 1 TABLE ACCESS (FULL) OF 'CAT_TRANS_HISTORY' (Cost=6204 Ca
rd=1905290 Bytes=247687700)
3 SERIAL_FROM_REMOTE SELECT /*+ */ "A1"."LAH_CURR_LDC_ACCT_NUM" F
ROM "RSSC"."LDC_ACCT_HISTORY" "A2","
Statistics
42 recursive calls
1 db block gets
41038 consistent gets
41010 physical reads
380 redo size
7833 bytes sent via SQL*Net to client
253 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
6 rows processed

Update databse from internal table statement not using index

Hi Guys,
We are updating a databse table from a file. The file has a couple of fields which have data different from what the database has (non-primary fields :). We upload the file data into an internal table and then update the database table from internal table. At a time, internal table is supposed to have 10,000 records. I did SQL trace and found that the update statement is not making use of the databse index.
Should not the update statement here be using the table index (for primary key)?
Regards,
Munish

... as often there are recommendations in this forum which makes me wonder, how people overestimate their knowledge!!!
Updates and Deletes do of course use indexes, as can be seen in the SQL Trace (use explain).
Inserts don't use indexes, because in many databases inserts are just done somewhere, But also with the INSERT, the primary key is the constraint for the uniqueness condition, duplicate keys are not allowed.
Coming to the original question, what is you actually coding for the update?
What is the table, which fields are in the internal table and what are the indexes?
Siegfried

How is it possible to use Index Seek for LIKE %search-string% case?

Hello,
I have the following SP:
CREATE PROCEDURE dbo.USP_SAMPLE_PROCEDURE(@Beginning nvarchar(15))
AS
SELECT * FROM HumanResources.Employee
WHERE NationalIDNumber LIKE @Beginning + N'%';
GO
If I run the sp first time with param: N'94', then the following plan is generated and added to the cache:
SQL Server "sniffs" the input value (94) when compiling the query. So for this param using Index Seek for AK_Employee_NationalIDNumber index will be the best option. On the other hand, the query plan should be generic enough to be able to handle
any values specified in the @Beginning param.
If I call the sp with @Beginning =N'%94':
EXEC dbo.USP_SAMPLE_PROCEDURE N'%94'
I see the same execution plan as above. The question is how is it possible to reuse this execution plan in this case? To be more precise, how
Index Seek can be used in case LIKE %search-string% case. I expected that
ONLY Index Scan operation can be used here.
Alexey

The key is that the index seek operator includes both seek (greater than and less than) and a predicate (LIKE). With the leading wildcard, the seek is effectively returning all rows just like a scan and the filter returns only rows matching
the LIKE expression.
Do you want to say that in case of leading wildcard, expressions Expr1007 and Expr1008 (see image below) calculated such a way that
Seek Predicates retrieve all rows from the index. And only
Predicate does the real job by taking only rows matching the Like expression? If this is the case, then it explains how
Index Seek can be used to resolve such queries: LIKE N'%94'.
However, it leads me to another question: Since
Index Seek in
this particular case scans
all the rows, what is the difference between
Index Seek and Index Scan?
According to
MSDN:
The Index Seek operator uses the seeking ability of indexes to retrieve rows from a nonclustered index.
The storage engine uses the index to process
only those rows that satisfy the SEEK:() predicate. It optionally may include a WHERE:() predicate, which the storage engine will evaluate against all rows that satisfy the SEEK:() predicate (it does not use the indexes to do this).
The Index Scan operator retrieves
all rows from the nonclustered index specified in the Argument column. If an optional WHERE:() predicate appears in the Argument column, only those rows that satisfy the predicate are returned.
It seems like Index Scan is a special case of Index Seek,
which means that when we see Index Seek in the execution plan, it does NOT mean that storage engine does NOT scan all rows. Right?
Alexey

CBO calculates un acceptable cost while using index.

Hi,
I was wondering to see the execution plan for both the case using index/without index.
We are using oracle 10G(10.2.0.3.0) with RAC in production at O/S:- sun solaris 10.
Java based application is running in this database. One of the sql query is taking long time to fetch the records. I analyzed the sql plan and noticed the FTS. I created indexes to the column(s) which is refering in where clauses. I noticed a strage behavior. Execution plan shows that the CBO is using right path but its not acceptable as application is time outs while return the rows.
first execution plan with/without index (not using the index).
PLAN_TABLE_OUTPUT
Plan hash value: 419342726
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 196 | 3332 | 67845 (3)| 00:13:35 |
|* 1 | TABLE ACCESS FULL | CWDBENUMDESCRIPTIONS | 1 | 35 | 3 (0)| 00:00:01 |
| 2 | SORT GROUP BY | | 196 | 3332 | 67845 (3)| 00:13:35 |
|* 3 | TABLE ACCESS FULL| CWORDERINSTANCE | 51466 | 854K| 67837 (3)| 00:13:35 |
Predicate Information (identified by operation id):
1 - filter("ERR"."CODE"=:B1)
3 - filter("OI"."ERROR_CODE" IS NOT NULL AND "OI"."DIVISION"='OR9' AND
"OI"."ACTIVE"=TO_NUMBER(:1) AND "OI"."ORDER_STATE"<>'O_NR_NS' AND
"OI"."ORDER_STATE"<>'C_C_QR' AND "OI"."ORDER_STATE"<>'O_NR_NS_D')
SQl query was modified to force the index to use /*+ index(oi oi_div) */ the execution is as below:-
PLAN_TABLE_OUTPUT
Plan hash value: 1157277132
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 196 | 3332 | 394K (1)| 01:18:52 |
|* 1 | TABLE ACCESS FULL | CWDBENUMDESCRIPTIONS | 1 | 35 | 3 (0)| 00:00:01 |
| 2 | SORT GROUP BY | | 196 | 3332 | 394K (1)| 01:18:52 |
|* 3 | TABLE ACCESS BY INDEX ROWID| CWORDERINSTANCE | 51466 | 854K| 394K (1)| 01:18:52 |
|* 4 | INDEX RANGE SCAN | OI_DIV | 3025K| | 14226 (1)| 00:02:51 |
Predicate Information (identified by operation id):
1 - filter("ERR"."CODE"=:B1)
3 - filter("OI"."ERROR_CODE" IS NOT NULL AND "OI"."ACTIVE"=TO_NUMBER(:1) AND
"OI"."ORDER_STATE"<>'O_NR_NS' AND "OI"."ORDER_STATE"<>'C_C_QR' AND
"OI"."ORDER_STATE"<>'O_NR_NS_D')
My questions are here:-
1). why FTS is less costly comparing index scan where there are 15000000 rows in the table.
2). while forcing index to use cost increase drastically (the statistics is latest one analyzed on 6th of feb 2009)
3). what should i suppose to change to get the performance benefit.
Thanks,
Pradeep

user587112 wrote:
select null, oi.division, oi.METADATATYPE, oi.ERROR_CODE,
       ( select err.DESCRIPTION
FROM   CWDBENUMDESCRIPTIONS err
WHERE oi.ERROR_CODE = err.CODE
count(*)
from CWORDERINSTANCE oi
where
     oi.ERROR_CODE is not null
      and oi.division in ('BK9')
     and oi.order_state not in ('O_NR_NS_D', 'C_C_QR', 'O_NR_NS')
      and oi.metadatatype = :1
     and oi.duedate>=:2
     and oi.active = :3
group by oi.division, oi.metadatatype, oi.error_code
order by oi.division, oi.metadatatype, oi.error_code
In this query, if we use as it is how its being displayed, it runs like a rocket, but if we change division in ('OR9') instead of 'BK9' it does not use index and leads to time out the application.
Number of records   division
1964690                             ---------------- why this field is null ?
3090666              OR9
3468                 BA9
1242                 EL9
2702                 IN9
258                  EU9
196198               DT9
1268                 PA9
8                    BK9
2332                 BH9
1405009              TP9
According to the stats in your original execution plan, it looks like you have a histogram on this column, and the index you want to use is on just the division column.
Oracle estimate for 'OR9' is 3M rowids from the index, resulting in 50,000+ rows from the table - that's a lot of work - it's not surprising that the optimizer chose a tablescan for 'OR9' - but chose to use the index for 'BK9' which has only 8 rows.
How often do you want to run this query ? And how accurate does the answer have to be ?
If you want this query to run faster even when it's processing a huge number of rows, one option would be to create a materialized view over the data that could supply the result set much more efficiently (possibly getting your front-end code to call a materialized view refresh before running the query).
The only other altenative is probably to create an index that covers all the columns in the query so that you don't have to visit the table - and if you order them correctly you won't have to do a sort group by. I think this index should do the trick: (division, metadatatype, error_code,active, duedate,orderstate). You could also compress this index on at least the first column, but possibly on far more columns, to minimise the size,
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
"The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge."
Stephen Hawking
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.

"Tables are not using indexes"-Please help

We have a new database , version
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bi
PL/SQL Release 10.2.0.1.0 - Production
CORE 10.2.0.1.0 Production
TNS for IBM/AIX RISC System/6000: Version 10.2.0.1.0 - Productio
NLSRTL Version 10.2.0.1.0 - Production
We have created Indexes for the tables and analysed the table. Problem is , non of the tables are using indexes. Explain paln for the sql queries are showing full table scan.
Kindly let me know any parameter I have to change or is there any setttings needed on database level?
Thanks in advance.
Regards,
Chotu

What is your optimizer mode?
Another question why you want to use indexes? Use of indexes depends,
Here is a simple example
test@>ed
Wrote file afiedt.buf
1 explain plan for
2 select c.cname from mytable c, mytable1 m
3* where c.cname=m.cname
test@>/
Explained.
test@>SELECT PLAN_TABLE_OUTPUT FROM TABLE(DBMS_XPLAN.DISPLAY());
PLAN_TABLE_OUTPUT
Plan hash value: 2460944079
| Id | Operation         | Name         | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |              |     8 |    64 |     1   (0)| 00:00:01 |
|   1 | NESTED LOOPS     |              |     8 |    64 |     1   (0)| 00:00:01 |
|   2 |   INDEX FULL SCAN | C_MYTAB_IDX |     8 |    32 |     1   (0)| 00:00:01 |
|* 3 |   INDEX RANGE SCAN| C_MYTAB1_IDX |     1 |     4 |     0   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   3 - access("C"."CNAME"="M"."CNAME")
15 rows selected.
test@>explain plan for
2 select * from mytable;
Explained.
test@>SELECT PLAN_TABLE_OUTPUT FROM TABLE(DBMS_XPLAN.DISPLAY());
PLAN_TABLE_OUTPUT
Plan hash value: 1229213413
| Id | Operation         | Name    | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |         |     8 |    32 |     3   (0)| 00:00:01 |
|   1 | TABLE ACCESS FULL| MYTABLE |     8 |    32 |     3   (0)| 00:00:01 |
8 rows selected.As you see MYTABLE has an index but it not always uses that index it depends on the need.
sql queries are showing full table scan this is a not a curse. So unless you are having some problem. You should not change queries only because to avoid full table scans, there is no rule that indexes should always be used in every case.
Adith

USING INDEXES DEFINED ON TABLES IN SELECT STATEMENTS

Hi there,
I would like to ask a simple question, how i can use indexes defined on certain columns on one of my database tables in a select clause:
table name: B2TECDOC
schema name: AWDBT1M4
indexes defined: AWDBT1M4.B2TECDOC_B2TECDOCKEY
index AWDBT1M4.B2TECDOC_B2TECDOCKEY is defined on columns:
documentname
documenttype
organizationid
organizationtype
revision
sequence
versionnumbercould you help me construct a select sql using this index?
another question is will using this index in my select clause increase the overall query performance?
thanks
rohan

A query like
SELECT *
FROM AWDBT1M4.B2TECDOC
WHERE documentname = <<some value>>
   AND documenttype = <<some value>
   AND organizationid = <<some value>>
   AND organizationtype = <<some value>>
   AND revision = <<some value>>
   AND sequence = <<some value>>
   AND versionnumber = <<some value>>should use the index.
An index is a more efficient way to access a relatively small fraction of the rows in the table. A table scan will be more efficient if you are trying to access a relatively large fraction of the rows in the table. Exactly what "small fraction" and "large fraction" means will depend on a variety of factors that the cost-based optimizer (CBO) attempts to evaluate in determing the query plan.
Justin

Using Index

Similar Messages

Maybe you are looking for