Function-based indexes don't seem to work in Oracle 8.1.5?

Hi,
What gives? What am I doing wrong? I have a table AIRPORT with a column (varchar2(64)) which I have specified a function based index for, but I can't get SQL wueries to use it!!!! the following SQL executes a FULL TABLE SCAN:
select /*+ index (a idx_upper_cityname) */ *
from airport a
where nls_upper(cityName) = 'dfdf'
...as does...
select *
from airport a
where nls_upper(cityName) = 'dfdf'
Table and index code is as follows:
CREATE TABLE airport
id NUMBER NOT NULL,
citycode VARCHAR2(3) NOT NULL,
cityname VARCHAR2(64) NOT NULL,
state VARCHAR2(2),
country VARCHAR2(2) NOT NULL,
region CHAR(1),
airportcode VARCHAR2(3) NOT NULL,
airportname VARCHAR2(64),
code VARCHAR2(4)
drop index idx_upper_cityname
CREATE INDEX idx_upper_cityname ON airport nls_upper(substr(cityName, 0, 64) )
Environment is as follows:
Oracle8i v8.1.5 running on WinNT v4.0 (SP 5)
Client is running on the same machine
thanks in advance,
Alexander

New data point: when I set the handler in my logging.properties file thusly,
org.apache.catalina.core.ContainerBase.[Catalina].[info-dev].[/infoisland].level = ALL
org.apache.catalina.core.ContainerBase.[Catalina].[info-dev].[/infoisland].handlers = java.util.logging.ConsoleHandlerI get 0 bytes in the info-dev log (which used to have the aforementioned expception in it). Where is my console going?

Similar Messages

Function based indexing v8.1.7 not working

I have created a function based index on a column and when I run my query although I get the correct results I seem to be doing a full table scan instead of using the index.
Are there any known bugs or additional parameter setting for function based indexing in 8i ?
Thanks
Bob I

Robert
To use Functional Index you to set following parameters in INIT.ORA, Compatiable should be more than 8.1.0
query_rewrite_enabled = TRUE
query_rewrite_integrity = TRUSTED
Compatiable = 8.1.7.0
optimizer = Choose
Create index indexname on table (lower(column));
then analyze table
Analyze table tablename compute statistics;
Regards
Shailesh
null

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.

Function-Based Index enabling.

Hi...
I'm trying to create a function-based index along the lines of:
CREATE INDEX x_ssn4
ON table_y(SUBSTR(ssn,6,4))
UNRECOVERABLE;
...so as to be able to query the final 4 digits of social security numbers. Problem is that the above elicits an ORA-00439 "feature not enabled" message. I'm running 8.1.6 and have tried setting the Oracle parameter QUERY_REWRITE_ENABLED to 'TRUE' via an ALTER SESSION command, but to no avail.
Anyone know how to 'turn the feature on'?
Thanks, Rob

<BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:</font><HR>Originally posted by Rick Post:
I've always done it by logging on as SYS and executing a 'grant query rewrite to myuser'.
<HR></BLOCKQUOTE>
Thanks... but turns out that the privilege is not really the issue, as the ALTER SESSION command works. I figured out that the problem was the setting for COMPATIBLE. It pointed to 8.0.0 instead of 8.1.x which is what was needed to permit function-based indexing.
~Rob
null

Oracle 8i Function-based index

Hi,
i have problem with making Oracle8i to use function-based index. I am using version 8.1.6 Enterprise Edition.
So here is the test I did
CREATE INDEX first_name_index ON customer ( UPPER(first_name)) ;
alter session set QUERY_REWRITE_ENABLED = TRUE;
alter session set QUERY_REWRITE_INTEGRITY=TRUSTED;
ANALYZE TABLE customer COMPUTE STATISTICS;
alter index first_name_index compute statistics;
Everything seemed to be as required by Oracle but it doesn't use this function-based index when I make
select *
from customer
where upper(first_name) like 'J%';
I test it on large table and with table with few hundred rows. I don't have NULLs in that field.
Can anyone help me with this.

