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.

Similar Messages

  • Storage for Foreign Keys and Function based indexes

    This may well be the silliest question of the day, but is it possible to specify the storage for a Foreign key or a function based index? I'm not even sure that it would make sense.

    Well, a foreign key constraint is not a segment, nor is any other type of constraint. However, a function-based index is a segment, just like any other index. So, in that case, specify a tablespace, just like you would with any other index.
    Something like this:
    create index my_fbi on my_tab(upper(last_name)) tablespace my_index_tablespace;
    -Mark
    Message was edited by:
    mbobak
    Fixed minor typo.

  • 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

  • Impdp not importing function based index correctly.

    We noticed that a process running in our develop database was running much faster than in the production database. After investigating we found that on the development database the process was using an index on the main large table and on the production database the index was ignored and full table scans of the large table were being used.
    The data in the tables was the same, statistics were up-to-date, etc. Looking closer we saw that the index on the production database was function based because it had the DESC keyword on one column in the index. On the development database all columns of the index were ASC and thus it was a "normal" index. This was very confusing since we had just refreshed the development database from production using expdp/impdp. I ran impdp with the sqlfiles option to capture the DDL from the export file for the index in question from the production database:
    CREATE UNIQUE INDEX "SYSADM"."PS_SF_1098_ITEM" ON "SYSADM"."PS_SF_1098_ITEM" ("EMPLID", "SF_TIN", "CALENDAR_YEAR", "SEQ_NO" DESC, "DTL_SEQ_NBR")
    PCTFREE 10 INITRANS 2 MAXTRANS 255
    STORAGE(INITIAL 40960 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
    PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
    TABLESPACE "PSINDEX" ;
    I then dropped the table/index in the development database and reimported just this one table. Sure enough, the index wasn't created as a function based index (no DESC keyword on SEQ_NO column):
    CREATE UNIQUE INDEX "SYSADM"."PS_SF_1098_ITEM" ON "SYSADM"."PS_SF_1098_ITEM" ("EMPLID", "SF_TIN", "CALENDAR_YEAR", "SEQ_NO", "DTL_SEQ_NBR")
    PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS
    STORAGE(INITIAL 40960 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
    PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
    TABLESPACE "PSINDEX" ;
    I've researched this extensively and can't find any information on why this is happening. Any ideas before I open a SR?
    BTW.... version is 11.1.0.7 patchset 31 on Windows Server 2003. Both dev and prod environments are identical.
    Thanks,
    Dan

    Working on something else I noticed the following two "hidden" init.ora parameters in both my dev and production databases:
    *._disable_function_based_index=TRUE
    *._ignore_desc_in_index=TRUE
    The first parameter explains why the index (function based) was being ignored in my production database. The second explains why the index is created without the DESC keyword in my dev database from an export from my prod database. I guess you do learn something new every day :)
    These databases are used by Peoplesoft applications and I found several posts saying that function based indexes created by Peoplesoft were causing performance and/or data validity problems and users were instructed to set the above parameters so the FIB's weren't used. So, everything is working as expected/designed. I will contact Peoplesoft Tech Support to see if users are still encouraged to set the above parameters.
    Dan

  • 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]

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

  • 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

  • Function-based indexes

    Oracle documentation on "How Function-Based Indexes Work" states that for the creation of a function-based index in the user's own schema, the user must be granted the QUERY REWRITE system privileges. And 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.
    I have created a function-based unique index, which uses the SQL function DECODE(). But the user doesn't have the QUERY REWRITE sytem privilege. The user has the following privileges:
    CREATE PROCEDURE
    CREATE SEQUENCE
    CREATE SESSION
    CREATE TABLE
    CREATE TRIGGER
    CREATE VIEW
    And also the initialization parameters for QUERY_REWRITE_INTEGRITY and QUERY_REWRITE_ENABLED are set to their DEFAULT values as follows:
    QUERY_REWRITE_INTEGRITY set to ENCFORCED
    QUERY_REWRITE_ENABLED set to FALSE.
    Note: The index is an unique index for data integrity purpose. I am using Oracle 9.2.0.6 version.
    Kindly explain me the reason how the function-based index is created without the system privilege and the initialization parmaters defined as stated in the Oracle9i Database Administrator's Guide Release 2 (9.2).

    You can change those parameter at session level as well.
    Following link would be helpful:
    http://asktom.oracle.com/pls/ask/f?p=4950:8:2552324147195810457::NO::F4950_P8_DISPLAYID,F4950_P8_CRITERIA:667694821129
    Jaffar

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

  • Unable to create function based Index

    Hi All,
    I created a function as below:
    create or replace function eqx_oklb_term_date_nvl(pin_term_date date)
    return date
    deterministic
    is
    l_sub_date date := sysdate+1;
    l_return_value date := l_sub_date;
    begin
    l_return_value := nvl(pin_term_date, l_sub_date);
    return l_return_value;
    exception
    when others
    then
    l_return_value := l_sub_date;
    return l_return_value;
    end eqx_oklb_term_date_nvl;
    Now trying to create a function based index using below code:
    create index EQX_OKC_K_LINES_B_N4 on OKC.OKC_K_LINES_B(EQX_OKLB_TERM_DATE_NVL(DATE_TERMINATED))
    logging
    tablespace EQIXDATA
    noparallel;
    Encountered Error:
    SQL Error: ORA-00904: "EQX_OKLB_TERM_DATE_NVL": invalid identifier
    00904. 00000 - "%s: invalid identifier"
    *Cause:   
    *Action:
    I can successfully query dba_objects for the function.
    Owner Object_name object_id object_type last_ddl_time status
    APPS     EQX_OKLB_TERM_DATE_NVL     11764623     FUNCTION     3/4/2013 9:44:57 PM     VALID
    I can also query the function using dual.
    select eqx_oklb_term_date_nvl(null) nvl_date from dual;
    nvl_date
    3/5/2013 9:53:59 PM
    I have given grants of the function to both schemas APPS/OKC
    grant all on eqx_oklb_term_date_nvl to okc;
    grant all on eqx_oklb_term_date_nvl to apps;
    The column date_terminated in table okc_k_lines_b is a date. I've checked that.
    Stuck here. Please help.
    Thanks in advance,
    Rahul

    Hi,
    To follow up, the below code resolved the issue:
    create index EQX_OKC_K_LINES_B_N4 on okc_k_lines_b(apps.eqx_oklb_term_date_nvl(date_terminated))
    logging
    tablespace eqixdata
    noparallel;
    -- qualifying the custom function name with schema name resolved the issue.
    Thanks,
    Rahul

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

  • Function Based index getting disabled frequently

    I am facing some error like “ORA-30554: function-based index ORADB1.FUN_INDX1 is disabled” in the development database. I verified that the function which is referred by the index is valid. Once I even got the tedious generic error ORA-600 because of this. I referred the metalink and advised to drop and recreate the index
    Dropping and recreating the index will solve the issue for 2-3 days and again the same will be repeated. So what I did is made the index unusable as it will not affect the other application activities. Can anybody give a clue on this issue?

    I am facing some error like “ORA-30554:
    function-based index ORADB1.FUN_INDX1 is disabled” Cause: An attempt was made to access a function-based index that has been marked disabled because the function on which the index depends has been changed.
    Action: Perform one of the following actions: -- drop the specified index using the DROP INDEX command -- rebuild the specified index using the ALTER INDEX REBUILD command -- enable the specified index using the ALTER INDEX ENABLE command -- make the specified index usable using the ALTER INDEX UNUSABLE command

  • Function Based Index MOD(column_name,8)

    For a function based index (MOD(column_name,8), the query is not using it. Do anyone have a solution to it? The table is having millions of rows.

    Oracle only uses indexes if the number of returned rows is less than (i think) 4%. In your case the number of rows is 12,5% so Oracle will never use this index unless you force it

Maybe you are looking for