Does this query need function based index?

Hello All,
I have a strange problem. I have a table DM_T_CLEAN_EXCEPTION_LOG and I am doing a query in reports as follows:
select COUNT(*) NO_OF_ALL_RECORDS
FROM DM_T_CLEAN_EXCEPTION_LOG
WHERE CREATE_DATE > to_date(to_char(sysdate -1 ,'dd-mon-yyyy') || ' 05:00:00PM' ,'dd-mon-yyyy hh:mi:sspm')
AND EXCEPTION_SEVERITY = :EXCEPTION_SEVERITY
AND EXCEPTION_DESCRIPTION = :EXCEPTION_DESCRIPTION
Now I created indexes on CREATE_DATE, EXCEPTION_SEVERITY and EXCEPTION_DESCRIPTION. It says Index Skip Scan so I think it is slow. I tried even creating function based index on create_date using the to_date(to_char(create_date,'dd-mon-yyyy') but then it does a full table scan. Can anyone tell me what is the right way in this situation?
Thanks

It says Index Skip Scan so I think it is slow.Is it really slow or do you only think that it is slow ?
If it is slow, please show us the explain plan with cardinalities, so we can figure out if an index on (exception_severity,exception_description,create_date) is more beneficial than your current one on (create_date,exception_severity,exception_description).
Regards,
Rob.

Similar Messages

Function Based Index on Date Column

Hi All,
I need to execute a query like this :
SELECT * FROM ORDERS WHERE APPROVE_DATE IS NULL
I read anywhere that this will cause unnecessary FTS so that I should create function based index.
I have tried one below , but not sure that this is correct approach :
CREATE INDEX idx_1
ON ORDERS (NVL(APPROVE_DATE, '01-JAN-1900'));
SELECT * FROM ORDERS WHERE NVL(APPROVE_DATE, '01-JAN-1900') = '01-JAN-1900'
Is this a correct approach ?
Thank you,
xtanto

A SQL_TRACE output will explain clearly what Justin has stated.
I have created a table T based on all_objects.
SQL> desc t
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                                            DATE
LAST_DDL_TIME                             NOT NULL DATE
TIMESTAMP                                          VARCHAR2(19)
STATUS                                             VARCHAR2(7)
TEMPORARY                                          VARCHAR2(1)
GENERATED                                          VARCHAR2(1)
SECONDARY                                          VARCHAR2(1)
CASE I_
SQL> select count(1) from t
2 /
COUNT(1)
    934320
SQL> select count(1) from t where created is null
2 /
COUNT(1)
      2376The number of null values in CREATED column is proportionately very small.
Now i execute the query without function based index.
select *
from t
where created is null
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.09          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch      160      0.04       0.10          0      12662          0        2376
total      162      0.04       0.19          0      12662          0        2376
Rows     Execution Plan
      0 SELECT STATEMENT   GOAL: ALL_ROWS
   2376   TABLE ACCESS   GOAL: ANALYZED (FULL) OF 'T' (TABLE)And here is the query that uses the function based index
select *
from t
where nvl(created,to_date('01-01-1900','DD-MM-YYYY')) = to_date('01-01-1900','DD-MM-YYYY')
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.01       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch      160      0.01       0.01          0        698          0        2376
total      162      0.03       0.01          0        698          0        2376
Rows     Execution Plan
      0 SELECT STATEMENT   GOAL: ALL_ROWS
   2376   TABLE ACCESS   GOAL: ANALYZED (BY INDEX ROWID) OF 'T' (TABLE)
   2376    INDEX   GOAL: ANALYZED (RANGE SCAN) OF 'T_FN_IDX' (INDEX)Its very obvious from the above output that the Function Based Index as increased the performance.
CASE II_
SQL> select count(1) from t
2 /
COUNT(1)
    934320
SQL> select count(1) from t where created is null
2 /
COUNT(1)
    202168Now the null values in the CREATED column is proportionately large than the first test case.
Now lets see without using the function based index
select *
from t
where created is null
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    13479      0.46       0.71          2      25832          0      202168
total    13481      0.46       0.71          2      25832          0      202168
Rows     Execution Plan
      0 SELECT STATEMENT   GOAL: ALL_ROWS
202168   TABLE ACCESS   GOAL: ANALYZED (FULL) OF 'T' (TABLE)Now iam trying to use the function based index
select *
from t
where nvl(created,to_date('01-01-1900','DD-MM-YYYY')) = to_date('01-01-1900','DD-MM-YYYY')
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    13479      0.54       0.84          0      33826          0      202168
total    13481      0.54       0.84          0      33826          0      202168
Rows     Execution Plan
      0 SELECT STATEMENT   GOAL: ALL_ROWS
202168   TABLE ACCESS   GOAL: ANALYZED (FULL) OF 'T' (TABLE)Its obvious from the result that oracle has decided to go for a FULL TABLE SCAN even when an index was available.
So just having a function based index is not going to increase the query performance. There are lot of other factors to be considered as stated above.
Thanks,
Karthick.

Why do we need query rewrite enabled for a function-based index?

Oracle 9i
========
I have searched a few sites but could not find any content on it. The question is why do we need to implement query rewrite enabled when we are trying out a function-based index?
Thanks in advance.

You don't, that's a legacy requirement from the early days of function based indexes in Oracle 8i. Here's a quick example running under 9.2.0.6
drop table t1;
create table t1 as
select
from
     all_objects
where
     rownum <= 30000
create or replace function pl_func(i_vc     varchar2)
return varchar2
deterministic
as
begin
     return soundex(i_vc);
end;
-- set the worst case scenario
alter session set query_rewrite_enabled = false;
alter session set query_rewrite_integrity = enforced;
create index t1_i1 on t1(pl_func(object_name));
execute dbms_stats.gather_table_stats(user, 't1')
set autotrace traceonly explain
select
     object_name
from t1
where pl_func(object_name) = 'T513'
set autotrace offResults (after set feedback off)
SQL> @temp
Execution Plan
Plan hash value: 1429545322
| Id | Operation                   | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT            |       |    27 |   675 |    10   (0)| 00:00:01 |
|   1 | TABLE ACCESS BY INDEX ROWID| T1    |    27 |   675 |    10   (0)| 00:00:01 |
|* 2 |   INDEX RANGE SCAN          | T1_I1 |    27 |       |     1   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - access("TEST_USER"."PL_FUNC"("OBJECT_NAME")='T513')
SQL> spool offRegards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk

Query not considering function based index in oracle 11g

I have a query which used Function Based Index when run in oracle 9i but when I run the same query
without any changes, it does not consider index. Below is the query:
SELECT distinct patient_role.domain_key, patient_role.patient_role_key,
patient_role.emergency_contact_name,
patient_role.emergency_contact_phone, patient_role.emergency_contact_note,
patient_role.emergency_contact_relation_id,
patient_role.financial_class_desc_id, no_known_allergies, patient_role.CREATED_BY,
patient_role.CREATED_TIMESTAMP,
patient_role.CREATED_TIMESTAMP_TZ, patient_role.UPDATED_BY, patient_role.UPDATED_TIMESTAMP,
patient_role.UPDATED_TIMESTAMP_TZ,
patient_role.discontinued_date
FROM encounter, patient_role
WHERE patient_role.patient_role_key = encounter.patient_role_key
AND UPPER(TRIM(leading :SYS_B_0 from encounter.account_number)) = UPPER(TRIM(leading :SYS_B_1 from
:SYS_B_2))
AND patient_role.discontinued_date IS null
AND encounter.discontinued_date IS null ;
Index definition:
CREATE INDEX "user1"."IX_TRIM_ACCOUNT_NUMBER" ON "user1."ENCOUNTER" (UPPER(TRIM(LEADING
'0' FROM "ACCOUNT_NUMBER")), "PATIENT_ROLE_KEY", "DOMAIN_KEY", "DISCONTINUED_DATE")
PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1
BUFFER_POOL DEFAULT)
TABLESPACE "user1"
Database : Oracle 11g (11.2.0.3)
O/S : Linux 64 bit (the query does not consider index even on windows os)
Any suggestions?
-Onkar
Edited by: onkar.nath on Jul 2, 2012 3:32 PM