I would not create an index to have it prepared for an ORDER BY. An index is quite costly in DML opperations and space as well. More, a function based index will be costlier as the function has to be called for every read and/or write.
Do not forget that indexes a created for a direct access to data and not for sorting purposes.
George

Err ORA-00439 feature not enabled: function-based indexes

How can I enable function based indexes?
Database Version is 8i Release 8.1.6.0.0.
I've done the following steps:
The init-parameter compatible is set to 8.1.0.0.0.
I've altered the session parameters
QUERY_REWRITE_INTEGRITY to TRUSTED and
QUERY_REWRITE_ENABLED to TRUE.
But it still doesn't work.
I would appreciate your help.
Martin

Function Based Index feature is not available in the Standard Edition of Oracle. This feature is available ONLY in the Enterprise and Personal Editions.
Use the V$OPTION view to see the list of installed options.
If the option is installed, you will see for "Function-based indexes":
PARAMETER VALUE
Function-based indexes TRUE
null

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.

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

How to create function based index for TO_CHAR

i need to create a function based index for the function to_char.when i tried ,i got an error,"only pure function can be indexed".what the error really means, help me in creating the index to reduce my query cost.

It works fine on my database. version 9iR2
create index IDX_TO_CHAR on emp(to_char(hiredate,'YYYY-MM-DD HH24:MI:SS'));
explain plan for
select hiredate from emp where to_char(hiredate,'YYYY-MM-DD HH24:MI:SS')='1981-05-01 00:00:00';
| Id | Operation                   | Name        | Rows | Bytes | Cost (%CPU)|
|   0 | SELECT STATEMENT            |              |     1 |     8 |     2 (50)|
|   1 | TABLE ACCESS BY INDEX ROWID| EMP          |     1 |     8 |     2 (50)|
|* 2 |   INDEX RANGE SCAN          | IDX_TO_CHAR |     1 |       |     2 (50)|
Predicate Information (identified by operation id):
   2 - access(TO_CHAR("EMP"."HIREDATE",'YYYY-MM-DD HH24:MI:SS')='1981-05-01 00
              :00:00')Yours seem like a tuning issue, so why not give us your sql and execution plan and so on.
maybe there is other ways to tune your sql than creating a function based index?

Performance problem on function-based index

Hi guys,
I am having performance problems with the addition of new function-based indexes.
alter session set nls_comp='ANSI';
alter session set nls_sort='BINARY_CI';
* have to run this because the of case-insensitivity requirements
I have a view. for ex:
create or replace view view1
as
select * from emp1,user
where emp1.empno=user.empno
union
select * from emp2,user
where emp2.empno=user.empno
union
select * from emp3,user
where emp3.empno=user.empno and so on
When I run this it works with a full table scan. Then when i created a function-based index:
create index user_ix on
user(nlssort(empno,'NLS_SORT=BINARY_CI'));
analyze index user_ix compute statistics;
analyze table user compute statistics;
the view hangs. but when i run the individual select statements it works.
Do you guys have any idea on what's going on? Any advise is greatly appreciated.
Thanks.

LC is absolutely right. Brain cramp on my part.
On the other hand, I can't seem to coerce Oracle to apply a to_binary_double conversion as part of an implicit conversion.
var bin_dbl binary_double;
select to_binary_double(14) into :bin_dbl from dual;
SCOTT @ nx102 JCAVE9420> select * from emp where empno = :bin_dbl;
no rows selected
Elapsed: 00:00:00.14
Execution Plan
Plan hash value: 2949544139
| Id | Operation                   | Name   | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT            |        |     1 |    39 |     1   (0)| 00:00:01 |
|   1 | TABLE ACCESS BY INDEX ROWID| EMP    |     1 |    39 |     1   (0)| 00:00:01 |
|* 2 |   INDEX UNIQUE SCAN         | PK_EMP |     1 |       |     0   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - access("EMPNO"=TO_NUMBER(:BIN_DBL))I'd expect that Oracle would try to convert the binary double to a number, not the other way around.
Justin

Is Function-based Index useless ?

I have a table with 1+ mln records, which has lastupdate (date) column.
In order to improve performance for it, I created Function-based index on Trunc(lastupdate) column:
CREATE INDEX idx_trunc_lastupdate
ON ms_test(TRUNC(LASTUPDATE))
When I run Explain Plan for my query
SELECT * FROM ms_test
WHERE trunc(lastupdate)=trunc(sysdate)
it chooses Full table scan instead of index.
Even when I include hint like this
SELECT /*+ index(MS_TEST, idx_trunc_lastupdate) */
* FROM ms_test
WHERE trunc(lastupdate)=trunc(sysdate)
Explain Plan still chooses full table scan.
What is wrong here, or maybe hints don't work with function-based indexes ?
Thanks

Todd,
You're right. I can't remember when or where I read that, but I think I tested it and it was true at the time. I just tested it using 8.1.7 and, as you said, it is no longer necessary to match case and whitespace. I included my tests below.
Barbara
SQL> CREATE TABLE test_table AS SELECT created FROM user_objects
2 /
Table created.
SQL> CREATE INDEX t_fbi ON test_table (TRUNC (created))
2 /
Index created.
SQL> ANALYZE TABLE test_table
2 COMPUTE STATISTICS
3 FOR TABLE
4 FOR ALL INDEXES
5 FOR ALL INDEXED COLUMNS
6 /
Table analyzed.
SQL> ALTER SESSION SET QUERY_REWRITE_ENABLED=TRUE
2 /
Session altered.
SQL> ALTER SESSION SET QUERY_REWRITE_INTEGRITY=TRUSTED
2 /
Session altered.
SQL> SET AUTOTRACE ON EXPLAIN
SQL> SELECT COUNT (*) FROM test_table WHERE TRUNC (created) = TRUNC (SYSDATE)
2 /
COUNT(*)
         3
Execution Plan
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=1 Card=1 Bytes=9)
   1    0   SORT (AGGREGATE)
   2    1     INDEX (RANGE SCAN) OF 'T_FBI' (NON-UNIQUE) (Cost=1 Card=
          10 Bytes=90)
