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.

Similar Messages

  • Differences between function based index and normal index

    Hi,
    Please Give me some differences between function based index and normal indexes.
    1. Is there any performance gain in function based index?
    2. Why indexes created in DESC are treated as function based?
    3. Every DESC index is b-tree index?
    Thanks

    check this link. This would give u a basic idea of what a function based index is .
    http://www.oracle-base.com/articles/8i/FunctionBasedIndexes.php
    --Prasad                                                                                                                                                                                                                                                                                                                                       

  • Like condition in the where clause.

    Dear All,
    I have created a new form using a datablock wizard with one table.
    Now i placed a text box and a button in the same form. I will be entering the value in the text box and based up the condition in the where clause of the datablock property i am restricting the values where the column name is thetext box value.
    Now my problem is i need to give a string value in the text box and the datablokc has to populate based up the like condtion. I dont know the syntax how to give like condition in the where clause of the property pallet.
    Please help me in this.
    Thanks in advance.
    Cheers,
    Raju

    Maybe try this ...
    Create a button to query the block :
    In the WHEN-BUTTON-PRESSED-Trigger enter :
    DECLARE
        v_block_def_where         VARCHAR2(255)     := '1 = 1';
    BEGIN
        v_block_def_where := v_block_def_where || ' AND NAME_OF_YOUR_TABLE_COLUMN LIKE ''' || '%' || :NAME_OF_YOUR_BLOCK.SEARCH_ITEM || '%' ||  '''';
        SET_BLOCK_PROPERTY('NAME_OF_YOUR_BLOCK', DEFAULT_WHERE, v_block_def_where);
        GO_BLOCK('NAME_OF_YOUR_BLOCK');
        EXECUTE_QUERY;
    END;

  • Include dynamic conditions in the where clause

    Hi All,
    I have an requirement where i need to dynamically include the conditions in the where clause based on the bind variable.
    My condition is like this.
    SELECT f.scheduled_date, a.bld_id, a.room_id, a.cage_id, f.test_num
    FROM feeding_test_results f,
    v_onl_gf_anmls a
    WHERE f.sak_feeding_test_res > 5000000
    AND f.anml_id(+) = a.anml_id
    AND f.bld_id = 'A5'
    AND f.room_id > 0
    AND f.cage_id > '0'
    case when :check_value = 1 Then
    AND scheduled_date <= '16-Apr-2009'
    AND scheduled_date >= '06-Apr-2009'
    Else
    AND scheduled_date = '16-Apr-2009'
    End
    AND f.feeding_status <> 'X') f
    Kindly anyone help me how to acheive this.
    Thanks & Regards,
    P. Gayathri Devi

    michaels2 wrote:
    and scheduled_date <= case when :check_value = 1 then date '2009-04-16' end
    and scheduled_date >= case when :check_value = 1 then date '2009-04-06' end
    and scheduled_date = case when not :check_value = 1 then date '2009-04-16' end
    Hmmm, you may want some NVL's around those case statements such as..
           and scheduled_date <= NVL(case when :check_value = 1 then date '2009-04-16' end,scheduled_date)
           and scheduled_date >= NVL(case when :check_value = 1 then date '2009-04-06' end,scheduled_date)
           and scheduled_date = NVL(case when not :check_value = 1 then date '2009-04-16' end,,scheduled_date)or some such thing. Otherwise the comparisons with Null will just cause it all to fail.

  • Function Based Index And Selectivity

    Hi All,
    I have some doubts w.r.t FBI.I am on 10gR2 (10.2.0.4) with Solaris 5.9
    I was under impression that FBI does not provide guaranteed index access and CBO choose access pattern purely on basis of available stats and query selectivity.
    However, many a times i found that CBO is going for FBI even in case when FTS provides better query elapsed time.
    I created following test case:
    create table fbi_test (id number,flag varchar2(1));
    begin
    for i in 1..1000000
    loop
    insert into fbi_test values(i,'Y');
    end loop;
    end;
    commit;
    begin
    for i in 1..10
    loop
    insert into fbi_test values(i,'N');
    end loop;
    end;
    commit;
    ANALYZE TABLE FBI_TEST COMPUTE STATISTICS;
    CREATE INDEX fbi_test_FBI
    ON fbi_test (CASE WHEN flag = 'Y' THEN 1 ELSE NULL END);
    Autotrace for FBI ACCESS
    SQL> select *from fbi_test where (CASE WHEN flag = 'Y' THEN 1 ELSE NULL END)=1;
    1000000 rows selected.
    Elapsed: 00:00:18.43
    Execution Plan
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
    | 0 | SELECT STATEMENT | | 10000 | 50000 | 342 (1)|
    | 1 | TABLE ACCESS BY INDEX ROWID| FBI_TEST | 10000 | 50000 | 342 (1)|
    |* 2 | INDEX RANGE SCAN | FBI_TEST_FBI | 4000 | | 1958 (1)|
    Statistics
    0 recursive calls
    0 db block gets
    136812 consistent gets
    0 physical reads
    0 redo size
    22180292 bytes sent via SQL*Net to client
    733814 bytes received via SQL*Net from client
    66668 SQL*Net roundtrips to/from client
    0 sorts (memory)
    0 sorts (disk)
    1000000 rows processed
    Autotrace for FTS
    SQL> select *from fbi_test where flag = 'Y';
    1000000 rows selected.
    Elapsed: 00:00:16.56
    Execution Plan
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
    | 0 | SELECT STATEMENT | | 500K| 2441K| 371 (9)|
    |* 1 | TABLE ACCESS FULL| FBI_TEST | 500K| 2441K| 371 (9)|
    Statistics
    0 recursive calls
    0 db block gets
    68372 consistent gets
    0 physical reads
    0 redo size
    22180292 bytes sent via SQL*Net to client
    733814 bytes received via SQL*Net from client
    66668 SQL*Net roundtrips to/from client
    0 sorts (memory)
    0 sorts (disk)
    1000000 rows processed
    FYI...
    SQL> show parameter opt
    NAME TYPE VALUE
    filesystemio_options string asynch
    object_cache_optimal_size integer 102400
    optimizer_dynamic_sampling integer 2
    optimizer_features_enable string 10.2.0.3
    optimizer_index_caching integer 0
    optimizer_index_cost_adj integer 100
    optimizer_mode string ALL_ROWS
    optimizer_secure_view_merging boolean TRUE
    plsql_optimize_level integer 2
    My questions are,
    1.why oracle optimizer is going for FBI with high cardinality of 100000 rows?
    2.Why cost of FTS is high (371) as compare to FBI (342) eventhough FTS is having fewer IO (68372) + Less Elapsed Time?
    3.Why Optimizer is considering ELAPSED TIME during plan generation?
    Any inpute would be highly appreciated.

    user635930 wrote:
    Hi All,
    I have some doubts w.r.t FBI.I am on 10gR2 (10.2.0.4) with Solaris 5.9
    Execution Plan
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
    | 0 | SELECT STATEMENT | | 10000 | 50000 | 342 (1)|
    | 1 | TABLE ACCESS BY INDEX ROWID| FBI_TEST | 10000 | 50000 | 342 (1)|
    |* 2 | INDEX RANGE SCAN | FBI_TEST_FBI | 4000 | | 1958 (1)|
    ---------------------------------------------------------------------------------You're seeing three different effects here.
    First - for the table access by index, Oracle has "lost" the cost of the index range scan - notice that the total cost of the query is 342, but the cost of the index access is 1958. The total cost of the query should be 2,300 and Oracle should have chosen the full tablescan automatically.
    Second, the stats on the index show just one distinct value for "distinct_keys", and the optimizer has decided (for no reason I can think of - it may be a bug) to assume a 0.4% selectivity on the index.
    Third, the estimated cardinality of the table and index lines differs. Whatever Oracle has done in the index line has been forgotten, and the cardinality of the table line has been based on the predicate given by your case statement and, as a "complex function", that predicate has been given a selectivity of 1% - hence the 10,000 rows estimate.
    The combination of unsuitable statistics, an extreme case, and a couple of quirks in the optimizer mean that the chosen path is clearly unsuitable.
    [Addendum]: It just occurred to me that part of the problem is that you collected stats on the table before you created the index. Given you're running 10g, the 'create index' would automatically generate index stats at the same time - but since it's a function-based index, there's a "virtual column" created for the table as well, and that column won't have any statistics on it - which is why you get the "fixed percentage" selectivities.
    Regards
    Jonathan Lewis
    http://jonathanlewis.wordpress.com
    http://www.jlcomp.demon.co.uk
    "Science is more than a body of knowledge; it is a way of thinking" Carl Sagan
    Edited by: Jonathan Lewis on Nov 29, 2008 1:15 PM

  • Function based Indexes and user_tab_cols

    Why an entry is created in user_tab_cols when we create a function based on a column of a table?
    create table t1(a varchar2(100), b number); 
    select * from user_tab_cols where table_name = 'T1'; -- Two rows coming 
    create index idx1 on t1(upper(a));
    select * from user_tab_cols where table_name = 'T1'; -- Three rows coming
    What is the reason to put an entry in user_tab_cols?

    Hi,
    Martin Preiss wrote:
    if my memory serves me well there is also an attribute VIRTUAL_COLUMN in %_TAB_COLS (at least since 11.1).
    This is interesting!
    In Oracle 11.2.0.2.0, when logged in as a developer with limited privileges, I don't see that column when using DESCRIBE:
    SQL> desc user_tab_columns
    Name                                      Null?    Type
    TABLE_NAME                                NOT NULL VARCHAR2(30)
    COLUMN_NAME                               NOT NULL VARCHAR2(30)
    DATA_TYPE                                          VARCHAR2(106)
    DATA_TYPE_MOD                                      VARCHAR2(3)
    DATA_TYPE_OWNER                                    VARCHAR2(120)
    DATA_LENGTH                               NOT NULL NUMBER
    DATA_PRECISION                                     NUMBER
    DATA_SCALE                                         NUMBER
    NULLABLE                                           VARCHAR2(1)
    COLUMN_ID                                          NUMBER
    DEFAULT_LENGTH                                     NUMBER
    DATA_DEFAULT                                       LONG
    NUM_DISTINCT                                       NUMBER
    LOW_VALUE                                          RAW(32)
    HIGH_VALUE                                         RAW(32)
    DENSITY                                            NUMBER
    NUM_NULLS                                          NUMBER
    NUM_BUCKETS                                        NUMBER
    LAST_ANALYZED                                      DATE
    SAMPLE_SIZE                                        NUMBER
    CHARACTER_SET_NAME                                 VARCHAR2(44)
    CHAR_COL_DECL_LENGTH                               NUMBER
    GLOBAL_STATS                                       VARCHAR2(3)
    USER_STATS                                         VARCHAR2(3)
    AVG_COL_LEN                                        NUMBER
    CHAR_LENGTH                                        NUMBER
    CHAR_USED                                          VARCHAR2(1)
    V80_FMT_IMAGE                                      VARCHAR2(3)
    DATA_UPGRADED                                      VARCHAR2(3)
    HISTOGRAM                                          VARCHAR2(15)
    But when logged in as SYSTEM on the same database, I do see it:
    SQL> DESC USER_TAB_COLS
    Name                                      Null?    Type
    TABLE_NAME                                NOT NULL VARCHAR2(30)
    COLUMN_NAME                               NOT NULL VARCHAR2(30)
    DATA_TYPE                                          VARCHAR2(106)
    DATA_TYPE_MOD                                      VARCHAR2(3)
    DATA_TYPE_OWNER                                    VARCHAR2(120)
    DATA_LENGTH                               NOT NULL NUMBER
    DATA_PRECISION                                     NUMBER
    DATA_SCALE                                         NUMBER
    NULLABLE                                           VARCHAR2(1)
    COLUMN_ID                                          NUMBER
    DEFAULT_LENGTH                                     NUMBER
    DATA_DEFAULT                                       LONG
    NUM_DISTINCT                                       NUMBER
    LOW_VALUE                                          RAW(32)
    HIGH_VALUE                                         RAW(32)
    DENSITY                                            NUMBER
    NUM_NULLS                                          NUMBER
    NUM_BUCKETS                                        NUMBER
    LAST_ANALYZED                                      DATE
    SAMPLE_SIZE                                        NUMBER
    CHARACTER_SET_NAME                                 VARCHAR2(44)
    CHAR_COL_DECL_LENGTH                               NUMBER
    GLOBAL_STATS                                       VARCHAR2(3)
    USER_STATS                                         VARCHAR2(3)
    AVG_COL_LEN                                        NUMBER
    CHAR_LENGTH                                        NUMBER
    CHAR_USED                                          VARCHAR2(1)
    V80_FMT_IMAGE                                      VARCHAR2(3)
    DATA_UPGRADED                                      VARCHAR2(3)
    HIDDEN_COLUMN                                      VARCHAR2(3)
    VIRTUAL_COLUMN                                     VARCHAR2(3)
    SEGMENT_COLUMN_ID                                  NUMBER
    INTERNAL_COLUMN_ID                        NOT NULL NUMBER
    HISTOGRAM                                          VARCHAR2(15)
    QUALIFIED_COL_NAME                                 VARCHAR2(4000)
    I can see that column in ALL_TAB_COLS either way.

  • How to use multiple search conditions in the where clause

    Hi,
    Below is my query
    /****** Script for SelectTopNRows command from SSMS  ******/
    SELECT distinct 
    ctacct,sum(GLMN02)
      FROM [ODS].[Staging].[tODS_INF_GLPCT]
      inner join 
      [ODS].[Staging].[tODS_INF_GLPGL] ON tODS_INF_GLPCT.CTPAGE = tODS_INF_GLPGL.GLPAGE
      where 
      CTACCT like '[0-9][0-9][0-9]-[0-9][0-9][0-9]-63020-4110%'
    This one gives me the exact result i want, now if i add one more to my where clause like this
    /****** Script for SelectTopNRows command from SSMS  ******/
    SELECT distinct 
    ctacct,sum(GLMN02)
    --,ctdesc,CTPAGE
    --SUM(GLMN02)
      FROM [ODS].[Staging].[tODS_INF_GLPCT]
      inner join 
      [ODS].[Staging].[tODS_INF_GLPGL] ON tODS_INF_GLPCT.CTPAGE = tODS_INF_GLPGL.GLPAGE
      where 
      CTACCT like'[0-9][0-9][0-9]-[0-9][0-9][0-9]-63020-4110%' or
      CTACCT like '[0-9][0-9][0-9]-[0-9][0-9][0-9]-63020-4115%'
    This query doesnt give me the exact values instead it gives me all the weird values.Can someone please help me with how to work on this where clause?
    Thanks

    Hi Patrick,
    This is what i ve tried earlier and it isnt working .If i use the first query
    /****** Script for SelectTopNRows command from SSMS  ******/
    SELECT distinct 
    ctdesc,SUM(GLMN02)
    --,ctdesc,CTPAGE
    --SUM(GLMN02)
      FROM [ODS].[Staging].[tODS_INF_GLPCT]
      inner join 
      [ODS].[Staging].[tODS_INF_GLPGL] ON tODS_INF_GLPCT.CTPAGE = tODS_INF_GLPGL.GLPAGE
      where 
     CTAcct LIKE '[0-9][0-9][0-9]-[0-9][0-9][0-9]-63020-4110%'
       --OR
       --CTAcct LIKE '[0-9][0-9][0-9]-[0-9][0-9][0-9]-63020-4115%'
      and GLYEAR = 2014
      and CTDESC = 'Sales'
      group by ctdesc
    The result set is 
    Sales                        
    -182273.96
    And if i use the second query
    SELECT distinct 
    ctdesc,SUM(GLMN02)
    --,ctdesc,CTPAGE
    --SUM(GLMN02)
      FROM [ODS].[Staging].[tODS_INF_GLPCT]
      inner join 
      [ODS].[Staging].[tODS_INF_GLPGL] ON tODS_INF_GLPCT.CTPAGE = tODS_INF_GLPGL.GLPAGE
      where 
     CTAcct LIKE '[0-9][0-9][0-9]-[0-9][0-9][0-9]-63020-4110%'
     OR
       CTAcct LIKE '[0-9][0-9][0-9]-[0-9][0-9][0-9]-63020-4115%'
      and GLYEAR = 2014
      and CTDESC = 'Sales'
      group by ctdesc
    The result set i get is 
    Sales                        
    -1455441.08
    And i verified that  CTAcct LIKE '[0-9][0-9][0-9]-[0-9][0-9][0-9]-63020-4115%'
    this second line of where clause has not desc as Sales.
    I am not sure whats causing the difference in the values.
    Can you please help me with this?
    Thanks

  • Function Based Index and ORA-01450

    The following DDL produces ORA-01450 (maximum key length (758) exceeded) :
    create index test_fn_ix1 on ausv_int_acc (test_package.test_function(intacc_username));
    Here's the package :
    create or replace package test_package
    is
    function test_function (value_in varchar2) return varchar2 deterministic;
    end test_package;
    create or replace package body test_package
    is
    function test_function (value_in varchar2) return varchar2
    is
    begin
    return ''&#0124; &#0124;value_in;
    end test_function;
    end test_package;
    Obviously this is only a test function but I have a real function I want to use - I have just tried to simplify the problem.
    How does Oracle know how long the function result is ? - it doesn't because you can't specify return length of a function, just the type !
    I have got round this problem thus :
    create index test_fn_ix1 on ausv_int_acc (substr(test_package.test_function(intacc_username),1,100));
    Surly there's a tidier way ???
    Thanks for any help
    Angus

    Hi,
    You can add SUBSTRs, like this:
    CREATE UNIQUE INDEX addresses_uq1
           ON addresses ( UPPER( SUBSTR (REGEXP_REPLACE( STREET1,'([^[:alnum:]])',''), 1, 50) ),
                          UPPER( SUBSTR (REGEXP_REPLACE( STREET2,'([^[:alnum:]])',''), 1, 50) ),
                          UPPER( SUBSTR (REGEXP_REPLACE( CITY,   '([^[:alpha:]])',''), 1, 50) ),
                          COUNTRY_CODE,
                          STATE_CODE );Why?
    Try this:
    CREATE OR REPLACE VIEW  view_x
    AS
    SELECT  UPPER( REGEXP_REPLACE( STREET1,'([^[:alnum:]])','') )     AS street1
    FROM     addresses;
    DESC     view_xYou'll see that view_x.street1 is VARCHAR2 *(4000)* .
    You and I know that the REGEXP_REPLACE function is taking a 50-character (max) string, and, if anything, reducing its size. But the system doesn't figure out what REGEXP_REPLACE is doing; for all it knows, REGEXP_REPLACE could be returning any VARCHAR2, so it allows room for the biggest possible VARCHAR2.

  • 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

  • Oracle 8i Function-based index

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

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

  • 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

  • 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

  • Problem using two function based indexes at once!

    Hello Oracle!
    I've got problems using two function based indexes on geometries at once.
    The problem occures, when I use a spatial join between two geometries both using function based indexes.
    The test case:
    CREATE TABLE quad (centroid NUMBER);
    CREATE TABLE points (no NUMBER, point MDSYS.SDO_GEOMETRY);
    CREATE OR REPLACE FUNCTION getQuad (centroid NUMBER) RETURN MDSYS.SDO_GEOMETRY DETERMINISTIC IS
    BEGIN
    RETURN MDSYS.SDO_GEOMETRY(2003, NULL, NULL, MDSYS.SDO_ELEM_INFO_ARRAY(1,1003,1),MDSYS.SDO_ORDINATE_ARRAY(centroid-5,centroid-5,centroid+5,centroid-5,centroid+5,centroid+5,centroid-5,centroid+5,centroid-5,centroid-5));
    END;
    INSERT INTO USER_SDO_GEOM_METADATA VALUES('quad','tiedge.getQuad(centroid)',MDSYS.SDO_DIM_ARRAY(MDSYS.SDO_DIM_ELEMENT('X', -100, 100, .0000001), MDSYS.SDO_DIM_ELEMENT('Y', -100, 100, .0000001)),NULL);
    CREATE INDEX quad_idx on quad(getQuad(centroid)) INDEXTYPE IS MDSYS.SPATIAL_INDEX;
    INSERT INTO quad VALUES (0);
    INSERT INTO quad VALUES (5);
    INSERT INTO quad VALUES (10);
    INSERT INTO points VALUES (1, MDSYS.SDO_GEOMETRY(1001,NULL,NULL,MDSYS.SDO_ELEM_INFO_ARRAY(1,1,1),MDSYS.SDO_ORDINATE_ARRAY(4,4)));
    ALTER SESSION SET QUERY_REWRITE_INTEGRITY=TRUSTED;
    ALTER SESSION SET QUERY_REWRITE_ENA[i]Long postings are being truncated to ~1 kB at this time.

    hi there,
    For a better audience for this question, I'd look at the database forum.
    guys on that will be a lot more familiar with FBIs
    thanks
    Barry

Maybe you are looking for