Onkar,
I don't appreciate you posting this question in several forums at the same time.
If I would know you also posted this on Asktom, I wouldn't even have bothered.
As to your 'issue':
First of all: somehow cursor_sharing MUST have been set to FORCE. Oracle is a predictable system, not a fruitmachine.
Your statement the '0' is replaced by a bind variable anyway is simply false. If you really believe it is not false, SUBMIT a SR.
But your real issue is not Oracle: it is your 'application', which is a mess anyway. Allowing for alphanumeric numbers is a really bad idea.
Right now you are already putting workaround on workaround on workaround on workaround.
Issue is the application: it is terminal., and you either need to kill it, or to replace it.
Sybrand Bakker
Senior Oracle DBA

Function based indexes doing full table scan

Guys,
I am testing function based indexes and whatever I do
it is doing a full table scan.
1)I have set the following init parameters as
QUERY_REWRITE_ENABLED=TRUE
QUERY_REWRITE_INTEGRITY=TRUSTED
2)CREATE INDEX i3 ON emp(UPPER(ename));
3) ANALYZE TABLE emp COMPUTE STATISTICS
ANALYZE INDEX I3 COMPUTE STATISTICS
4) DELETE plan_table;
5) EXPLAIN PLAN SET statement_id='Test1' FOR
SELECT ename FROM emp WHERE UPPER(ename) = 'KING';
6) SELECT LPAD(' ',2*level-2)||operation||' '||options||' '||object_name
query_plan
FROM plan_table
WHERE statement_id='Test1'
CONNECT BY prior id = parent_id
START WITH id = 0 order by id
7) And the query plan shows as
SELECT STATEMENT
TABLE ACCESS FULL EMP
I am using 9.0.1.4 !!!
Any help is appreciated !!!
Regards,
A.Kishore

One of the many new features in Oracle 8i is the Function-Based Index (we will refrain from using FBI, but only just). This allows the DBA to create indexes on functions or expressions; these functions can be user generated pl/sql functions, standard SQL functions (non-aggregate only) or even a C callout.
A classic problem the DBA faces in SQL Tuning is how to tune those queries that use function calls in the where clause, and result in indexes created on these columns not to be used.
Example
Standard B-Tree index on SURNAME with cost based optimizer
create index non_fbi on sale_contacts (surname);
analyze index non_fbi compute statistics;
analyze table sale_contacts compute statistics;
SELECT count(*) FROM sale_contacts
WHERE UPPER(surname) = 'ELLISON';
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=3 Card=1 Bytes=17)
1 0 SORT (AGGREGATE)
2 1 TABLE ACCESS (FULL) OF 'SALES_CONTACTS' (Cost=3 Card=16 Bytes=272)
Now we use a function based index
create index fbi on sale_contacts (UPPER(surname));
analyze index fbi compute statistics;
analyze table sale_contacts compute statistics;
SELECT count(*) FROM sale_contacts WHERE UPPER(surname) = 'ELLISON';
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=2 Card=1 Bytes=17)
1 0 SORT (AGGREGATE)
2 1 INDEX (RANGE SCAN) OF 'FBI' (NON-UNIQUE) (Cost=2 Card=381 Bytes=6477)
The function-based index has forced the optimizer to use index range scans (retuning zero or more rowids) on the surname column rather than doing a full table scan (non-index lookup). Optimal performance does vary depending on table size, uniqueness and selectivity of columns, use of fast full table scans etc. Therefore try both methods to gain optimal performance in your database.
It is important to remember that the function-based B*Tree index does not store the expression results in the index but uses an "expression tree". The optimizer performs expression matching by parsing the expression used in the SQL statement and comparing the results against the expression-tree values in the function-based index. This comparison IS case sensitive (ignores spaces) and therefore your function-based index expressions should match expressions used in the SQL statement where clauses.
Init.ora Parameters
The following parameter must be set in your parameter file: QUERY_REWRITE_INTEGRITY = TRUSTED
QUERY_REWRITE_ENABLED = TRUE
COMPATIBLE = 8.1.0.0.0 (or higher)
Grants
Grants To create function-based indexes the user must be granted CREATE INDEX and QUERY REWRITE, or alternatively be granted CREATE ANY INDEX and GLOBAL QUERY REWRITE. The index owner must have EXECUTE access on the function used for the index. If execute access is revoked then the function-based index will be "disabled" (see dba_indexes).
Disabled Indexes
If your function-based index has a status of "disabled" the DBA can do one of the following:
a) drop and create the index (take note of its current settings)
b) alter index enable, function-based indexes only, also use disable keyword as required
c) alter index unusable.
Queries on a DISABLED index fail if the optimizer chooses to use the index.Here is an example ORA error:
ERROR at line 1: ORA-30554: function-based index MYUSER.FBI is disabled.
All DML operations on a DISABLED index also fail unless the index is also marked UNUSABLE and the initialization parameter SKIP_UNUSABLE_INDEXES is set to true.
Some more Examples
CREATE INDEX expression_ndx
ON mytable ((mycola + mycolc) * mycolb);
SELECT mycolc FROM mytable
WHERE (mycola + mycolc) * mycolb <= 256;
..or a composite index..
CREATE INDEX example_ndx
ON myexample (mycola, UPPER(mycolb), mycolc);
SELECT mycolc FROM myexample
WHERE mycola = 55 AND UPPER(mycolb) = 'JONES';
Restriction & Rule Summary
The following restrictions apply to function based indexes. You may not index:
a) LOB columns
b) REF
c) Nested table column
d) Objects types with any of the above data types.
Function-based indexes must always follow these rules:
a) Cost Based optimizer only, must generate statistics after the index is created
b) Can not store NULL values (function can not return NULL under any circumstance)
c) If a user defined pl/sql routine is used for the function-based index, and is invalidated, the index will become "disabled"
d) Functions must be deterministic (always return the same value for a known input)
e) The index owner must have "execute" access on function used in the function-based index. Revocation of the privilege will render the index "disabled"
f) May have a B-Tree and Bitmap index type only
g) Can not use expressions that are based on aggregate functions, ie. SUM, AVG etc.
h) To alter a function-based index as enabled, the function used must be valid, deterministic and the signature of the function matches the signature of the function when it was created.
Joel P�rez