SQL> SELECT COUNT (*) FROM test_table WHERE trunc(created) = TRUNC (SYSDATE)
2 /
COUNT(*)
         3
Execution Plan
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=1 Card=1 Bytes=9)
   1    0   SORT (AGGREGATE)
   2    1     INDEX (RANGE SCAN) OF 'T_FBI' (NON-UNIQUE) (Cost=1 Card=
          10 Bytes=90)

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]

Creation of function based index using escape

Hello,
I have the following SQL, sometimes performing bad:
SELECT DISTINCT UPPER(A.PROCESSIDCODE), UPPER(A.RULENAME), CHARSET
FROM XIB_DETECT A, XIB_PROCESSIDPROPERTIES B, XIB_RULES C
WHERE ( A.KEY1 = :P1 OR ( :P1 like REPLACE(REPLACE(REPLACE(REPLACE(KEY1,'%', '\%'),'_', '\_'),'?', '_'),'*','%') escape '\' AND A.REGFLAGS1 = 'Y') OR A.KEY1 = '*' AND A.REGFLAGS1 = 'Y')
AND (A.KEY2 = :P2 OR ( :P2 like REPLACE(REPLACE(REPLACE(REPLACE(KEY2,'%', '\%'),'_', '\_'),'?', '_'),'*','%') escape '\' AND A.REGFLAGS2 = 'Y') OR (A.KEY2 IS NULL AND A.REGFLAGS2 IS NULL ) )
AND (A.KEY3 = :P3 OR ( :P3 like REPLACE(REPLACE(REPLACE(REPLACE(KEY3,'%', '\%'),'_', '\_'),'?', '_'),'*','%') escape '\' AND A.REGFLAGS3 = 'Y') OR (A.KEY3 IS NULL AND A.REGFLAGS3 IS NULL ) )
AND (A.KEY4 = :P4 OR ( :P4 like REPLACE(REPLACE(REPLACE(REPLACE(KEY4,'%', '\%'),'_', '\_'),'?', '_'),'*','%') escape '\' AND A.REGFLAGS4 = 'Y') OR (A.KEY4 IS NULL AND A.REGFLAGS4 IS NULL ) )
AND (A.KEY5 = :P5 OR ( :P5 like REPLACE(REPLACE(REPLACE(REPLACE(KEY5,'%', '\%'),'_', '\_'),'?', '_'),'*','%') escape '\' AND A.REGFLAGS5 = 'Y') OR (A.KEY5 IS NULL AND A.REGFLAGS5 IS NULL ) )
AND (A.KEY6 IS NULL OR A.KEY6 = '*' AND REGFLAGS6 = 'Y')
AND (A.KEY7 IS NULL OR A.KEY7 = '*' AND REGFLAGS7 = 'Y')
AND (A.KEY8 IS NULL OR A.KEY8 = '*' AND REGFLAGS8 = 'Y')
AND (A.KEY9 IS NULL OR A.KEY9 = '*' AND REGFLAGS9 = 'Y')
AND (A.KEY10 IS NULL OR A.KEY10 = '*' AND REGFLAGS10 = 'Y')
AND ( ( A.PROCESSIDCODE IS NOT NULL AND UPPER(A.PROCESSIDCODE) = UPPER(B.PROCESSIDCODE) AND A.XLEVEL = B.XLEVEL AND B.ACTIVEFLAG = 'Y' )
OR ( A.RULENAME IS NOT NULL AND UPPER(A.RULENAME) = UPPER(C.RULENAME) AND A.XLEVEL = C.XLEVEL AND C.ACTIVEFLAG = 'Y' ) );
Now I want to create a function based index on the key1 column:
CREATE INDEX xib_detect_ix ON xib_detect (REPLACE(REPLACE(REPLACE(REPLACE(KEY1,'%', '\%'),'_', '\_'),'?', '_'),'*','%') escape '\') TABLESPACE ... ONLINE;
However, this is not working with "escape" '\', throwing: ORA-00907: missing right parenthesis
Any idea how to create an index on this construct with "escape"?
Database version is 10.2.0.3.
Thanks a lot.
Regards
Oliver

Hi,
You can get the "missing right parenthesis" error for many different syntax errors.
In this case, you really are missing a right parenthesis. Your statement has 5 left '('s, but only 4 right ')'s. It's easy to see this if you format your code:
CREATE INDEX xib_detect_ix
ON xib_detect ( REPLACE ( REPLACE ( REPLACE ( REPLACE ( KEY1
escape '\'
ESCAPE is an option that you can use with the LIKE operator. It gives you a mechanism for cancelling the special meaning of symbols like '%'. You're not using the LIKE operator to create the index. You're only using REPLACE, and no characters have any special meaning in REPLACE, so there's no way (or reason) to escape them. Use ESCAPE in queries that use LIKE, when appropriate.

Function-Based Indexes for 8.1.6 SE and 9iAS

I have installed the 9iAS Portal into a 8.1.6 SE database, and I cannot get the Function-Based Index feature to turn on. I have set QUERY_REWRITE_INTEGRITY=trusted, QUERY_REWRITE_ENABLED=true and COMPATIBLE="8.1.0.0.0". The feature will still not enable.
I have 2 questions:
1. Is there anything else I can do to turn this feature on.
2. If not, do I have to upgrade to 8.1.7 or to 8.1.* Enterprise Edition to make use of this feature.

Could you give the statement for the index you have used, the query you try to do and a description of columns and datatypes of the table? How do you know/check that is doesn't work? Execution plan, errors?...

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 don't seem to work in Oracle 8.1.5?

Similar Messages

Maybe you are looking for