Index ignored by optimizer
Hi All,
I have a table with email id as one of the column. There is a query generated by packaged application to search email id's along with some other details.
This query has an in-definite elapsed time. After some research i found out that query is not using one of the index on email id column. hence i have hinted the index and the query elapsed time reduced to 1 minute.
But now the issue is i cannot implement hint since the query is generated dynamically from packaged application.
The stats are upto date and there exists a height based histogram on email id column. Even then the query is still not picking up the index.
How to help optimizer to choose the right index which was hinted?
Please help...
Thanks in advance
regards
sunil
PrafullaNath wrote:
If your optimizer is not using the index then you can think of setting the parameter "optimizer_index_cost_adj"
The optimizer_index_cost_adj parameter was created to allow use to change the relative costs of full-scan versus index operations. This is the most important parameter of all, and the default setting of 100 . For some OLTP systems, re-setting this parameter to a smaller value (between 10- to 30) may result in huge performance gains! and it will force to use the index.This is not good advice - the OP is not running Oracle 8i, and probably doesn't want to wreck the rest of his system just to improve the probability that one of his queries might go faster some of the time.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
Author: <b><em>Oracle Core</em></b>
Similar Messages
-
How to handle the MISSING STATISTICS:Table or Index has no optimizer stats
Dear All,
For some of our recently created Ztables, we have been receiving an error message of MISSING STATISTICS in the system saying that Table or Index has no optimizer statistics. To solve the problem, when I go for creating an index with the key fields of the table, I receive a message that these fields are already there in the index 0 (primary index).
Pls advice how to solve this issue.
Regards,
Alok.Hi friend,
Please delete all primary and secondary indexes and redo creation of index. Now u will surely be able to create it. -
This is probably a basic question about indexes, thanks for your insights.
I have a table VOUCHER with some columns including a TICKETNO column for which there is a primary key index, defined as follows:
CREATE UNIQUE INDEX VOUCHER_PK ON VOUCHER (TICKETNO)
The table contain approximately 20 million records.
We are using Oracle 9i RAC on HP-UX 11.11
I am running the following query, which runs for 20 minutes and then fails:
Oracle9i Enterprise Edition Release 9.2.0.8.0 - 64bit Production
With the Partitioning and Real Application Clusters options
JServer Release 9.2.0.8.0 - Production
SQL> select count(*) from VOUCHER
2 where TICKETNO between 100000 and 100100
3
SQL> /
select count(*) from VOUCHER
ERROR at line 1:
ORA-01555: snapshot too old: rollback segment number 741 with name
"_SYSSMU741$" too small
I am confused... Why counting 100 records with an indexed column takes so long and fail?Thanks for the feedback. I am going to run the ANALYZE suggestion tonight.
Here are the results of the queries asked for:
SELECT Table_Name, Status FROM User_Indexes WHERE Index_Name = 'VOUCHER_PK';
OWNER TABLE_NAME STATUS
SMVDBA VOUCHER VALID
SELECT Column_Name FROM User_Ind_Columns WHERE Index_Name = 'VOUCHER_PK';
COLUMN_NAME
TICKETNO
SELECT Last_Analyzed FROM User_Indexes WHERE Index_Name = 'VOUCHER_PK';
LAST_ANAL
SELECT Last_Analyzed FROM User_Tables WHERE Table_Name = 'VOUCHER';
LAST_ANAL
21-FEB-08
EXPLAIN PLAN FOR
select count(*) from VOUCHER
where TICKETNO between 100000 and 100100;
Explained
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY('', '', 'ALL'));
PLAN_TABLE_OUTPUT
| Id | Operation | Name | Rows | Bytes | Cost |
| 0 | SELECT STATEMENT | | | | |
| 1 | SORT AGGREGATE | | | | |
| 2 | TABLE ACCESS FULL | VOUCHER | | | |
Note: rule based optimization, PLAN_TABLE' is old version
10 rows selected.
EXPLAIN PLAN FOR
select /*+ INDEX(V VOUCHER_PK) */ count(*) from VOUCHER V
where TICKETNO between 100000 and 100100;
Explained.
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY('', '', 'ALL'));
PLAN_TABLE_OUTPUT
| Id | Operation | Name | Rows | Bytes | Cost |
| 0 | SELECT STATEMENT | | 1 | 18 | 5 |
| 1 | SORT AGGREGATE | | 1 | 18 | |
| 2 | INDEX FAST FULL SCAN| VOUCHER_PK | 83788 | 1472K| 5 |
Note: cpu costing is off, PLAN_TABLE' is old version
10 rows selected. -
BITMAP indexes ignored with large IN(...)
I have a fact table with 20 million records joined to a few dimension tables using 10g BITMAP INDEXes but if I add more than two or three items to my SELECT query the optimizer does not choose to use the bitmaps. For example, the first query
SELECT p.period_date, po.agent_id, count(*), SUM(ah.charge_amt)
FROM Travel_History ah, Period p, Agent po
WHERE ah.primary_agent_key = po.agent_key
AND ah.period_key = p.period_key
AND po.agent_id IN( 'DGF ', '001MG ' )
AND p.period_date =
TO_DATE( '20010701', 'YYYYMMDD' )
AND p.period_date =
TO_DATE( '20010801', 'YYYYMMDD' )
GROUP BY po.agent_id, p.period_date
definitely uses my BITMAPs as I see that in my EXECUTION PLAN (i.e. I have set autotrace on):
| 0 | SELECT STATEMENT | | 1 | 32
| 1 | HASH GROUP BY | | 1 | 32
|* 2 | FILTER | | |
| 3 | NESTED LOOPS | | 1 | 32
|* 4 | HASH JOIN | | 1 | 19
|* 5 | TABLE ACCESS FULL | PERIOD | 1 | 10
| 6 | TABLE ACCESS BY INDEX ROWID | TRAVEL_HISTORY | 4000K| 34
| 7 | BITMAP CONVERSION TO ROWIDS | | |
| 8 | BITMAP AND | | |
| 9 | BITMAP OR | | |
|* 10 | BITMAP INDEX SINGLE VALUE| XIF4TRAVEL_HISTORY | |
|* 11 | BITMAP INDEX SINGLE VALUE| XIF4TRAVEL_HISTORY | |
| 12 | BITMAP MERGE | | |
|* 13 | BITMAP INDEX RANGE SCAN | TRVLHIST_MULTI3_BMIX | |
|* 14 | BITMAP INDEX SINGLE VALUE | XIF1TRAVEL_HISTORY | |
|* 15 | TABLE ACCESS BY INDEX ROWID | AGENT | 1 | 13
|* 16 | INDEX UNIQUE SCAN | XPKAGENT | 1 |
There are only a few hundred records for those two dates, and the above query returns in
less than a second.
However, if I replace the two "period_date =" with IN(...) as:
SELECT /*+ INDEX_COMBINE( Travel_history
AcctHist_MULTI3_bmix
XIF4TRAVEL_HISTORY
XIF1TRAVEL_HISTORY )
p.period_date, po.agent_id, count(*), SUM(ah.charge_amt)
FROM Travel_History ah, Period p, Agent po
WHERE ah.primary_agent_key = po.agent_key
AND ah.period_key = p.period_key
AND po.agent_id IN( 'DGF ', '001MG ' )
AND p.period_date IN (
TO_DATE( '20010701', 'YYYYMMDD' ),
TO_DATE( '20010801', 'YYYYMMDD' ) )
GROUP BY po.agent_id, p.period_date
the execution plan goes back to
| 0 | SELECT STATEMENT | | 747 | 23904 | 45760 (7)|
| 1 | HASH GROUP BY | | 747 | 23904 | 45760 (7)|
|* 2 | FILTER | | | | |
|* 3 | HASH JOIN | | 5000K| 152M| 44897 (5)|
| 4 | MERGE JOIN CARTESIAN| | 860 | 19780 | 26 (0)|
|* 5 | TABLE ACCESS FULL | PERIOD | 4 | 40 | 6 (0)|
| 6 | BUFFER SORT | | 215 | 2795 | 20 (0)|
| 7 | TABLE ACCESS FULL | AGENT | 215 | 2795 | 5 (0)|
| 8 | TABLE ACCESS FULL | TRAVEL_HISTORY | 20M| 171M| 44527 (4)|
If I do a UNION with two SELECTs each with a unique period then the BITMAPs get used. I don't get it.
Is there any reason this would be happening???There are no bitmap indexes, there is a 64k tablespace header block containing the bitmap of occupied and free extents.
Sybrand Bakker
Senior Oracle DBA -
Help indexer ignors exactmatch.plist what can I do?
I am having two problems:
1. The terms in my exact match plist do not appear in my help index file after using help indexer (file viewed in Text Wrangler). All of the achors are listed.
2. Although my help book appears correctly in the help viewer, only my unique search terms, such as isaac or benny, are found and displyed after a search for help terms. Common terms, such as browse or paste which appear in other help books, are found and displyed for those apps, but not for mine.
I am using Xcode 4.2 but am targeting 10.6
Suggestions please.My last post did not contain enough background. I am completing an app "XSAVER" with the addition of the user help book accessed through the help menu. Everything works fine - the XSAVER help book appears properly the Apple HelpViewer - except for two problems with the Spotlight search in the viewer window.
My help book consists of the required folders and html, css, exact match plist and .helpindex files as listed in the Apple Help PG, Bill Cheesemen's book on Vermont Recipies, and the on-line book More Cocoa Programming. The book is indexed using the X-code 4.2 Help Indexer tool.
Problem 1. Although all of the terms and anchors in the html files are listed in the help index file (viewed in Text Wrangler), none of the terms in the ExactMatch.plist appear there.
Problem 2. I tested Spotlight search in the HelpViewer window against the terms that do appear in the .helpindex file. Common terms - such as copy, paste, cut - produce (0) hits for XSAVER but do produce multiple hits for Apple's and third party apps. On the other hand, terms that are unique to the XSAVER .helpindex file - such as pasty, benny, isaac - do produce hits for XSAVER and (0) hits for Apple's and other apps.
Has anyone experienced and solved these problems?
Thanks in advance -
SQL> CREATE table t (a VARCHAR2(10),b VARCHAR2(10))
2 /
Table created.
SQL> BEGIN
2 FOR i IN 1..10000
3 LOOP
4 INSERT INTO t VALUES (i,'A');
5 END LOOP;
6 END;
7 .
SQL> /
PL/SQL procedure successfully completed.
SQL> COMMIT;
Commit complete.
SQL> CREATE INDEX t_a_idx ON t (a)
2 /
Index created.
SQL> DESC emp
Name Null? Type
EMPNO NOT NULL NUMBER(4)
ENAME VARCHAR2(10)
JOB VARCHAR2(9)
MGR NUMBER(4)
HIREDATE DATE
SAL NUMBER(7,2)
COMM NUMBER(7,2)
DEPTNO NUMBER(2)
GRADE NUMBER
SQL> SELECT * FROM emp WHERE empno>500
2 /
Execution Plan
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=2 Card=14 Bytes=56
0)
1 0 TABLE ACCESS (BY INDEX ROWID) OF 'EMP' (TABLE) (Cost=2 Car
d=14 Bytes=560)
2 1 INDEX (RANGE SCAN) OF 'PK_EMP' (INDEX (UNIQUE)) (Cost=1
Card=14)
Above query is not ignoring the possibility of using an index on empno column,while the same query with table t
ignoring the usage of index on 'a' column why??
SQL> SELECT *
2 FROM t WHERE a>500
3 /
Execution Plan
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=6 Card=9500 Bytes=
133000)
1 0 TABLE ACCESS (FULL) OF 'T' (TABLE) (Cost=6 Card=9500 Bytes
=133000)
SQL> SELECT *
2 FROM t WHERE a>'500'
3 /
Execution Plan
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=6 Card=5552 Bytes=
77728)
1 0 TABLE ACCESS (FULL) OF 'T' (TABLE) (Cost=6 Card=5552 Bytes
=77728)KhurramWell, there are many issues with the test which you have posted here.
1. No statistics are collected after the table created, data inserted. Still, in your example it shows the cost, cardinality and bytes, unless you enable dynamic samplying parameter.
2. a VARCHAR2(10)
You have defined 'a' column as varchar datatype and ine one of your example you are using nubmber predicate value. Therefore, doing implicit conversion.
I have come across of this proble, like, why the hell my index ignored. Then understood the situation.
SQL> SELECT *
2 FROM t WHERE a>500
3 /
Lets take another example why index ignored,
SQL> SELECT *
2 FROM t WHERE a>'500'
3 /
column a has distinct values from 1 to 10000
formula for predicate selectity when there are no historgrams in place, as follows.
c1 > '4076' 1 - (High - Value / High - Low)
Apart from all, I dont believe in AUTOTRACE generated execution plan, it is not the real one, it is just predicated one.
If you are on >=9iR2, I strongly recommend you to use, DBMS_XPLAN.DISPLAY to get the execution plan.
Jaffar -
Hello,
I know that an "alter index X coalesce" optimizes the index X. But I want to optimize all indexes of a database but I don't want to write a script with some hundred alter index statements? Is there a smart way to do this like:
for i in indexes loop
alter index i coalesce;
commit;
end loop;
(Pseudocode)
Edited by: user9206958 on 01.04.2010 01:30Actually, no. If the following conditions are all true:
1.) Sequence generated key.
2.) Newest key values are inserted.
3.) Keys are updated over time.
4.) Oldest keys are deleted.
5.) Deletion doesn't skip any key values, leaving behind older key values forever.
If all the above is true, you should never need to coalesce or rebuild your indexes.
All the new key values go into the "Right hand" leaf block. On the left side, when the last key in a particular block is deleted, the empty block is left in the index structure and added back to the pool of free blocks. As a new block is needed on the right side, Oracle will grab the emptied block from the left side, unlink it from the structure, and move it to the right side.
So, in this way, blocks move from the left over to the right to be recycled. The only time this cannot happen is if some old values are left behind in the blocks on the left. (i.e. if item #5 above is not true.) If that's the case, there may be some benefit in periodic coalesces.
For more than you ever needed to know about indexes, how they work, and when index rebuilds are necessary, see Richard Foote's blog, and check out his white papers, especially "Rebuilding the Truth".
http://richardfoote.wordpress.com/
Hope that helps,
-Mark -
Question about the Query Optimizer
For an Excercise during my database lecture the following table
CREATE TABLE TASKS
"ID" NUMBER NOT NULL ENABLE,
"START_DATE" DATE,
"END_DATE" DATE,
"DESCRIPTION" VARCHAR2(50 BYTE)
) ;with about 1.5 Million Entries were given. In addition there was the following Query:
SELECT START_DATE, COUNT(START_DATE) FROM TASKS
GROUP BY START_DATE
ORDER BY START_DATE;And the Index:
create index blub on Tasks (start_date asc);The main excercise was to speed up queries with indexes. Because all data is accessed the optimizer ignores the index and just did a full table scan.
Here the QEP:
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 9343 | 74744 | 3423 (6)| 00:00:42 |
| 1 | SORT GROUP BY | | 9343 | 74744 | 3423 (6)| 00:00:42 |
| 2 | TABLE ACCESS FULL| TASKS | 1981K| 15M| 3276 (2)| 00:00:40 |
----------------------------------------------------------------------------Then we tried to force him to do the index with this query:
ALTER SESSION SET OPTIMIZER_MODE = FIRST_ROWS_1;
SELECT /* + INDEX (TASKS BLUB) */ START_DATE, COUNT(START_DATE) FROM TASKS
GROUP BY START_DATE
ORDER BY START_DATE;but again it ignored the index. The optimizer guide states clearly, that each time you access all data from a table it has to do a full scan.
So we tricked him in doing a fast index scan with this query:
create or replace function bla
return date deterministic is
ret date;
begin
select MIN(start_date) into ret from Tasks;
return ret;
end bla;
ALTER SESSION SET OPTIMIZER_MODE = FIRST_ROWS_1;
SELECT /* + INDEX (TASKS BLUB) */ START_DATE, COUNT(START_DATE) FROM TASKS
where start_date >= bla
GROUP BY START_DATE
ORDER BY START_DATE; now we got the following QEP:
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 8 | 3 (0)| 00:00:01 |
| 1 | SORT GROUP BY NOSORT| | 1 | 8 | 3 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | BLUB | 1 | 8 | 3 (0)| 00:00:01 |
----------------------------------------------------------------------------- So it do use the index.
Now to my two questions:
1. Why should it always do a full scan (because the optimizer documentation answer is a little bit unsatisfying)?
2. After looking at the difference between the costs (FS: 3276 IR: 3) and the time the system needs (FS: 9,6 sec IR: 4,45) why does the optimizer refuse the clearly better plan?
Thanks in advance,
Kai Gödde
Edited by: Kai Gödde on May 30, 2011 6:54 PM
Edited by: Kai Gödde on May 30, 2011 6:56 PMJohn Spencer mentioned already the most important point (the role of NULL values) but here are some minor additions:
* with the additional NOT NULL condition Oracle will do an INDEX FAST FULL SCAN (a multiblock scan of the index segment, similar to a FULL TABLE SCAN)
* with the additional NOT NULL condition you don't need a hint and Oracle will choose the IFFS access
* if the index was a bitmap index you would not need a NOT NULL condition because Oracle stores NULL-values in bitmap indexes (but you should not define bitmap indexes in an OLTP system because they bring massive locking issues)
* if the index would contain a second value the additional NOT NULL condition would also be needless
CREATE TABLE TASKS
"ID" NUMBER NOT NULL ENABLE,
"START_DATE" DATE,
"END_DATE" DATE,
"DESCRIPTION" VARCHAR2(50 BYTE)
insert into tasks
select rownum
, case when mod(rownum, 5) = 0 then null else sysdate - round(rownum/100) end
, case when mod(rownum, 4) = 0 then null else sysdate - round(rownum/50) end
, lpad('*', 50 , '*')
from dual
connect by level <= 1500000;
exec dbms_stats.gather_table_stats(user, 'TASKS')
-- the IFFS access without a hint:
create index blub on Tasks (start_date);
SELECT START_DATE
, COUNT(START_DATE)
FROM TASKS
WHERE START_DATE IS NOT NULL
GROUP BY START_DATE
ORDER BY START_DATE;
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 15001 | 102K| 1871 (16)| 00:00:10 |
| 1 | SORT GROUP BY | | 15001 | 102K| 1871 (16)| 00:00:10 |
|* 2 | INDEX FAST FULL SCAN| BLUB | 1200K| 8203K| 1631 (3)| 00:00:09 |
Statistiken
0 recursive calls
0 db block gets
3198 consistent gets
0 physical reads
0 redo size
378627 bytes sent via SQL*Net to client
11520 bytes received via SQL*Net from client
1002 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
15001 rows processed
-- the bitmap index
create bitmap index blub on tasks(START_DATE);
SELECT START_DATE
, COUNT(START_DATE)
FROM TASKS
GROUP BY START_DATE
ORDER BY START_DATE
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 15001 | 102K| 132 (1)| 00:00:01 |
| 1 | SORT GROUP BY NOSORT | | 15001 | 102K| 132 (1)| 00:00:01 |
| 2 | BITMAP CONVERSION TO ROWIDS| | 1500K| 10M| 132 (1)| 00:00:01 |
| 3 | BITMAP INDEX FULL SCAN | BLUB | | | | |
Statistiken
1 recursive calls
0 db block gets
1126 consistent gets
0 physical reads
0 redo size
378682 bytes sent via SQL*Net to client
11520 bytes received via SQL*Net from client
1002 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
15002 rows processed
-- the composite index
create index blub on tasks(START_DATE, 0);
SELECT START_DATE
, COUNT(START_DATE)
FROM TASKS
GROUP BY START_DATE
ORDER BY START_DATE;
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 15001 | 102K| 2400 (15)| 00:00:12 |
| 1 | SORT GROUP BY | | 15001 | 102K| 2400 (15)| 00:00:12 |
| 2 | INDEX FAST FULL SCAN| BLUB | 1500K| 10M| 2095 (3)| 00:00:11 |
Statistiken
0 recursive calls
0 db block gets
4120 consistent gets
0 physical reads
0 redo size
378682 bytes sent via SQL*Net to client
11520 bytes received via SQL*Net from client
1002 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
15002 rows processedRegards
Martin Preiss -
Hi All,
I have 3 indexes on a table. The first index is a combination of 8 columns, 2nd is a combination of 3 columns and the 3rd is a combination of only two columns.
What I want to know is that if I have to write a query joining two tables do I need to use the all of the indexed columns in the where clause to make it faster. Can I use any one of the indexed column for joins such that indexed scan happens.
Also I have seen that in some places oracle doesn't use the index I defined. Do anyone know what is the circumstance where Oracle ignores the index.
thanks...user627047 wrote:
Hi All,
I have 3 indexes on a table. The first index is a combination of 8 columns, 2nd is a combination of 3 columns and the 3rd is a combination of only two columns.
What I want to know is that if I have to write a query joining two tables do I need to use the all of the indexed columns in the where clause to make it faster. Can I use any one of the indexed column for joins such that indexed scan happens.
Your join needs to be written to satisfy the business logic of the query.
Also I have seen that in some places oracle doesn't use the index I defined. Do anyone know what is the circumstance where Oracle ignores the index.
Oracle will ignore the index when the optimizer determines that it is more expensive to use the index, or when the index cannot be used. An example of the first case is when it determines you will be retreiving so many rows that it makes more sense to just do a FTS than incur tha additional i/o of looking thing up in the index. An example of the second is where you reference an indexed column in your WHERE clause, but you applied a function to it:
SELECT *
FROM mytable
WHERE UPPER(indexed_col) = 'SOMEVALUE'In the above snippet, even the optimizer were to determine I'm only retreiving 1 row out of a million, the UPPER() function will prevent the use of the index.
thanks... -
how and when we create secondary indexes and what are the advantages and disadvantages of secondary indexes?
Hi
Index: Technical key of a database table.
Primary index: The primary index contains the key fields of the table and a pointer to the non-key fields of the table. The primary index is created automatically when the table is created in the database.
Secondary index: Additional indexes could be created considering the most frequently accessed dimensions of the table.
Structure of an Index
An index can be used to speed up the selection of data records from a table.
An index can be considered to be a copy of a database table reduced to certain fields. The data is stored in sorted form in this copy. This sorting permits fast access to the records of the table (for example using a binary search). Not all of the fields of the table are contained in the index. The index also contains a pointer from the index entry to the corresponding table entry to permit all the field contents to be read.
When creating indexes, please note that:
An index can only be used up to the last specified field in the selection! The fields which are specified in the WHERE clause for a large number of selections should be in the first position.
Only those fields whose values significantly restrict the amount of data are meaningful in an index.
When you change a data record of a table, you must adjust the index sorting. Tables whose contents are frequently changed therefore should not have too many indexes.
Make sure that the indexes on a table are as disjunctive as possible.
(That is they should contain as few fields in common as possible. If two indexes on a table have a large number of common fields, this could make it more difficult for the optimizer to choose the most selective index.)
Accessing tables using Indexes
The database optimizer decides which index on the table should be used by the database to access data records.
You must distinguish between the primary index and secondary indexes of a table. The primary index contains the key fields of the table. The primary index is automatically created in the database when the table is activated. If a large table is frequently accessed such that it is not possible to apply primary index sorting, you should create secondary indexes for the table.
The indexes on a table have a three-character index ID. '0' is reserved for the primary index. Customers can create their own indexes on SAP tables; their IDs must begin with Y or Z.
If the index fields have key function, i.e. they already uniquely identify each record of the table, an index can be called a unique index. This ensures that there are no duplicate index fields in the database.
When you define a secondary index in the ABAP Dictionary, you can specify whether it should be created on the database when it is activated. Some indexes only result in a gain in performance for certain database systems. You can therefore specify a list of database systems when you define an index. The index is then only created on the specified database systems when activated
Regards -
What is Short Dump Analysis and secendry index ?
Dear Experts .
1.) What is purpose of T-codes SE30 and ST22 ?
What is Short Dump Analysis ?
2.) What is secendry index , How to use it ? How it effects the Performance of a report ?
Please it is urgent ...
Regards : RajneeshHi
A dump analysis is a comprehensive list that should enable you to identify the causes and possible solutions of program errors. The ABAP Workbench generates a short dump whenever a report or transaction terminates due to a serious error. The system enters the error in the system log and writes a snapshot of the program at the moment when it terminated into a special database table called SNAP.
Dump analyses give the user or programmer information about the causes of the error that has caused the program to terminate. Experienced users can use them to identify very quickly where and why this occurred. He or she can them solve the problem.
The snapshot contains the following information:
Why the program has terminated
What caused the program termination
Where in the program code the termination occurred
What you can do to correct the error
The values of the relevant system fields when the program terminated
The calls or events that were active when the program terminated
Any other programs that are affected.
http://help.sap.com/saphelp_nw70/helpdata/en/c6/617d0ce68c11d2b2ab080009b43351/content.htm
Index: Technical key of a database table.
Primary index: The primary index contains the key fields of the table and a pointer to the non-key fields of the table. The primary index is created automatically when the table is created in the database.
Secondary index: Additional indexes could be created considering the most frequently accessed dimensions of the table.
Structure of an Index
An index can be used to speed up the selection of data records from a table.
An index can be considered to be a copy of a database table reduced to certain fields. The data is stored in sorted form in this copy. This sorting permits fast access to the records of the table (for example using a binary search). Not all of the fields of the table are contained in the index. The index also contains a pointer from the index entry to the corresponding table entry to permit all the field contents to be read.
When creating indexes, please note that:
An index can only be used up to the last specified field in the selection! The fields which are specified in the WHERE clause for a large number of selections should be in the first position.
Only those fields whose values significantly restrict the amount of data are meaningful in an index.
When you change a data record of a table, you must adjust the index sorting. Tables whose contents are frequently changed therefore should not have too many indexes.
Make sure that the indexes on a table are as disjunctive as possible.
(That is they should contain as few fields in common as possible. If two indexes on a table have a large number of common fields, this could make it more difficult for the optimizer to choose the most selective index.)
Accessing tables using Indexes
The database optimizer decides which index on the table should be used by the database to access data records.
You must distinguish between the primary index and secondary indexes of a table. The primary index contains the key fields of the table. The primary index is automatically created in the database when the table is activated. If a large table is frequently accessed such that it is not possible to apply primary index sorting, you should create secondary indexes for the table.
The indexes on a table have a three-character index ID. '0' is reserved for the primary index. Customers can create their own indexes on SAP tables; their IDs must begin with Y or Z.
If the index fields have key function, i.e. they already uniquely identify each record of the table, an index can be called a unique index. This ensures that there are no duplicate index fields in the database.
When you define a secondary index in the ABAP Dictionary, you can specify whether it should be created on the database when it is activated. Some indexes only result in a gain in performance for certain database systems. You can therefore specify a list of database systems when you define an index. The index is then only created on the specified database systems when activated -
Secondary Index Select Statement Problem
Hi friends.
I have a issue with a select statement using secondary index,
SELECT SINGLE * FROM VEKP WHERE VEGR4 EQ STAGE_DOCK
AND VEGR5 NE SPACE
AND WERKS EQ PLANT
%_HINTS ORACLE
'INDEX("&TABLE&" "VEKP~Z3" "VEKP^Z3" "VEKP_____Z3")'.
given above statement is taking long time for processing.
when i check for the same secondary index in vekp table i couldn't see any DB index name with vekp~z3 or vekp^z3 or vekp____z3.
And the sy-subrc value after select statement is 4. (even though values avaliable in VEKP with given where condition values)
My question is why my select statement is taking long time and sy-subrc is 4?
what happens if a secnodary index given in select statement, which is not avaliable in that DB Table?Hi,
> ONe more question: is it possible to give more than one index name in select statement.
yes you can:
read the documentation:
http://download.oracle.com/docs/cd/A97630_01/server.920/a96533/hintsref.htm#5156
index_hint:
This hint can optionally specify one or more indexes:
- If this hint specifies a single available index, then the optimizer performs
a scan on this index. The optimizer does not consider a full table scan or
a scan on another index on the table.
- If this hint specifies a list of available indexes, then the optimizer
considers the cost of a scan on each index in the list and then performs
the index scan with the lowest cost. The optimizer can also choose to
scan multiple indexes from this list and merge the results, if such an
access path has the lowest cost. The optimizer does not consider a full
table scan or a scan on an index not listed in the hint.
- If this hint specifies no indexes, then the optimizer considers the
cost of a scan on each available index on the table and then performs
the index scan with the lowest cost. The optimizer can also choose to
scan multiple indexes and merge the results, if such an access path
has the lowest cost. The optimizer does not consider a full table scan.
Kind regards,
Hermann -
Can we associate index with foreign key?
hello
i have searched and could not find the answer to the above;
i have a foreign key constraint on the tables; i added an index on that column as well;
however when i query the all_constraints, under index_name for this foreign constraint there is nothing; only when i have PK/UK i case see indexes associated with them;
will then oracle still associate my index with the FK constrained column? or i need to excplicity associate it with the foreign key column? if so, how to do that?
thx
rgdsHi,
UserMB wrote:
i have a foreign key constraint on the tables; i added an index on that column as well;It helps if you give a specific example, such as:
"I have a foreign key constraint, where emp.deptno references dept.deptno. (Deptno is the primary key of dept.) I created an index called emp_deptno_idx on emp.deptno as well."
however when i query the all_constraints, under index_name for this foreign constraint there is nothing; only when i have PK/UK i case see indexes associated with them;Not all indexes are associated with a constraint. In the example above, you wouldn't expect to see anything about the index emp_demptno_idx in all_constraints or in all_cons_columns.
will then oracle still associate my index with the FK constrained column? or i need to excplicity associate it with the foreign key column? if so, how to do that?In the situation above, Oracle will still use the index when the optimizer thinks it will help. You don't have to do anything else. -
FUNCTION-BASED INDEX ( ORACLE 8I NEW FEATURE )
제품 : ORACLE SERVER
작성날짜 : 2004-08-16
FUNCTION-BASED INDEX ( ORACLE 8I NEW FEATURE )
==============================================
SCOPE
10g Standard Edition(10.1.0) 이상 부터 Function-based Index 기능이 지원된다.
Explanation
1. 개요
Function-based index는, 함수(function)이나 수식(expression)으로 계산
된 결과에 대해 인덱스를 생성하여 사용할 수 있는 기능을 제공한다.
질의 수행 시 해당 함수나 수식을 처리하여 결과를 가져 오는 것이 아니라,
인덱스 형태로 존재하는 미리 계산되어 있는 결과를 가지고 처리하므로
성능 향상을 기할 수 있다.
2. 제약사항
1) aggregate function 에 대한 function-based index 생성 불가.
(예 : sum(...) )
2) LOB, REF, nested table 컬럼에 대한 function-based index 생성 불가.
3. 주요 특징
1) cost-based optimizer에 의해 사용됨.
2) B*Tree / bitmap index로 생성 가능.
3) 산술식 (arithmetic expression), PLSQL function, SQL built-in
function 등에 적용 가능.
4) 함수나 수식으로 처리된 결과에 대한 range scan 가능
5) NLS SORT 지원
6) SELECT/DELETE를 할 때마다 함수나 수식의 결과를 계산하는 것이 아니라
INSERT/UPDATE 시 계산된 값을 인덱스에 저장.
7) 질의 속도 향상
8) object column이나 REF column에 대해서는 해당 object에 정의된
method에 대해 function-based index 생성 가능.
4. 생성 방법
CREATE [UNIQUE | BITMAP ] INDEX <index_name>
ON <tablename> (<index-expression-list>)
<index-expression-list> -> { <column_name> | <column_expression> }
예) CREATE INDEX EMP_NAME_INDEX ON EMP (UPPER(ENAME));
CREATE INDEX EMP_SAL_INDEX ON EMP( SAL + COMM, empno);
* Function-based index를 생성하기 위해서는 QUERY REWRITE 권한이
부여 되어 있어야만 한다.
예) GRANT QUERY REWRITE TO SCOTT;
5. Function-Based Index 사용을 위한 사전 작업
1) Function-based index는 cost based optimizer에서만 사용 가능하므로,
테이블에 대해 미리 analyze 해 주는 것이 바람직하다.
그리고 init 파일에서 OPTIMIZER_MODE 를 FIRST_ROWS 나 ALL_ROWS 등으
로 지정하거나 HINT 등을 사용하여 cost based optimizer가 사용되도록
한다.
2) init 파일에서 COMPATIBLE 파라미터 값을 8.1 이상으로 설정되어 있어야
한다.
( 예 : COMPATIBLE = 8.1.6 )
3) session/instance level 에서 QUERY_REWRITE_ENABLED 값이 TRUE 지정
되어 있어야 한다.
( 예 : ALTER SESSION SET QUERY_REWRITE_ENABLED = TRUE; )
6. 예제
1) init 파라미터에서 다음과 같이 지정
compatible = 8.1.6 (반드시 8.1이상이어야 한다)
query_rewrite_enabled = true
query_rewrite_integrity = trusted
2) SCOTT 유저에서 function_based_index 생성
create index idx_emp_lower_ename
on emp
( lower(ename) ) ;
3) EMP table analyze
analyze table emp compute statistics ;
4) PLAN_TABLE 생성
@ ?/rdbms/admin/utlxplan.sql
5) Cost based optimizer 선택
alter session set optimizer_mode = FIRST_ROWS ;
6) Query 실행
explain plan set statement_id='qry1' FOR
select empno, ename
from emp
where lower(ename) = 'ford' ;
7) PLAN 분석
SELECT LPAD(' ',2*level-2)||operation||' '||options||' '||object_name query_plan
FROM plan_table
WHERE statement_id='qry1'
CONNECT BY prior id = parent_id
START WITH id = 0 order by id ;
-> 결과
QUERY_PLAN
SELECT STATEMENT
TABLE ACCESS BY INDEX ROWID EMP
INDEX RANGE SCAN IDX_EMP_LOWER_ENAME
7. 결론
Function-based index는 적절하게 사용될 경우 성능상의 많은 이점을 가져
온다. Oracle8i Designing and Tuning for Performance에서도 가능한 한
Function-based index를 사용하는 것을 권장하고 있으며, LOWER(), UPPER()
등의 함수를 사용하여 불가피하게 FULL TABLE SCAN을 하는 경우에 대해서도
효과적으로 처리해 줄 수 있는 방안이라 할 수 있다.
Reference Documents
-------------------Partha:
From the Oracle8i Administrators Guide:
"Table owners should have EXECUTE privileges on the functions used in function-based indexes.
For the creation of a function-based index in your own schema, you must be
granted the CREATE INDEX and QUERY REWRITE system privileges. To create
the index in another schema or on another schemas tables, you must have the
CREATE ANY INDEX and GLOBAL QUERY REWRITE privileges."
Hope this helps.
Peter -
Select query with secondary index
hi,
i have a report which is giving performance issues on a perticular select query on KONH table.
the select query doesnt use the primary key fields and table already has around 19 million entries.So there was a secondary index created for the fields in the table.
now, KONH is a client specific table, and hence has MANDT as the first field. when the table is not indexed it is sorted according to the order of fields, like first MANDT, then primary key fields and then remaining fields.. (correct me if i am wrong)
but the secondary index created doesnt has MANDT in it..(yea, a mistake! )...
but instead of correccting the secondary index, i am told to change the select query..
so, i used a "client specific" syntax to sort the issue.. but i dont understand whre i should put the "where mandt eq sy-mandt" clause..
should i put it right after all my secondary index fields are over? or what happens to the order of fields which are not present in the list of secondary index?
kindaly help.
thanx.Hi chinmay kulkarni,
its better if you can ask concerned person to add MANDT field in your index as well....
Indexes and MANDT
If a table begins with the mandt field, so should its indexes. If a table begins with mandt and an index doesn't, the optimizer might not use the index.
Remember, if you will, Open SQL's automatic client handling feature. When select * from ztxlfa1 where land1 = 'US' is executed, the actual SQL sent to the database is select * from ztxlfa1 where mandt = sy-mandt and land1 = 'US'. Sy-mandt contains the current logon client. When you select rows from a table using Open SQL, the system automatically adds sy-mandt to the where clause, which causes only those rows pertaining to the current logon client to be found.
When you create an index on a table containing mandt, therefore, you should also include mandt in the index. It should come first in the index, because it will always appear first in the generated SQL.
Index: Technical key of a database table.
Primary index: The primary index contains the key fields of the table and a pointer to the non-key fields of the table. The primary index is created automatically when the table is created in the database.
Secondary index: Additional indexes could be created considering the most frequently accessed dimensions of the table.
Structure of an Index
An index can be used to speed up the selection of data records from a table.
An index can be considered to be a copy of a database table reduced to certain fields. The data is stored in sorted form in this copy. This sorting permits fast access to the records of the table (for example using a binary search). Not all of the fields of the table are contained in the index. The index also contains a pointer from the index entry to the corresponding table entry to permit all the field contents to be read.
When creating indexes, please note that:
An index can only be used up to the last specified field in the selection! The fields which are specified in the WHERE clause for a large number of selections should be in the first position.
Only those fields whose values significantly restrict the amount of data are meaningful in an index.
When you change a data record of a table, you must adjust the index sorting. Tables whose contents are frequently changed therefore should not have too many indexes.
Make sure that the indexes on a table are as disjunctive as possible.
(That is they should contain as few fields in common as possible. If two indexes on a table have a large number of common fields, this could make it more difficult for the optimizer to choose the most selective index.)
For Example...
SELECT KUNNR KUNN2 INTO TABLE T_CUST_TERR
FROM KNVP CLIENT SPECIFIED
WHERE MANDT = SY-MANDT " here MANDT shd be first
AND KUNN2 IN S_TERR
AND PARVW LIKE 'Z%'.
Accessing tables using Indexes
The database optimizer decides which index on the table should be used by the database to access data records.
You must distinguish between the primary index and secondary indexes of a table. The primary index contains the key fields of the table. The primary index is automatically created in the database when the table is activated. If a large table is frequently accessed such that it is not possible to apply primary index sorting, you should create secondary indexes for the table.
The indexes on a table have a three-character index ID. '0' is reserved for the primary index. Customers can create their own indexes on SAP tables; their IDs must begin with Y or Z.
If the index fields have key function, i.e. they already uniquely identify each record of the table, an index can be called a unique index. This ensures that there are no duplicate index fields in the database.
When you define a secondary index in the ABAP Dictionary, you can specify whether it should be created on the database when it is activated. Some indexes only result in a gain in performance for certain database systems. You can therefore specify a list of database systems when you define an index. The index is then only created on the specified database systems when activated
Also pls have a look on below link
http://www.sapfans.com/sapfans/forum/devel/messages/30240.html
Hope it will solve your problem..
Reward points if useful...
Thanks & Regards
ilesh 24x7
Maybe you are looking for
-
Vendor/Customer balance confirmation prints
Hi, when we want to print vendor/customer balance confirmations, transactions f.18/f.17 always print: - form set - reconciliation list - results table - if there is some error - error list We want to restrict the printing only to FORM SET and we DO N
-
Uploading of Budget Volume in SAP
Dear All, I want to upload the budgeted sales quantity data in SAP. The sale quantity budget varies from one location to another on a monthly basis and we have got 1000 such locations from where we have to sell. Can anyone help with the procedure for
-
Why does one of site pages show up as index in my reports?
Why does one of site pages show up as index in my reports?
-
I've had to reinstall everything on my Macbook and now I try to plug in my iphone4 and itunes doesn't see it. The phone "knows" it's plugged in because it makes the noise when I plug it in. Any tips on how I can fix this? Thanks
-
Is there anything I've endnote for pages?