Function Based Index - Query Performance

HI,
Good Day to All..
I'd like to use function based indexes on following column(to_char(ps.user_pc_id)).
Whereas this column is part of PRIMARY KEY.
Is it possible to create a function based index on PRIMARY KEY Column?
Attached below is the query with the explain plan ...
TO_CHAR Expression - Performance
Thanks for your reply.

DTYLER_APP@pssdev2> create table dt_fbi_pk(id varchar2(20));
Table created.
DTYLER_APP@pssdev2> drop table dt_fbi_pk;
Table dropped.
DTYLER_APP@pssdev2> create table dt_fbi(id number);
Table created.
DTYLER_APP@pssdev2> create index dt_fbi_idx on dt_fbi(to_char(id));
Index created.
DTYLER_APP@pssdev2> alter table dt_fbi add constraint dt_fbi_pk primary key (id);
Table altered.
DTYLER_APP@pssdev2> select constraint_name,constraint_type, index_name from user_constraints where table_name='DT_FBI';
CONSTRAINT_NAME                C INDEX_NAME
DT_FBI_PK                      P DT_FBI_PK
1 row selected.When we created the primary key constraint, Oracle created a new index rather than using the existing one because....
DTYLER_APP@pssdev2> alter table dt_fbi drop primary key;
Table altered.
DTYLER_APP@pssdev2> select index_name from user_indexes where table_name ='DT_FBI';
INDEX_NAME
DT_FBI_IDX
1 row selected.
DTYLER_APP@pssdev2> alter table dt_fbi add constraint dt_fbi_pk primary key (id) using index dt_fbi_idx;
alter table dt_fbi add constraint dt_fbi_pk primary key (id) using index dt_fbi_idx
ERROR at line 1:
ORA-14196: Specified index cannot be used to enforce the constraint.
DTYLER_APP@pssdev2> alter table dt_fbi add constraint dt_fbi_uk unique(id) using index dt_fbi_idx;
alter table dt_fbi add constraint dt_fbi_uk unique(id) using index dt_fbi_idx
ERROR at line 1:
ORA-14196: Specified index cannot be used to enforce the constraint.We can't use a function based index to enforce a unique or primary key constraint. Changing the syntax does not help..
DTYLER_APP@pssdev2> alter table dt_fbi add constraint dt_fbi_uk unique(TO_CHAR(id)) using index dt_fbi_idx;
alter table dt_fbi add constraint dt_fbi_uk unique(TO_CHAR(id)) using index dt_fbi_idx
ERROR at line 1:
ORA-00904: : invalid identifierWe can create a unique index however
DTYLER_APP@pssdev2> drop index dt_fbi_idx;
Index dropped.
DTYLER_APP@pssdev2> create unique index dt_fbi_idx on dt_fbi(to_char(id));
Index created.but we still can't use it to enforce a unique or primary key constraint
DTYLER_APP@pssdev2> alter table dt_fbi add constraint dt_fbi_pk primary key (id) using index dt_fbi_idx;
alter table dt_fbi add constraint dt_fbi_pk primary key (id) using index dt_fbi_idx
ERROR at line 1:
ORA-14196: Specified index cannot be used to enforce the constraint.
DTYLER_APP@pssdev2> alter table dt_fbi add constraint dt_fbi_uk unique(id) using index dt_fbi_idx;
alter table dt_fbi add constraint dt_fbi_uk unique(id) using index dt_fbi_idx
ERROR at line 1:
ORA-14196: Specified index cannot be used to enforce the constraint.So no, you can't use it for a primary key. If you just want to enforce uniqueness then yes, you can do it with a unique index, but not a constraint.
DTYLER_APP@pssdev2> select * from v$version;
BANNER
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi
PL/SQL Release 10.2.0.4.0 - Production
CORE    10.2.0.4.0      Production
TNS for Linux: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production
5 rows selected.HTH
Daviid

Query Transformation in Function Based Index's Expression

Hi All,
I am having a wired issue with Function Based Indexes on Orcale 10.2.0.3 running on Solaris 5.9.
I have created two FBI on two tables using following syntax.
CREATE INDEX EQHUB.IDX_BBO_WRT_DES_FBI ON EQHUB.BBO_WARRANT_PRICING (CASE WHEN latest_version_flag = 'Y' THEN 1 ELSE NULL END);
CREATE INDEX EQHUB.IDX_BBO_DES_FBI ON EQHUB.BBO_DESCRIPTIVE_DATA (CASE WHEN latest_version_flag = 'Y' THEN 1 ELSE NULL END);
For the second command (IDX_BBO_DES_FBI), when i query DBA_IND_EXPRESSIONS view, i found that Oracle has done some kind of QUERY TRANSFORMATION (?) and converted
FBI expression to CASE "LATEST_VERSION_FLAG" WHEN 'Y' THEN 1 ELSE NULL END.At the same time,EXPRESSION on first index is not changed.
Now,my question is what has made transformation to occure only for second index.
I also found that inspite of highly SELECTIVE nature of both the indexes, only SECOND index is being used by CBO (for which trasnformation occured)
and IDX_BBO_WRT_DES_FBI is not being used(FTS is happening instead).
Query is using same expression for both the tables as
(CASE WHEN latest_version_flag = 'Y' THEN 1 ELSE NULL END)=1
INDEX_NAME                          TABLE_NAME                          COLUMN_EXPRESSION
IDX_BBO_WRT_DES_FBI                 BBO_WARRANT_PRICING                 CASE WHEN "LATEST_VERSION_FLAG"='Y' THEN 1 ELSE NULL END
IDX_BBO_DES_FBI                     BBO_DESCRIPTIVE_DATA                CASE "LATEST_VERSION_FLAG" WHEN 'Y' THEN 1 ELSE NULL ENDI read that expression should be evaluated including CASE of characters and spaces in query.Is that true?
Appreciating responses in advance.

