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

Similar Messages

  • 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

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

  • ORA-00439 while creating function based indexes.

    Hi everybody
    I'm working on Oracle 8.1.7 database, and try to create a function based index on a table.
    Unfortunately I get the ORA-00439 error, that recommends me not to use this feature :-(
    What should I do to activate this feature ?
    Thanx

    Try.
    SQL> select * from v$version;
    BANNER
    Oracle Database 10g Enterprise Edition Release 10.1.0.2.0 - 64bi
    PL/SQL Release 10.1.0.2.0 - Production
    CORE    10.1.0.2.0      Production
    TNS for Solaris: Version 10.1.0.2.0 - Production
    NLSRTL Version 10.1.0.2.0 - Production

  • Question on Function-based Indexes

    hi
    I have created one function based index on EMP table as follows
    SQL> CREATE INDEX UPP_ENAME ON EMP UPPER(ENAME);
    Index created.
    as well enable two parameters and analyze the table
    SQL> ALTER SESSION SET QUERY_REWRITE_ENABLED =TRUE;
    Session altered.
    SQL> ALTER SESSION SET QUERY_REWRITE_INTEGRITY =TRUSTED;
    Session altered.
    SQL> EXECUTE DBMS_STATS.GATHER_TABLE_STATS ('MYTEST','EMP');
    PL/SQL procedure successfully completed.
    and when I run the following query system is still not using this index.
    SQL> SELECT ENAME,EMPNO,JOB FROM EMP WHERE UPPER(ENAME) LIKE 'JAMES';
    ENAME EMPNO JOB
    JAMES 7900 CLERK
    Execution Plan
    0 SELECT STATEMENT Optimizer=CHOOSE (Cost=2 Card=1 Bytes=18)
    1 0 TABLE ACCESS (FULL) OF 'EMP' (Cost=2 Card=1 Bytes=18)
    Can anyone explain me why it is not being used.
    Thanks

    SQL> select count(*) "Rows" from acledger;
    Rows
    1444280
    SQL> set timing on
    SQL> select * from acledger where nserial like '1';
    NSERIAL DTRNDATE DDATEIN CACTCODE NTRNAMT NNARRATION NDOCUMENT
    NSOURCE NBRANCH NCURRENCY NEXCHANGE NFCYAMT
    1 24-OCT-96 24-OCT-96 650A10001 126876.5 1 200
    0 1 6 1 126876.5
    Elapsed: 00:00:14.85
    SQL> select * from acledger where nserial = '1';
    NSERIAL DTRNDATE DDATEIN CACTCODE NTRNAMT NNARRATION NDOCUMENT
    NSOURCE NBRANCH NCURRENCY NEXCHANGE NFCYAMT
    1 24-OCT-96 24-OCT-96 650A10001 126876.5 1 200
    0 1 6 1 126876.5
    Elapsed: 00:00:00.29
    SQL>
    Always "=" faster than "like" operator.
    Listen to all other members.
    Message was edited by:
    user526020
    Message was edited by:
    user526020

  • Why Segment shrink is not supported for tables with function-based indexes

    As we all know , Segment shrink is not supported for tables with function-based indexes.
    But i'm very confused .
    Why Segment shrink is not supported for tables with function-based indexes ?? what's its essential?

    Creating a function based index creates a hidden virtual column (you'll see it if you query user_tab_cols) and once you index a virtual column you can no longer shrink the table:orcl> create table t1(c1 number,c2 as (c1 * 2)) segment creation immediate;
    Table created.
    orcl> alter table t1 enable row movement;
    Table altered.
    orcl>
    orcl> alter table t1 shrink space;
    Table altered.
    orcl> create index i2 on t1(c2);
    Index created.
    orcl> alter table t1 shrink space;
    alter table t1 shrink space
    ERROR at line 1:
    ORA-10631: SHRINK clause should not be specified for this object
    orcl>so the issue is not with function based indexes per se, it is a level beneath that. Perhaps because the virtual column has no physical existance, when the row is moved there is no reason for Oracle to realize that an index needs updating? I haven't attempted to reverse engineer this, I would be interested to know if anyone else has.

  • 10.1.3 - Create Table Wizard - function based indexes?

    Is the ability to create function based indexes via the Create Table Wizard planned for the 10.1.3 production release?
    It appears the Wizard under step 7 has the ability to enter "function" expressions. However an error dialog appears if you enter anything but a column name.
    CM.

    Chris,
    Yes, this has been implemented for Production.
    Regards,
    Lisa Sherriff
    JDev QA

  • Function based indexes info,pls let me know data dictionary table name?

    Hi,
    pls let me know,Where can we find Function based index information ,that is data dictionary table name,.
    that is information like function used, column name.
    Thanks,
    KUmar.

    all_ind_expressions

  • ORA-04091 (table string.string is mutating) and Function-Based Index

    I've encountered a problem with DELETEing from a table when that table has a function-based index on it. The following demonstrates this:
    SQL> CREATE OR REPLACE FUNCTION get_employee_location(p_empno IN number)
      2  RETURN varchar2
      3  DETERMINISTIC
      4  IS
      5  l_return_value   varchar2(20);
      6  BEGIN
      7  SELECT loc
      8  INTO   l_return_value
      9  FROM   dept
    10  WHERE  deptno = (SELECT
    11                   e.deptno
    12                   FROM emp e
    13                   WHERE empno = p_empno);
    14  return l_return_value;
    15  end;
    16  /
    Function created.
    SQL> create index location_idx on emp (get_employee_location(empno));
    Index created.
    SQL> delete from emp;
    delete from emp
    ERROR at line 1:
    ORA-04091: table SCOTT.EMP is mutating, trigger/function may not see it
    ORA-06512: at "SCOTT.GET_EMPLOYEE_LOCATION", line 7------------------------------------------------
    The question is: How can I successfully DELETE FROM emp but keep my function-based index in place?
    Thanks
    Andy

    'Being able to' is 'being able to', but
    it is dangerous to declare "DETERMINISTIC" for non-deterministic function.
    The following problem happens on non-deterministic function index.
    SQL> update dept set loc = 'NEWYORK' where deptno=10;
    1 row updated.
    SQL> commit;
    Commit complete.
    SQL> select * from emp where get_employee_location(deptno)='NEWYORK';
    no rows selected
    SQL> select * from dept;
        DEPTNO DNAME          LOC
            10 ACCOUNTING     NEWYORK
            20 RESEARCH       DALLAS
            30 SALES          CHICAGO
            40 OPERATIONS     BOSTON
    SQL> select empno,ename from emp where get_employee_location(deptno)='NEW YORK';
         EMPNO ENAME
          7782 CLARK
          7839 KING
          7934 MILLER
    SQL> select empno,ename,get_employee_location(deptno) from emp where deptno=10;
         EMPNO ENAME      GET_EMPLOYEE_LOCATION(DEPTNO)
          7782 CLARK
          7839 KING
          7934 MILLER
    SQL> select empno,ename,get_employee_location(deptno) from emp where get_employee_location(deptno)='NEW YORK';
         EMPNO ENAME      GET_EMPLOYEE_LOCATION(DEPTNO)
          7782 CLARK      NEW YORK
          7839 KING       NEW YORK
          7934 MILLER     NEW YORK
    SQL> drop index location_idx ;
    Index dropped.
    SQL> select empno,ename from emp where get_employee_location(deptno)='NEW YORK';
    no rows selected

  • 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

  • Seqment shrink with function based indexes - 10.2.0.3

    I see 10g Rel 2 limiation with function based index while doing segment shrink. Is their a workaround? I tried to drop the function based index before shrink, still shrink is taking several hrs to complete.
    Any help is appreciated.
    Thanks,
    Siva

    Hi,
    Analogy: suppose you have 1 million barrels filled with water near 85% maybe less, now you spilled ...say 40% the total water, maybe you have 400,000 empty barrels or the equivalent (here comes the overhead) you are going to concentrate the water in 600,000 barrels and return the empty ones to the "Oracle Server" store, just to reclaim them gradually until you have the starting 1 million barrel.
    Our advise: keep the objects as they are, both table and index. Oracle will use released space as efficiently as he can, which is (at that level) better than us.
    You're worried about the index space? much better leave it now, that's the structure which may cause the major part of overhead.
    Regards
    Ignacio
    http://oracledisect.blogspot.com

  • Creating function-based indexes

    I'm trying to create a function-based index in one of the user's schemas and am getting an insufficient privilege error. Below are the examples:
    connect scott/tiger ;
    CREATE INDEX emp_ename_idx ON ename( emp ) ;
    Index created.
    CREATE INDEX upper_ename_idx ON ename( upper(ename)) ;
    ERROR at line1:
    ORA-01031: insufficient privileges
    The DBA granted the CREATE ANY INDEX privilege to user scott already. Any ideas???
    Thanks,
    SY

    Hi, all.
    I didn't hear about function-based index before, so I did some testing. Instead of using Oracle predefined functions (upper, lower, substr etc.), I created my own function and tried to create an index on it. I received an error that function is not deterministic. The definition of deterministic from Oracle docs:
    DETERMINISTIC
    This hint helps the optimizer avoid redundant function calls. If a stored function was called previously with the same arguments, the optimizer can elect to use the previous result. The function result should not depend on the state of session variables or schema objects. Otherwise, results might vary across calls. Only DETERMINISTIC functions can be called from a function-based index or a materialized view that has query-rewrite enabled.
    So, I put word deterministic in function declaration and everything works OK. Then I modified function to use some of the tables (I used tables across different schemas), recreated the index and it also worked fine.
    Question - is this statement correct: You can use schema objects in function which is in turn used for indexes as long as you put word deterministic in function declaration and all objects (function, index) will be valid, but ORACLE doesn't guarantee that result produced using that index will be correct?
    Thank you.

  • Function based indexes in Data Modeler 3.0

    Trying to create a function based index in DATA MODELER 3.0 but cannot find a way to do it. When I reverse engineer (import from DATA DICTIONNARY) an existing table that contains such an object, the index appears in the physical model as a regular index. I guess this functionnality is not yet available...
    Thanks.

    Hi,
    You can create a function-based Index by going to the Properties dialog for the Index in the Relational model (not the Physical model). If you select the Index Expression tick box, you can then enter the expression into the Expression text area.
    David

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

Maybe you are looking for