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]

Similar Messages

  • Performance with dates in the where clause

    Performance with dates in the where clause
    CREATE TABLE TEST_DATA
    FNUMBER NUMBER,
    FSTRING VARCHAR2(4000 BYTE),
    FDATE DATE
    create index t_indx on test_data(fdata);
    query 1: select count(*) from TEST_DATA where trunc(fdate) = trunc(sysdate);
    query 2: select count(*) from TEST_DATA where fdate between trunc(sysdate) and trunc(SYSDATE) + .99999;
    query 3: select count(*) from TEST_DATA where fdate between to_date('21-APR-10', 'dd-MON-yy') and to_date('21-APR-10 23:59:59', 'DD-MON-YY hh24:mi:ss');
    My questions:
    1) Why isn't the index t_indx used in Execution plan 1?
    2) From the execution plan, I see that query 2 & 3 is better than query 1. I do not see any difference between execution plan 2 & 3. Which one is better?
    3) I read somewhere - "Always check the Access Predicates and Filter Predicates of Explain Plan carefully to determine which columns are contributing to a Range Scan and which columns are merely filtering the returned rows. Be sceptical if the same clause is shown in both."
    Is that true for Execution plan 2 & 3?
    3) Could some one explain what the filter & access predicate mean here?
    Thanks in advance.
    Execution Plan 1:
    SQL> select count(*) from TEST_DATA where trunc(fdate) = trunc(sysdate);
    COUNT(*)
    283
    Execution Plan
    Plan hash value: 1486387033
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
    | 0 | SELECT STATEMENT | | 1 | 9 | 517 (20)| 00:00:07 |
    | 1 | SORT AGGREGATE | | 1 | 9 | | |
    |* 2 | TABLE ACCESS FULL| TEST_DATA | 341 | 3069 | 517 (20)| 00:00:07 |
    Predicate Information (identified by operation id):
    2 - filter(TRUNC(INTERNAL_FUNCTION("FDATE"))=TRUNC(SYSDATE@!))
    Note
    - dynamic sampling used for this statement
    Statistics
    4 recursive calls
    0 db block gets
    1610 consistent gets
    0 physical reads
    0 redo size
    412 bytes sent via SQL*Net to client
    380 bytes received via SQL*Net from client
    2 SQL*Net roundtrips to/from client
    0 sorts (memory)
    0 sorts (disk)
    1 rows processed
    Execution Plan 2:
    SQL> select count(*) from TEST_DATA where fdate between trunc(sysdate) and trunc(SYSDATE) + .99999;
    COUNT(*)
    283
    Execution Plan
    Plan hash value: 1687886199
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
    | 0 | SELECT STATEMENT | | 1 | 9 | 3 (0)| 00:00:01 |
    | 1 | SORT AGGREGATE | | 1 | 9 | | |
    |* 2 | FILTER | | | | | |
    |* 3 | INDEX RANGE SCAN| T_INDX | 283 | 2547 | 3 (0)| 00:00:01 |
    Predicate Information (identified by operation id):
    2 - filter(TRUNC(SYSDATE@!)<=TRUNC(SYSDATE@!)+.9999884259259259259259
    259259259259259259)
    3 - access("FDATE">=TRUNC(SYSDATE@!) AND
    "FDATE"<=TRUNC(SYSDATE@!)+.999988425925925925925925925925925925925
    9)
    Note
    - dynamic sampling used for this statement
    Statistics
    7 recursive calls
    0 db block gets
    76 consistent gets
    0 physical reads
    0 redo size
    412 bytes sent via SQL*Net to client
    380 bytes received via SQL*Net from client
    2 SQL*Net roundtrips to/from client
    0 sorts (memory)
    0 sorts (disk)
    1 rows
    Execution Plan 3:
    SQL> select count(*) from TEST_DATA where fdate between to_date('21-APR-10', 'dd-MON-yy') and to_dat
    e('21-APR-10 23:59:59', 'DD-MON-YY hh24:mi:ss');
    COUNT(*)
    283
    Execution Plan
    Plan hash value: 1687886199
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
    | 0 | SELECT STATEMENT | | 1 | 9 | 3 (0)| 00:00:01 |
    | 1 | SORT AGGREGATE | | 1 | 9 | | |
    |* 2 | FILTER | | | | | |
    |* 3 | INDEX RANGE SCAN| T_INDX | 283 | 2547 | 3 (0)| 00:00:01 |
    Predicate Information (identified by operation id):
    2 - filter(TO_DATE('21-APR-10','dd-MON-yy')<=TO_DATE('21-APR-10
    23:59:59','DD-MON-YY hh24:mi:ss'))
    3 - access("FDATE">=TO_DATE('21-APR-10','dd-MON-yy') AND
    "FDATE"<=TO_DATE('21-APR-10 23:59:59','DD-MON-YY hh24:mi:ss'))
    Note
    - dynamic sampling used for this statement
    Statistics
    7 recursive calls
    0 db block gets
    76 consistent gets
    0 physical reads
    0 redo size
    412 bytes sent via SQL*Net to client
    380 bytes received via SQL*Net from client
    2 SQL*Net roundtrips to/from client
    0 sorts (memory)
    0 sorts (disk)
    1 rows processed

    Hi,
    user10541890 wrote:
    Performance with dates in the where clause
    CREATE TABLE TEST_DATA
    FNUMBER NUMBER,
    FSTRING VARCHAR2(4000 BYTE),
    FDATE DATE
    create index t_indx on test_data(fdata);Did you mean fdat<b>e</b> (ending in e)?
    Be careful; post the code you're actually running.
    query 1: select count(*) from TEST_DATA where trunc(fdate) = trunc(sysdate);
    query 2: select count(*) from TEST_DATA where fdate between trunc(sysdate) and trunc(SYSDATE) + .99999;
    query 3: select count(*) from TEST_DATA where fdate between to_date('21-APR-10', 'dd-MON-yy') and to_date('21-APR-10 23:59:59', 'DD-MON-YY hh24:mi:ss');
    My questions:
    1) Why isn't the index t_indx used in Execution plan 1?To use an index, the indexed column must stand alone as one of the operands. If you had a function-based index on TRUNC (fdate), then it might be used in Query 1, because the left operand of = is TRUNC (fdate).
    2) From the execution plan, I see that query 2 & 3 is better than query 1. I do not see any difference between execution plan 2 & 3. Which one is better?That depends on what you mean by "better".
    If "better" means faster, you've already shown that one is about as good as the other.
    Queries 2 and 3 are doing different things. Assuming the table stays the same, Query 2 may give different results every day, but the results of Query 3 will never change.
    For clarity, I prefer:
    WHERE     fdate >= TRUNC (SYSDATE)
    AND     fdate <  TRUNC (SYSDATE) + 1(or replace SYSDATE with a TO_DATE expression, depending on the requirements).
    3) I read somewhere - "Always check the Access Predicates and Filter Predicates of Explain Plan carefully to determine which columns are contributing to a Range Scan and which columns are merely filtering the returned rows. Be sceptical if the same clause is shown in both."
    Is that true for Execution plan 2 & 3?
    3) Could some one explain what the filter & access predicate mean here?Sorry, I can't.

  • Select with timestamp in the where-clause don't work after importing data

    Hello,
    I have to databases (I call them db1 and db2, they have the same datastructure) and exported some data from the table "rfm_meas"from db1. Later on I imported that dataset into the "rfm_meas"-table of db2. The table contains a col with the datatype "timestamp(6)" and checking the success of the import looks fine:
    (executed on db2)
    SELECT
    id,acqtime
    from
    rfm_meas
    WHERE
    box_id=1
    AND id>145029878
    Returns two rows:
    ID ACQTIME
    145029883 01.06.10 10:30:00,000000000
    145029884 01.06.10 10:50:00,000000000
    It seems there are valid timestamps as I expected.
    But if I now want to select all rows from box_id=1 which are newer than e.g. 25-may-2010 I would try this:
    SELECT
    id,acqtime
    from
    rfm_meas
    WHERE
    box_id=1
    AND acqtime>=to_timestamp('25-05-2010 17:10:00,000','DD-MM-YYYY HH24:MI:SS,FF3')
    And it returns ... nothing!? If I execute the same query on db1 it works correctly.
    I guess db1 and db2 has different codepages!?
    If I insert some rows from a PL/SQL script in db2 into the "rfm_meas"-table, querys like the one above works fine. Therefore i guess, during importing the data there must be something wrong, so I cann see the timestamp, but can't use it.
    How can i fix that? Any ideas?
    If someone need more details I will provide it.
    Regards
    Steffen

    check this link out
    Importing timestamp columns appears to use to_date instead of to_timestamp

  • 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 indexes on object tables

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

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

  • Function based indexes 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

  • 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

  • Does this query need function based index?

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

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

  • 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

  • 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 index Issue

    Hi Guys,
    We are running Oracle 8.1.7 Database on Solaris server. We created function based indexes, while executing queries the function based indexes are not being used. Only if we use a hint in the query the indexes are being used. Is this a bug in oracle 8.1.7 or is this is how the function based indexes have to be used. Can somebody clarify this issue, I will appreciate your help. Thanks in advance.

    First, have you analyzed the tables recently? I believe you have to be using the CBO if you're using function based indexes. If the CBO has bad statistics, it may be generating bad plans.
    Second, can you post the query & the plan (with and without the hint)? Is it possible that the CBO is finding a better plan than using the index?
    Justin

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

  • 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 Indexes in Primary Key Definition

    Hello.
    I have been looking into function based indexes. I have been able to create them using unique indexes. However, when I try to create them on primary keys, the engine complains.
    Any ideas? Does anyone know if you can create function based indexes on primary keys?
    An example would be great!
    Thanks,
    Brad

    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

Maybe you are looking for

  • Credit note due date

    Hi Client wants the due date in a credit note (A/R) to reflect a date according to the Payment term of a customer. This I can achieve with a formatted search. The payment terms for  customers are - 30 days Due date based on posting date Start from mo

  • Date format in windowes 7

    i have problem with date format in developer 10g and developer 6i it show date in this format 2011/25/1 it sould be like this 25/1/2011 i put the format mask like dd/mm/yyyy but it showing lik 2011/25/1 this problem only in windowes 7 if i run in win

  • Firefox ShadowDoc out of sync, how do I issue a "cache document" command?

    frequently getting error message that ShadowDoc is out of sync because typing or pasting of text has been detected. Issue a "cache document: command to sync Dragon Dictate with your document

  • Restriction in PO

    hi all Good morning, i want to restrict line item deletion after MIGO/ MIRO done for respective PO. is it possible ?

  • Interop assembly generates AccessViol​ationExcep​tion

    Hi, I am writing a .Net application that needs to read/write to an FPGA via DMA.  To do this I've written some LabVIEW VIs that do the read/write, generated a .net interop assembly and successfully incorportated this into my application.  The APIs ge