Randolf.
It's a shame that I forgot to look into the full execution plan information to check how Oracle really handles my queries.
Look here(edited for clarity):
explain plan for
select /*+ case1 ordered use_nl(x, y) */ count(case c1
    when '1' then 1
    when '2' then 2
    when '3' then 3
    else 4
end) from
(select level from dual connect by level <= 300000) x,
(select
from t1
) y;
| Id | Operation                       | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT                |      |     1 |     2 |     5   (0)| 00:00:01 |
|   1 | SORT AGGREGATE                 |      |     1 |     2 |            |          |
|   2 |   NESTED LOOPS                  |      |     3 |     6 |     5   (0)| 00:00:01 |
|   3 |    VIEW                         |      |     1 |       |     2   (0)| 00:00:01 |
|   4 |     CONNECT BY WITHOUT FILTERING|      |       |       |            |          |
|   5 |      FAST DUAL                  |      |     1 |       |     2   (0)| 00:00:01 |
|   6 |    TABLE ACCESS FULL            | T1   |     3 |     6 |     3   (0)| 00:00:01 |
Column Projection Information (identified by operation id):
   1 - (#keys=0) COUNT(CASE WHEN "T1"."C1"='1' THEN 1 WHEN "T1"."C1"='2' THEN
       2 WHEN "T1"."C1"='3' THEN 3 ELSE 4 END )[22]
   2 - (#keys=0) "T1"."C1"[CHARACTER,1]
   4 - "DUAL".ROWID[ROWID,10], LEVEL[4]
   5 - "DUAL".ROWID[ROWID,10]
   6 - "T1"."C1"[CHARACTER,1]
32 rows selected.
explain plan for select /*+ case2 ordered use_nl(x, y) */ count(case
    when c1 = '1' then 1
    when c1 = '2' then 2
    when c1 = '3' then 3
    else 4
end) from
(select level from dual connect by level <= 300000) x,
(select
from t1
) y;
| Id | Operation                       | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT                |      |     1 |     2 |     5   (0)| 00:00:01 |
|   1 | SORT AGGREGATE                 |      |     1 |     2 |            |          |
|   2 |   NESTED LOOPS                  |      |     3 |     6 |     5   (0)| 00:00:01 |
|   3 |    VIEW                         |      |     1 |       |     2   (0)| 00:00:01 |
|   4 |     CONNECT BY WITHOUT FILTERING|      |       |       |            |          |
|   5 |      FAST DUAL                  |      |     1 |       |     2   (0)| 00:00:01 |
|   6 |    TABLE ACCESS FULL            | T1   |     3 |     6 |     3   (0)| 00:00:01 |
Column Projection Information (identified by operation id):
   1 - (#keys=0) COUNT(CASE WHEN "T1"."C1"='1' THEN 1 WHEN "T1"."C1"='2' THEN
       2 WHEN "T1"."C1"='3' THEN 3 ELSE 4 END )[22]
   2 - (#keys=0) "T1"."C1"[CHARACTER,1]
   4 - "DUAL".ROWID[ROWID,10], LEVEL[4]
   5 - "DUAL".ROWID[ROWID,10]
   6 - "T1"."C1"[CHARACTER,1]As you exactly mentioned, I was executing different SQL but actually same queries!
Thanks for pointing my flaws.
PS) OP, forgive me for bothering you with off-topic things. :)
================================
Dion Cho - Oracle Performance Storyteller
http://dioncho.wordpress.com (english)
http://ukja.tistory.com (korean)
================================
Edited by: Dion_Cho on Feb 10, 2009 5:45 AM
Typo

Importing error: related to function-based indexes?

I've come across a strange error. I've got a user that has an export dump file who wants me to import the data into a new database. (Its an Oracle 10G database.)
When I use the 'imp' command, the table import completes successfully, but I end up receiving the following warnings:
IMP-00003: oracle error 942 encountered
ORA-00942: table or view does not exist
IMP-00017: following statement failed with ORACLE error 942
"CREATE INDEX "X" on "Y" (TO_CHAR("Z",'yyyymmdd')) P"
"CTFREE 10 INITRANS 2 MAXTRANS 255 STORAGE(INITIAL 3145728 FREELISTS 1 FREEL"
"IST GROUPS 1 BUFFER_POOL DEFAULT) TABLESPACE "TBSPC" LOGGING"
The table itself seems to have been imported correctly; and all data rows exist. Its just the index that isn't being imported/rebuilt. (Other indexes on the same table were imported properly.)
The only thing that I could find that seems odd is that this index uses functions (the "TO_CHAR" in the index above). All of the other indexes on the table refer to basic fields. And I can rebuild the index manually.
Is the 'imp' command able to handle function-based indexes? Is there some parameter than I need to set to allow it to import these indexes?
(I know the more efficient thing to do would be to do an import with no indexes and rebuild them later...)
Edited by: user588235 on Dec 9, 2009 5:16 PM

Function based indexes should be supported. If it is exported, then it should be able to be imported. This just seems like a weird case. Have you tried to create a different table and then create a function based index on that table then see if exp/imp work?Yes, I have tried creating new versions of the tables (both with and without function-based indexes).
During my tests, I found that I can recreate the problem if I create the table in Oracle 9 and import it into Oracle 10; the problem doesn't occur when importing/exporting between Oracle9->Oracle9 or Oracle10->Oracle10. (However, the user told me that this was an export from Oracle 10.)
One other thing: I've noticed that if, instead of importing into a user account, I import into the system account, it works with no problems. For example:
imp userid='sys/xyz as sysdba' file=mydata.dmp fromuser=use1 touser=use2 ->Results in warnings while reading indexes
imp userid='sys/xyz as sysdba' file=mydata.dmp fromuser=use1 touser=sys ->works with no warning
This makes me suspect that its a problem with the permissions that have been granted. (I've granted 'create any index' and 'query rewrite' to the user account however.)
Not to change the issue, but since this is 10g, have you tried using datapump to expdp/impdp the same information?Might be an option; problem is, I'm dealing with a legacy system that was set up to use 'imp/exp', so altering backup and restore methods will require a lot of work.

Function-based index with OR in the wher-clause

We have some problems with functin-based indexes and
the or-condition in a where-clause.
--We use Oracle 8i (8.1.7)
create table TPERSON(ID number(10),NAME varchar2(20),...);
create index I_NORMAL_TPERSON_NAME on TPERSON(NAME);
create index I_FUNCTION_TPERSON_NAME on TPERSON(UPPER(NAME));
The following two statements run very fast on a large table
and the execution-plan asure the usage of the indexes
(-while the session is appropriate configured and the table is analyzed):
1)     select count(ID) FROM TPERSON where upper(NAME) like 'MIL%';
2)     select count(ID) from TPERSON where NAME like 'Mil%' or (3=5);
In particular we see that a normal index is used while the where-clause contains
an OR-CONDITION.
But if we try the similarly select-statement
3)     select count(ID) FROM TPERSON where upper(NAME) like 'MIL%' or (3=5);
the CBO will not use the function-index I_FUNCTION_TPERSON_NAME and we have a full table scan in the execution-plan.
(This behavior we only expect with views but not with indexes.)
We ask for an advice like a hint, which enable the CBO-usage
of function-based indexes in connection with OR.
This problem seems to be artificial because it contains this dummy logic:
     or (3=5).
This steams from an prepared statement, where this kind of boolean
flag reduce the amount of different select-statements needed for
covering the hole business-logic, while using bind-variables for the
concrete query-parameters.
A more realistic (still boild down) version of our select-statement is:
select * FROM TPERSON
where (upper(NAME) like 'MIL%' or (NAME is null))
and (upper(FIRSTNAME) like 'MICH% or (FIRSTNAME is null))
and ...;
thank you for time..
email: [email protected]

In the realistic statement you write :
select * FROM TPERSON
where (upper(NAME) like 'MIL%' or (NAME is null))
and (upper(FIRSTNAME) like 'MICH% or (FIRSTNAME is null))
and ...;
as far as i know, NULL values are not indexed, "or (NAME is NULL)" have to generate a full table scan.
HTH
We have some problems with functin-based indexes and
the or-condition in a where-clause.
--We use Oracle 8i (8.1.7)
create table TPERSON(ID number(10),NAME varchar2(20),...);
create index I_NORMAL_TPERSON_NAME on TPERSON(NAME);
create index I_FUNCTION_TPERSON_NAME on TPERSON(UPPER(NAME));
The following two statements run very fast on a large table
and the execution-plan asure the usage of the indexes
(-while the session is appropriate configured and the table is analyzed):
1)     select count(ID) FROM TPERSON where upper(NAME) like 'MIL%';
2)     select count(ID) from TPERSON where NAME like 'Mil%' or (3=5);
In particular we see that a normal index is used while the where-clause contains
an OR-CONDITION.
But if we try the similarly select-statement
3)     select count(ID) FROM TPERSON where upper(NAME) like 'MIL%' or (3=5);
the CBO will not use the function-index I_FUNCTION_TPERSON_NAME and we have a full table scan in the execution-plan.
(This behavior we only expect with views but not with indexes.)
We ask for an advice like a hint, which enable the CBO-usage
of function-based indexes in connection with OR.
This problem seems to be artificial because it contains this dummy logic:
     or (3=5).
This steams from an prepared statement, where this kind of boolean
flag reduce the amount of different select-statements needed for
covering the hole business-logic, while using bind-variables for the
concrete query-parameters.
A more realistic (still boild down) version of our select-statement is:
select * FROM TPERSON
where (upper(NAME) like 'MIL%' or (NAME is null))
and (upper(FIRSTNAME) like 'MICH% or (FIRSTNAME is null))
and ...;
thank you for time..
email: [email protected]

Function-based Index and an OR-condition in the WHERE-clause

We have some problems with functin-based indexes and
the or-condition in a where-clause.
(We use oracle 8i (8.1.7))
create table TPERSON(ID number(10),NAME varchar2(20),...);
create index I_NORMAL_TPERSON_NAME on TPERSON(NAME);
create index I_FUNCTION_TPERSON_NAME on TPERSON(UPPER(NAME));
The following two statements run very fast on a large table
and the execution-plan asure the usage of the indexes
(-while the session is appropriate configured and the table is analyzed):
1)     select count(ID) FROM TPERSON where upper(NAME) like 'MIL%';
2)     select count(ID) from TPERSON where NAME like 'Mil%' or (3=5);
In particular we see that a normal index is used while the where-clause contains
an OR-CONDITION.
But if we try the similarly select-statement
3)     select count(ID) FROM TPERSON where upper(NAME) like 'MIL%' or (3=5);
the CBO will not use the function-index.
(This behavior we only expect with views but not with indexes.)
We ask for an advice like an hint, which enable the CBO-usage
of function-based indexes in connection with OR.
This problem seems to be artificial because it contains this dummy logic:
     or (3=5).
This steams from an prepared statement, where this kind of boolean
flag reduce the amount of different select-statements needed for
covering the hole business-logic, while using bind-variables for the
concrete query-parameters.
A more realistic (still boild down) version of our prepared select-statement run in
SQL Plus:
define x_name = 'MIL%';
define x_firstname = '';
select * FROM TPERSON
where (upper(NAME) like '&x_name' or ( '&x_name' = ''))
and (upper(FIRSTNAME) like '&x_firstname' or ('&x_firstname' = ''))
and ...;
In particular we dont refernce the tablecolumn , but the QUERY-Parameter
yield the second boolean value in the or-condition.
The problem is that this condition ('&x_name' = '') dont use any index.
thanks a lot for spending your time with this problem

Try
SELECT /*+ RULE */
as your hint. I don't have the book with me, but this last weekend I read a section about your very problem. The book was a Oracle Press gold cover about Oracle 8i Performance tuning. If you e-mail me I can quote you the chapter when I get home Friday.

Dilemma regarding function based indexes

Hello,
I have a dilemma regarding function based indexes.
I have read Note:66277.1 on the Metalink discussing thoroughly the subject of “Concepts and Usage of Function Based Indexes”.
This doc was revised on 30-May-2006 so I was sure it referred to 9i and 10g.
This doc as well as other docs on the web claim that in order to use FBI (function based indexes) one must set the following parameters (can be done also at session level)
QUERY_REWRITE_ENABLED = TRUE
QUERY_REWRITE_INTEGRITY = TRUSTED
Also the schema that is owner of the FBI should be granted with QUERY REWRITE sys priv and statistics should be collected since FBI is usable only by CBO (cost based optimizer).
I have tested it and it works, my problem was that it worked
(1)     Without granting the QUERY REWRITE to the owning schema.
(2)     QUERY_REWRITE_ENABLED was set to false.
(3)     QUERY_REWRITE_INTEGRITY was set to enforced.
I have conducted my tests on 9.2.0.6 and found no evidence in the docs (10g) saying the above is required or not.
I found at http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:1197786003246 the following:
“Oracle9iR2 relaxed this so that the FBI on the builtin function may be used.”
so I have tested it with my own function:
create or replace function upper2( p_str in varchar2 ) return
varchar2 DETERMINISTIC
as
begin
return upper(p_str);
end;
=>
Also (yes you guessed right), without any privilege granted nor parameter setting the optimizer picked my FBI.
Can anyone refer me to a place documenting this behavior as a correct one?
Other comments?
Regards,
Tal Olier ([email protected])

Got an answer from Oracle support:
19-DEC-06 18:04:31 GMT
(Update for record id(s): 101017780,101017796)
QUESTION
========
Questions about the options required in 10g related to Function Based Indexes, and the correct
behaviors associated with them.
ANSWER
======
For 10g:
These requirements are no longer true in 10g. This has already clarified by
development in the Bug 3999326 which is available on metalink.
For 9I:
For the creation of a function-based index in your own schema, you must be
granted the QUERY REWRITE system privileges. To create the index in another
schema or on another schema's tables, you must have the CREATE ANY INDEX
and GLOBAL QUERY REWRITE privileges.
You must have the following initialization parameters defined to create a
function-based index:
QUERY_REWRITE_INTEGRITY set to TRUSTED
QUERY_REWRITE_ENABLED set to TRUE
COMPATIBLE set to 8.1.0.0.0 or a greater value
Additionally, to use a function-based index:
The table must be analyzed after the index is created.
The query must be guaranteed not to need any NULL values from the indexed
expression, since NULL values are not stored in indexes.
However, in 9.2.0.4 patchset, these prerequisites do not apply and one can
create function-based indexes without any of the above to be true. This is not
the case in 9.2.0.3, not in 8.1.7.
Reference: Oracle 9i R2 Administrators Guide
So as mentioned above that is why you didnt have any errors
Please back to us if any further information is need, and we will be pleased to
assist you further.
Thank You,
Best Regards,
Mina Anes

URGENT - Function based indexes

Hi,
I have a table with huge amount of data and hence I have created
a function-based (Upper) index on one of the character NOT
NULL field which is very likely to be used for query purposes.
First of all though I can create ordinary normal field based
indexes in my user I cannot create a function-based index, why
That had to be created thru SYS user. Secondly I my query
invloving this function is not using the index and instead doing
a full-table scan. Problem outlined below :
Table : PLZPOST, USER / OWNER : PARTNER, FIELD : ORT
INDEX created on UPPER(ORT) in SYS user -
Create index upper_plz_ort on partner.plzpost (upper(ort))
When I give any of the following queries instead of using the
resp. index as mentioned in Oracle DOC it just does a full table
scan (checked thru Explain Plan) :
select * from PLZPOST where upper(ort) is not null;
select * from PLZPOST where upper(ort) like upper('saar%')
select * from PLZPOST where upper(ort) = 'SAARBRUECKEN'
etc etc
If anyone has used Function-based indexes in Oracle 8i could you
please tell me where am I going wrong. Is it because my Table
belongs to PARTNER and Index to SYS (tried running the above
queries under SYS user also but still did not work) ?? If so how
can I grant access on an Index to PARTNER from SYS ??
Your help would be greatly appreciated.
Thanks in advance,
Cheers
Rashmi
null

<BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:</font><HR>Originally posted by Rashmi Rungta ([email protected]):
Hi,
I have a table with huge amount of data and hence I have created
a function-based (Upper) index on one of the character NOT
NULL field which is very likely to be used for query purposes.
First of all though I can create ordinary normal field based
indexes in my user I cannot create a function-based index, why
That had to be created thru SYS user. Secondly I my query
invloving this function is not using the index and instead doing
a full-table scan. Problem outlined below :
Table : PLZPOST, USER / OWNER : PARTNER, FIELD : ORT
INDEX created on UPPER(ORT) in SYS user -
Create index upper_plz_ort on partner.plzpost (upper(ort))
When I give any of the following queries instead of using the
resp. index as mentioned in Oracle DOC it just does a full table
scan (checked thru Explain Plan) :
select * from PLZPOST where upper(ort) is not null;
select * from PLZPOST where upper(ort) like upper('saar%')
select * from PLZPOST where upper(ort) = 'SAARBRUECKEN'
etc etc
If anyone has used Function-based indexes in Oracle 8i could you
please tell me where am I going wrong. Is it because my Table
belongs to PARTNER and Index to SYS (tried running the above
queries under SYS user also but still did not work) ?? If so how
can I grant access on an Index to PARTNER from SYS ??
Your help would be greatly appreciated.
Thanks in advance,
Cheers
Rashmi<HR></BLOCKQUOTE>
null

Function based indexes on CLOB storage

On a 10gR2 database, with schema-less CLOB storage for an XMLType column:
(1) Can a function based index include a wildcard in the namespace ? Or do I need a new function based index for each specific namespace ?
(2) I must create a new function based index for each different element that I want an indexed search on ?
(3) What limit is there on the number of function based indexes per table ?
(4) I believe XQuery can include a wildcard for namespaces, but XPath 1.x can't. Can I create a function based index using XQuery, rather than XPath ?
Documents conforming to different versions of an XML schema will be present (schema versioning), but I want to search across all documents irrespective of a specific namespace - e.g. "Find any document with reference = 'some Value' , and amount = 1000".
CLOB storage is proposed, due to the need to handle documents from multiple versions of an XML schema. The knowledge of the XSD is not known at development time, but is user definable, and it must be possible to change the structure without system down time. Structured storage is not suitable, due to Oracle's requirement for downtime if the schema changes (CopyEvolve drops/recreates tables), and Oracle doesn't support schema collections, so you can't bind an XML column to multiple schemas.
Here is some sample code of what I'm trying to do:
create table BulkTest
ID NUMBER(10) not null primary key,
USERFIELDS XMLTYPE
create sequence S_BulkTest;
--Document conforming to version 1 of schema
INSERT INTO BulkTest(id, Userfields) VALUES
(S_BulkTest.Nextval,
'<?xml version="1.0" encoding="utf-8" ?>
<mt395 xmlns="urn:incident:mt395-1">
     <reference>FH12345678</reference>
     <relatedReference>FH23456789</relatedReference>
     <queries>Here is some query text.</queries>
     <narrative>Here is some narrative text.</narrative>
     <relatedMessageType>300</relatedMessageType>
     <relatedMessageDate>2005-03-29</relatedMessageDate>
     <direction>R</direction>
     <sessionNumber>1234</sessionNumber>
     <isn>123456</isn>
     <relatedMessageDescription>This is the deal where I bought USD 1 million for GBP at 1.76.</relatedMessageDescription>
     <otherParty>232332</otherParty>
</mt395>'
--Document conforming to version 2 of schema
INSERT INTO BulkTest(id, Userfields) VALUES
(S_BulkTest.Nextval,
'<?xml version="1.0" encoding="utf-8" ?>
<mt395 xmlns="urn:incident:mt395-2">
     <guid>0f9a08f6-b052-4693-baba-8f7dc881e7e8</guid>
     <reference>333333</reference>
     <queries>Another query</queries>
     <narrative>Some narrative</narrative>
     <direction>R</direction>
     <sessionNumber>1234</sessionNumber>
     <isn>223456</isn>
</mt395>'
--It seems I need to create a new index for each field I want to search on
create index iBulkTest_REFERENCE
on BulkTest
(extractValue(UserFields,'/mt395/reference', 'xmlns="urn:incident:mt395-1"'));
--And that a new index is required for each specifc namespace that is present
--Can't we include a wildcard in the namespace ?
create index iBulkTest_REFERENCE_2
on BulkTest
(extractValue(UserFields,'/mt395/reference', 'xmlns="urn:incident:mt395-2"'));
--If I want to query, I have to explicitly specify each namespace.
--Can't I specify a wildcard ?
--This will make it "fun" querying across namespaces!
select
id,
extractValue(UserFields,'/mt395/reference', 'xmlns="urn:incident:mt395-2"') As Reference,
t.userfields.getclobval() userfields
from bulktest t
WHERE extractValue(UserFields,'/mt395/reference', 'xmlns="urn:incident:mt395-2"') = '333333'

Andy
#1. You do not have scehma versioning here. Your model is totally incorrect. You shoud not change the namespace when versioning the XML Schema. You have 2 different and totally disjoint XML Schemas. The correct was to version, as distinct from evolve an XML Schema is to change the Schema Location Hint associated with your XML...
Eg
INSERT INTO BulkTest(id, Userfields) VALUES
(S_BulkTest.Nextval,
'<?xml version="1.0" encoding="utf-8" ?>
<mt395 xmlns="urn:incident:mt395" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:incident:mt395 mt395-1.xsd">
<reference>FH12345678</reference>
<relatedReference>FH23456789</relatedReference>
<queries>Here is some query text.</queries>
<narrative>Here is some narrative text.</narrative>
<relatedMessageType>300</relatedMessageType>
<relatedMessageDate>2005-03-29</relatedMessageDate>
<direction>R</direction>
<sessionNumber>1234</sessionNumber>
<isn>123456</isn>
<relatedMessageDescription>This is the deal where I bought USD 1 million for GBP at 1.76.</relatedMessageDescription>
<otherParty>232332</otherParty>
</mt395>'
--Document conforming to version 2 of schema
INSERT INTO BulkTest(id, Userfields) VALUES
(S_BulkTest.Nextval,
'<?xml version="1.0" encoding="utf-8" ?>
<mt395 xmlns="urn:incident:mt395 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:incident:mt395 mt395-2.xsd">
<guid>0f9a08f6-b052-4693-baba-8f7dc881e7e8</guid>
<reference>333333</reference>
<queries>Another query</queries>
<narrative>Some narrative</narrative>
<direction>R</direction>
<sessionNumber>1234</sessionNumber>
<isn>223456</isn>
</mt395>'
This is the correct way of versioning an XML Schema. THe namespace stays the same, the SchemaLocationHint in the SchemaLocation tag changes.
Bear in mind that if you use the technique you are currently using you will make any path expressions you need to write absolutely unmaintaining and the processing of them very inefficient.
Some questions to consider
Node 'X' in namespace 'X' is never the same as Node 'X' in namespace 'Y'.
How would you write an Xpath or XQuery that targetted multiple versions, but not all versions ?
What happens if you have other documents that are really in a different namespace ? Using wildcards can you differentiate them..
From the problem you are describing and the terminolgy you are using it looks like you've been an early customer of Yukon. MSFT clearly didn't understand schema versioning in the early beta releases and used the 'change the namespace' schema for modelling schema versioning.
We do have some technology coming down the pipe which can address the issue, regardless of whether or not it is too late for you to correct the versioning scheme you have selected. However I cannot discuss that in a public forum. If you want to learn about these features and are prepared to enter an NDA with Oracle in order to do so please contact me directly. You can do this a number of ways...
Guess my email address @oracle.com
Post your email address here and I'll delete the post as soon as I have it..
Update your OTN Forum profile to include your email address
Open a TAR and post the tar number here. You can then softclose the tar as this is simply a method for me to get your contact info.

Function based indexes on object tables

Hi,
I am trying to create a function based index on an object table. I am getting the following error:
SQL> create index cell1_indx on cell1(create_cell1(id)) indextype is mdsys.spatial_index;
create index cell1_indx on cell1(create_cell1(id)) indextype is mdsys.spatial_index
ERROR at line 1:
ORA-29855: error occurred in the execution of ODCIINDEXCREATE routine
ORA-13249: internal error in Spatial index: [mdidxrbd]
ORA-13249: Error in Spatial index: index build failed
ORA-13249: Stmt-Execute Failure: SELECT num_rows from all_tables where owner='ASHE' and table_name=
'CELL1'
ORA-06512: at "MDSYS.SDO_INDEX_METHOD_9I", line 7
ORA-06512: at line 1
Here cell1 is an object table.
Is the procedure for creating function based indexes on object tables different from relational tables?
Chinni

One of the many new features in Oracle 8i is the Function-Based Index (we will refrain from using FBI, but only just). This allows the DBA to create indexes on functions or expressions; these functions can be user generated pl/sql functions, standard SQL functions (non-aggregate only) or even a C callout.
A classic problem the DBA faces in SQL Tuning is how to tune those queries that use function calls in the where clause, and result in indexes created on these columns not to be used.
Example
Standard B-Tree index on SURNAME with cost based optimizer
create index non_fbi on sale_contacts (surname);
analyze index non_fbi compute statistics;
analyze table sale_contacts compute statistics;
SELECT count(*) FROM sale_contacts
WHERE UPPER(surname) = 'ELLISON';
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=3 Card=1 Bytes=17)
1 0 SORT (AGGREGATE)
2 1 TABLE ACCESS (FULL) OF 'SALES_CONTACTS' (Cost=3 Card=16 Bytes=272)
Now we use a function based index
create index fbi on sale_contacts (UPPER(surname));
analyze index fbi compute statistics;
analyze table sale_contacts compute statistics;
SELECT count(*) FROM sale_contacts WHERE UPPER(surname) = 'ELLISON';
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=2 Card=1 Bytes=17)
1 0 SORT (AGGREGATE)
2 1 INDEX (RANGE SCAN) OF 'FBI' (NON-UNIQUE) (Cost=2 Card=381 Bytes=6477)
The function-based index has forced the optimizer to use index range scans (retuning zero or more rowids) on the surname column rather than doing a full table scan (non-index lookup). Optimal performance does vary depending on table size, uniqueness and selectivity of columns, use of fast full table scans etc. Therefore try both methods to gain optimal performance in your database.
It is important to remember that the function-based B*Tree index does not store the expression results in the index but uses an "expression tree". The optimizer performs expression matching by parsing the expression used in the SQL statement and comparing the results against the expression-tree values in the function-based index. This comparison IS case sensitive (ignores spaces) and therefore your function-based index expressions should match expressions used in the SQL statement where clauses.
Init.ora Parameters
The following parameter must be set in your parameter file: QUERY_REWRITE_INTEGRITY = TRUSTED
QUERY_REWRITE_ENABLED = TRUE
COMPATIBLE = 8.1.0.0.0 (or higher)
Grants
Grants To create function-based indexes the user must be granted CREATE INDEX and QUERY REWRITE, or alternatively be granted CREATE ANY INDEX and GLOBAL QUERY REWRITE. The index owner must have EXECUTE access on the function used for the index. If execute access is revoked then the function-based index will be "disabled" (see dba_indexes).
Disabled Indexes
If your function-based index has a status of "disabled" the DBA can do one of the following:
a) drop and create the index (take note of its current settings)
b) alter index enable, function-based indexes only, also use disable keyword as required
c) alter index unusable.
Queries on a DISABLED index fail if the optimizer chooses to use the index.Here is an example ORA error:
ERROR at line 1: ORA-30554: function-based index MYUSER.FBI is disabled.
All DML operations on a DISABLED index also fail unless the index is also marked UNUSABLE and the initialization parameter SKIP_UNUSABLE_INDEXES is set to true.
Some more Examples
CREATE INDEX expression_ndx
ON mytable ((mycola + mycolc) * mycolb);
SELECT mycolc FROM mytable
WHERE (mycola + mycolc) * mycolb <= 256;
..or a composite index..
CREATE INDEX example_ndx
ON myexample (mycola, UPPER(mycolb), mycolc);
SELECT mycolc FROM myexample
WHERE mycola = 55 AND UPPER(mycolb) = 'JONES';
Restriction & Rule Summary
The following restrictions apply to function based indexes. You may not index:
a) LOB columns
b) REF
c) Nested table column
d) Objects types with any of the above data types.
Function-based indexes must always follow these rules:
a) Cost Based optimizer only, must generate statistics after the index is created
b) Can not store NULL values (function can not return NULL under any circumstance)
c) If a user defined pl/sql routine is used for the function-based index, and is invalidated, the index will become "disabled"
d) Functions must be deterministic (always return the same value for a known input)
e) The index owner must have "execute" access on function used in the function-based index. Revocation of the privilege will render the index "disabled"
f) May have a B-Tree and Bitmap index type only
g) Can not use expressions that are based on aggregate functions, ie. SUM, AVG etc.
h) To alter a function-based index as enabled, the function used must be valid, deterministic and the signature of the function matches the signature of the function when it was created.
Joel P�rez

Function-based indexes in 8i

How can I enable function-based indexes on a already created
database. Is an Installation/Db Creation setting?
On another database I am able to create function-based indexes.
Any help appreciated.
Ashish
null

<BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:</font><HR>Originally posted by Rashmi Rungta ([email protected]):
Hi,
I have a table with huge amount of data and hence I have created
a function-based (Upper) index on one of the character NOT
NULL field which is very likely to be used for query purposes.
First of all though I can create ordinary normal field based
indexes in my user I cannot create a function-based index, why
That had to be created thru SYS user. Secondly I my query
invloving this function is not using the index and instead doing
a full-table scan. Problem outlined below :
Table : PLZPOST, USER / OWNER : PARTNER, FIELD : ORT
INDEX created on UPPER(ORT) in SYS user -
Create index upper_plz_ort on partner.plzpost (upper(ort))
When I give any of the following queries instead of using the
resp. index as mentioned in Oracle DOC it just does a full table
scan (checked thru Explain Plan) :
select * from PLZPOST where upper(ort) is not null;
select * from PLZPOST where upper(ort) like upper('saar%')
select * from PLZPOST where upper(ort) = 'SAARBRUECKEN'
etc etc
If anyone has used Function-based indexes in Oracle 8i could you
please tell me where am I going wrong. Is it because my Table
belongs to PARTNER and Index to SYS (tried running the above
queries under SYS user also but still did not work) ?? If so how
can I grant access on an Index to PARTNER from SYS ??
Your help would be greatly appreciated.
Thanks in advance,
Cheers
Rashmi<HR></BLOCKQUOTE>
null

Does this query need function based index?

Similar Messages

Maybe you are looking for