Auto Stats Collection on function based indexes

In 10g does AUTO Stats Collection job in the default weeknight / weekend window collect stats on "function based indexes".
Thank You
Message was edited by:
user449511
I got the reply in another similar post posted by me some time earlier.
Thank You
Message was edited by:
user449511

SELECT job_name, comments
FROM dba_scheduler_jobs;Then refine your search using the columns in the view.

Similar Messages

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 index with OR in the wher-clause

We have some problems with functin-based indexes and
the or-condition in a where-clause.
--We use Oracle 8i (8.1.7)
create table TPERSON(ID number(10),NAME varchar2(20),...);
create index I_NORMAL_TPERSON_NAME on TPERSON(NAME);
create index I_FUNCTION_TPERSON_NAME on TPERSON(UPPER(NAME));
The following two statements run very fast on a large table
and the execution-plan asure the usage of the indexes
(-while the session is appropriate configured and the table is analyzed):
1)     select count(ID) FROM TPERSON where upper(NAME) like 'MIL%';
2)     select count(ID) from TPERSON where NAME like 'Mil%' or (3=5);
In particular we see that a normal index is used while the where-clause contains
an OR-CONDITION.
But if we try the similarly select-statement
3)     select count(ID) FROM TPERSON where upper(NAME) like 'MIL%' or (3=5);
the CBO will not use the function-index I_FUNCTION_TPERSON_NAME and we have a full table scan in the execution-plan.
(This behavior we only expect with views but not with indexes.)
We ask for an advice like a hint, which enable the CBO-usage
of function-based indexes in connection with OR.
This problem seems to be artificial because it contains this dummy logic:
     or (3=5).
This steams from an prepared statement, where this kind of boolean
flag reduce the amount of different select-statements needed for
covering the hole business-logic, while using bind-variables for the
concrete query-parameters.
A more realistic (still boild down) version of our select-statement is:
select * FROM TPERSON
where (upper(NAME) like 'MIL%' or (NAME is null))
and (upper(FIRSTNAME) like 'MICH% or (FIRSTNAME is null))
and ...;
thank you for time..
email: [email protected]

In the realistic statement you write :
select * FROM TPERSON
where (upper(NAME) like 'MIL%' or (NAME is null))
and (upper(FIRSTNAME) like 'MICH% or (FIRSTNAME is null))
and ...;
as far as i know, NULL values are not indexed, "or (NAME is NULL)" have to generate a full table scan.
HTH
We have some problems with functin-based indexes and
the or-condition in a where-clause.
--We use Oracle 8i (8.1.7)
create table TPERSON(ID number(10),NAME varchar2(20),...);
create index I_NORMAL_TPERSON_NAME on TPERSON(NAME);
create index I_FUNCTION_TPERSON_NAME on TPERSON(UPPER(NAME));
The following two statements run very fast on a large table
and the execution-plan asure the usage of the indexes
(-while the session is appropriate configured and the table is analyzed):
1)     select count(ID) FROM TPERSON where upper(NAME) like 'MIL%';
2)     select count(ID) from TPERSON where NAME like 'Mil%' or (3=5);
In particular we see that a normal index is used while the where-clause contains
an OR-CONDITION.
But if we try the similarly select-statement
3)     select count(ID) FROM TPERSON where upper(NAME) like 'MIL%' or (3=5);
the CBO will not use the function-index I_FUNCTION_TPERSON_NAME and we have a full table scan in the execution-plan.
(This behavior we only expect with views but not with indexes.)
We ask for an advice like a hint, which enable the CBO-usage
of function-based indexes in connection with OR.
This problem seems to be artificial because it contains this dummy logic:
     or (3=5).
This steams from an prepared statement, where this kind of boolean
flag reduce the amount of different select-statements needed for
covering the hole business-logic, while using bind-variables for the
concrete query-parameters.
A more realistic (still boild down) version of our select-statement is:
select * FROM TPERSON
where (upper(NAME) like 'MIL%' or (NAME is null))
and (upper(FIRSTNAME) like 'MICH% or (FIRSTNAME is null))
and ...;
thank you for time..
email: [email protected]

Creation of function based index using escape

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

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

Function-Based Indexes for 8.1.6 SE and 9iAS

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

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

FUNCTION-BASED INDEX ( ORACLE 8I NEW FEATURE )

제품 : ORACLE SERVER
작성날짜 : 2004-08-16
FUNCTION-BASED INDEX ( ORACLE 8I NEW FEATURE )
==============================================
SCOPE
10g Standard Edition(10.1.0) 이상 부터 Function-based Index 기능이 지원된다.
Explanation
1. 개요
     Function-based index는, 함수(function)이나 수식(expression)으로 계산
된 결과에 대해 인덱스를 생성하여 사용할 수 있는 기능을 제공한다.
     질의 수행 시 해당 함수나     수식을 처리하여     결과를 가져 오는 것이 아니라,
     인덱스 형태로 존재하는 미리 계산되어 있는 결과를 가지고 처리하므로
     성능 향상을 기할 수 있다.
2. 제약사항
1) aggregate function 에 대한 function-based index 생성 불가.
(예 : sum(...) )
2) LOB, REF, nested table 컬럼에 대한 function-based index 생성 불가.
3. 주요 특징
     1) cost-based optimizer에 의해 사용됨.
     2) B*Tree / bitmap index로 생성 가능.
     3) 산술식 (arithmetic expression), PLSQL function, SQL built-in
function 등에 적용 가능.
     4) 함수나 수식으로 처리된 결과에 대한 range scan 가능
     5) NLS SORT 지원
     6) SELECT/DELETE를 할 때마다 함수나 수식의 결과를 계산하는 것이 아니라
     INSERT/UPDATE 시 계산된 값을 인덱스에 저장.
     7) 질의 속도 향상
     8) object column이나 REF column에 대해서는 해당 object에 정의된
     method에 대해 function-based index 생성 가능.
4. 생성 방법
     CREATE [UNIQUE | BITMAP ] INDEX <index_name>
     ON <tablename> (<index-expression-list>)
     <index-expression-list> -> { <column_name> | <column_expression> }
     예) CREATE INDEX EMP_NAME_INDEX ON EMP (UPPER(ENAME));
     CREATE INDEX EMP_SAL_INDEX ON EMP( SAL + COMM, empno);
     * Function-based index를 생성하기 위해서는 QUERY REWRITE 권한이
     부여 되어 있어야만 한다.
     예) GRANT QUERY REWRITE TO SCOTT;
5. Function-Based Index 사용을 위한 사전 작업
     1) Function-based index는 cost based optimizer에서만 사용 가능하므로,
     테이블에 대해 미리 analyze 해 주는 것이 바람직하다.
     그리고 init 파일에서 OPTIMIZER_MODE 를 FIRST_ROWS 나 ALL_ROWS 등으
로 지정하거나 HINT 등을 사용하여 cost based optimizer가 사용되도록
한다.
     2) init 파일에서 COMPATIBLE 파라미터 값을 8.1 이상으로 설정되어 있어야
한다.
     ( 예 : COMPATIBLE = 8.1.6 )
     3) session/instance level 에서 QUERY_REWRITE_ENABLED 값이 TRUE 지정
되어 있어야 한다.
     ( 예 : ALTER SESSION SET QUERY_REWRITE_ENABLED = TRUE; )
6. 예제
     1) init 파라미터에서 다음과 같이 지정
     compatible = 8.1.6 (반드시 8.1이상이어야 한다)
     query_rewrite_enabled = true
     query_rewrite_integrity = trusted
     2) SCOTT 유저에서 function_based_index 생성
     create index idx_emp_lower_ename
     on emp
     ( lower(ename) ) ;
     3) EMP table analyze
     analyze table emp compute statistics ;
     4) PLAN_TABLE 생성
     @ ?/rdbms/admin/utlxplan.sql
     5) Cost based optimizer 선택
     alter session set optimizer_mode = FIRST_ROWS ;
     6) Query 실행
     explain plan set statement_id='qry1' FOR
     select empno, ename
     from emp
     where lower(ename) = 'ford' ;
     7) PLAN 분석
     SELECT LPAD(' ',2*level-2)||operation||' '||options||' '||object_name query_plan
     FROM plan_table
     WHERE statement_id='qry1'
     CONNECT BY prior id = parent_id
     START WITH id = 0 order by id ;
     -> 결과
     QUERY_PLAN
     SELECT STATEMENT
     TABLE ACCESS BY INDEX ROWID EMP
     INDEX RANGE SCAN IDX_EMP_LOWER_ENAME
7. 결론
Function-based index는 적절하게 사용될 경우 성능상의 많은 이점을 가져
온다. Oracle8i Designing and Tuning for Performance에서도 가능한 한
Function-based index를 사용하는 것을 권장하고 있으며, LOWER(), UPPER()
등의 함수를 사용하여 불가피하게 FULL TABLE SCAN을 하는 경우에 대해서도
효과적으로 처리해 줄 수 있는 방안이라 할 수 있다.
Reference Documents
-------------------

Partha:
From the Oracle8i Administrators Guide:
"Table owners should have EXECUTE privileges on the functions used in function-based indexes.
For the creation of a function-based index in your own schema, you must be
granted the CREATE INDEX and QUERY REWRITE system privileges. To create
the index in another schema or on another schemas tables, you must have the
CREATE ANY INDEX and GLOBAL QUERY REWRITE privileges."
Hope this helps.
Peter

Query not considering function based index in oracle 11g

I have a query which used Function Based Index when run in oracle 9i but when I run the same query
without any changes, it does not consider index. Below is the query:
SELECT distinct patient_role.domain_key, patient_role.patient_role_key,
patient_role.emergency_contact_name,
patient_role.emergency_contact_phone, patient_role.emergency_contact_note,
patient_role.emergency_contact_relation_id,
patient_role.financial_class_desc_id, no_known_allergies, patient_role.CREATED_BY,
patient_role.CREATED_TIMESTAMP,
patient_role.CREATED_TIMESTAMP_TZ, patient_role.UPDATED_BY, patient_role.UPDATED_TIMESTAMP,
patient_role.UPDATED_TIMESTAMP_TZ,
patient_role.discontinued_date
FROM encounter, patient_role
WHERE patient_role.patient_role_key = encounter.patient_role_key
AND UPPER(TRIM(leading :SYS_B_0 from encounter.account_number)) = UPPER(TRIM(leading :SYS_B_1 from
:SYS_B_2))
AND patient_role.discontinued_date IS null
AND encounter.discontinued_date IS null ;
Index definition:
CREATE INDEX "user1"."IX_TRIM_ACCOUNT_NUMBER" ON "user1."ENCOUNTER" (UPPER(TRIM(LEADING
'0' FROM "ACCOUNT_NUMBER")), "PATIENT_ROLE_KEY", "DOMAIN_KEY", "DISCONTINUED_DATE")
PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1
BUFFER_POOL DEFAULT)
TABLESPACE "user1"
Database : Oracle 11g (11.2.0.3)
O/S : Linux 64 bit (the query does not consider index even on windows os)
Any suggestions?
-Onkar
Edited by: onkar.nath on Jul 2, 2012 3:32 PM

Onkar,
I don't appreciate you posting this question in several forums at the same time.
If I would know you also posted this on Asktom, I wouldn't even have bothered.
As to your 'issue':
First of all: somehow cursor_sharing MUST have been set to FORCE. Oracle is a predictable system, not a fruitmachine.
Your statement the '0' is replaced by a bind variable anyway is simply false. If you really believe it is not false, SUBMIT a SR.
But your real issue is not Oracle: it is your 'application', which is a mess anyway. Allowing for alphanumeric numbers is a really bad idea.
Right now you are already putting workaround on workaround on workaround on workaround.
Issue is the application: it is terminal., and you either need to kill it, or to replace it.
Sybrand Bakker
Senior Oracle DBA

Function-based indexes

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

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

Function-based Index and an OR-condition in the WHERE-clause

We have some problems with functin-based indexes and
the or-condition in a where-clause.
(We use oracle 8i (8.1.7))
create table TPERSON(ID number(10),NAME varchar2(20),...);
create index I_NORMAL_TPERSON_NAME on TPERSON(NAME);
create index I_FUNCTION_TPERSON_NAME on TPERSON(UPPER(NAME));
The following two statements run very fast on a large table
and the execution-plan asure the usage of the indexes
(-while the session is appropriate configured and the table is analyzed):
1)     select count(ID) FROM TPERSON where upper(NAME) like 'MIL%';
2)     select count(ID) from TPERSON where NAME like 'Mil%' or (3=5);
In particular we see that a normal index is used while the where-clause contains
an OR-CONDITION.
But if we try the similarly select-statement
3)     select count(ID) FROM TPERSON where upper(NAME) like 'MIL%' or (3=5);
the CBO will not use the function-index.
(This behavior we only expect with views but not with indexes.)
We ask for an advice like an hint, which enable the CBO-usage
of function-based indexes in connection with OR.
This problem seems to be artificial because it contains this dummy logic:
     or (3=5).
This steams from an prepared statement, where this kind of boolean
flag reduce the amount of different select-statements needed for
covering the hole business-logic, while using bind-variables for the
concrete query-parameters.
A more realistic (still boild down) version of our prepared select-statement run in
SQL Plus:
define x_name = 'MIL%';
define x_firstname = '';
select * FROM TPERSON
where (upper(NAME) like '&x_name' or ( '&x_name' = ''))
and (upper(FIRSTNAME) like '&x_firstname' or ('&x_firstname' = ''))
and ...;
In particular we dont refernce the tablecolumn , but the QUERY-Parameter
yield the second boolean value in the or-condition.
The problem is that this condition ('&x_name' = '') dont use any index.
thanks a lot for spending your time with this problem

Try
SELECT /*+ RULE */
as your hint. I don't have the book with me, but this last weekend I read a section about your very problem. The book was a Oracle Press gold cover about Oracle 8i Performance tuning. If you e-mail me I can quote you the chapter when I get home Friday.

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.

Query Transformation in Function Based Index's Expression

Hi All,
I am having a wired issue with Function Based Indexes on Orcale 10.2.0.3 running on Solaris 5.9.
I have created two FBI on two tables using following syntax.
CREATE INDEX EQHUB.IDX_BBO_WRT_DES_FBI ON EQHUB.BBO_WARRANT_PRICING (CASE WHEN latest_version_flag = 'Y' THEN 1 ELSE NULL END);
CREATE INDEX EQHUB.IDX_BBO_DES_FBI ON EQHUB.BBO_DESCRIPTIVE_DATA (CASE WHEN latest_version_flag = 'Y' THEN 1 ELSE NULL END);
For the second command (IDX_BBO_DES_FBI), when i query DBA_IND_EXPRESSIONS view, i found that Oracle has done some kind of QUERY TRANSFORMATION (?) and converted
FBI expression to CASE "LATEST_VERSION_FLAG" WHEN 'Y' THEN 1 ELSE NULL END.At the same time,EXPRESSION on first index is not changed.
Now,my question is what has made transformation to occure only for second index.
I also found that inspite of highly SELECTIVE nature of both the indexes, only SECOND index is being used by CBO (for which trasnformation occured)
and IDX_BBO_WRT_DES_FBI is not being used(FTS is happening instead).
Query is using same expression for both the tables as
(CASE WHEN latest_version_flag = 'Y' THEN 1 ELSE NULL END)=1
INDEX_NAME                          TABLE_NAME                          COLUMN_EXPRESSION
IDX_BBO_WRT_DES_FBI                 BBO_WARRANT_PRICING                 CASE WHEN "LATEST_VERSION_FLAG"='Y' THEN 1 ELSE NULL END
IDX_BBO_DES_FBI                     BBO_DESCRIPTIVE_DATA                CASE "LATEST_VERSION_FLAG" WHEN 'Y' THEN 1 ELSE NULL ENDI read that expression should be evaluated including CASE of characters and spaces in query.Is that true?
Appreciating responses in advance.

Randolf.
It's a shame that I forgot to look into the full execution plan information to check how Oracle really handles my queries.
Look here(edited for clarity):
explain plan for
select /*+ case1 ordered use_nl(x, y) */ count(case c1
    when '1' then 1
    when '2' then 2
    when '3' then 3
    else 4
end) from
(select level from dual connect by level <= 300000) x,
(select
from t1
) y;
| Id | Operation                       | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT                |      |     1 |     2 |     5   (0)| 00:00:01 |
|   1 | SORT AGGREGATE                 |      |     1 |     2 |            |          |
|   2 |   NESTED LOOPS                  |      |     3 |     6 |     5   (0)| 00:00:01 |
|   3 |    VIEW                         |      |     1 |       |     2   (0)| 00:00:01 |
|   4 |     CONNECT BY WITHOUT FILTERING|      |       |       |            |          |
|   5 |      FAST DUAL                  |      |     1 |       |     2   (0)| 00:00:01 |
|   6 |    TABLE ACCESS FULL            | T1   |     3 |     6 |     3   (0)| 00:00:01 |
Column Projection Information (identified by operation id):
   1 - (#keys=0) COUNT(CASE WHEN "T1"."C1"='1' THEN 1 WHEN "T1"."C1"='2' THEN
       2 WHEN "T1"."C1"='3' THEN 3 ELSE 4 END )[22]
   2 - (#keys=0) "T1"."C1"[CHARACTER,1]
   4 - "DUAL".ROWID[ROWID,10], LEVEL[4]
   5 - "DUAL".ROWID[ROWID,10]
   6 - "T1"."C1"[CHARACTER,1]
32 rows selected.
explain plan for select /*+ case2 ordered use_nl(x, y) */ count(case
    when c1 = '1' then 1
    when c1 = '2' then 2
    when c1 = '3' then 3
    else 4
end) from
(select level from dual connect by level <= 300000) x,
(select
from t1
) y;
| Id | Operation                       | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT                |      |     1 |     2 |     5   (0)| 00:00:01 |
|   1 | SORT AGGREGATE                 |      |     1 |     2 |            |          |
|   2 |   NESTED LOOPS                  |      |     3 |     6 |     5   (0)| 00:00:01 |
|   3 |    VIEW                         |      |     1 |       |     2   (0)| 00:00:01 |
|   4 |     CONNECT BY WITHOUT FILTERING|      |       |       |            |          |
|   5 |      FAST DUAL                  |      |     1 |       |     2   (0)| 00:00:01 |
|   6 |    TABLE ACCESS FULL            | T1   |     3 |     6 |     3   (0)| 00:00:01 |
Column Projection Information (identified by operation id):
   1 - (#keys=0) COUNT(CASE WHEN "T1"."C1"='1' THEN 1 WHEN "T1"."C1"='2' THEN
       2 WHEN "T1"."C1"='3' THEN 3 ELSE 4 END )[22]
   2 - (#keys=0) "T1"."C1"[CHARACTER,1]
   4 - "DUAL".ROWID[ROWID,10], LEVEL[4]
   5 - "DUAL".ROWID[ROWID,10]
   6 - "T1"."C1"[CHARACTER,1]As you exactly mentioned, I was executing different SQL but actually same queries!
Thanks for pointing my flaws.
PS) OP, forgive me for bothering you with off-topic things. :)
================================
Dion Cho - Oracle Performance Storyteller
http://dioncho.wordpress.com (english)
http://ukja.tistory.com (korean)
================================
Edited by: Dion_Cho on Feb 10, 2009 5:45 AM
Typo

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

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

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

Segment Shrinking script erroring out due to Function based indexes, lobs,.

DB version:10gR2
Following is a script i made for freeing up(SHRINK ing and resetting HWM) the space in Tables and its indexes. Due to the existence of LOB Segments and Tables with Function based indexes, this script was erroring out. So i was wondering if there is a way to find out the segments which are eligible/not eligible for Shrinking so that i could make necessary changes to the below script.
create or replace procedure freeup_space
is
type v_segment_type is table of varchar2(30) index by binary_integer;
v_segment v_segment_type;
begin
select segment_name bulk collect into v_segment
               from user_segments
               where segment_type in ('TABLE')
                 and segment_name not like 'BIN%';
for i in v_segment.first..v_segment.last loop
execute immediate 'alter table ' || v_segment(i) ||' enable row movement';
dbms_output.put_line('Table '||v_segment(i)||'''s row movement enabled');
execute immediate 'alter table ' || v_segment(i) ||' shrink space cascade';
execute immediate 'alter table ' || v_segment(i) ||' deallocate unused';
end loop;
end;
/

You can use USER_LOBS views to look for LOB columns in the segments and ALL_INDEXES.INDEX_TYPE tells if the index is function based index or not.
Message was edited by:
Pierre Forstmann

Importing error: related to function-based indexes?

I've come across a strange error. I've got a user that has an export dump file who wants me to import the data into a new database. (Its an Oracle 10G database.)
When I use the 'imp' command, the table import completes successfully, but I end up receiving the following warnings:
IMP-00003: oracle error 942 encountered
ORA-00942: table or view does not exist
IMP-00017: following statement failed with ORACLE error 942
"CREATE INDEX "X" on "Y" (TO_CHAR("Z",'yyyymmdd')) P"
"CTFREE 10 INITRANS 2 MAXTRANS 255 STORAGE(INITIAL 3145728 FREELISTS 1 FREEL"
"IST GROUPS 1 BUFFER_POOL DEFAULT) TABLESPACE "TBSPC" LOGGING"
The table itself seems to have been imported correctly; and all data rows exist. Its just the index that isn't being imported/rebuilt. (Other indexes on the same table were imported properly.)
The only thing that I could find that seems odd is that this index uses functions (the "TO_CHAR" in the index above). All of the other indexes on the table refer to basic fields. And I can rebuild the index manually.
Is the 'imp' command able to handle function-based indexes? Is there some parameter than I need to set to allow it to import these indexes?
(I know the more efficient thing to do would be to do an import with no indexes and rebuild them later...)
Edited by: user588235 on Dec 9, 2009 5:16 PM

Function based indexes should be supported. If it is exported, then it should be able to be imported. This just seems like a weird case. Have you tried to create a different table and then create a function based index on that table then see if exp/imp work?Yes, I have tried creating new versions of the tables (both with and without function-based indexes).
During my tests, I found that I can recreate the problem if I create the table in Oracle 9 and import it into Oracle 10; the problem doesn't occur when importing/exporting between Oracle9->Oracle9 or Oracle10->Oracle10. (However, the user told me that this was an export from Oracle 10.)
One other thing: I've noticed that if, instead of importing into a user account, I import into the system account, it works with no problems. For example:
imp userid='sys/xyz as sysdba' file=mydata.dmp fromuser=use1 touser=use2 ->Results in warnings while reading indexes
imp userid='sys/xyz as sysdba' file=mydata.dmp fromuser=use1 touser=sys ->works with no warning
This makes me suspect that its a problem with the permissions that have been granted. (I've granted 'create any index' and 'query rewrite' to the user account however.)
Not to change the issue, but since this is 10g, have you tried using datapump to expdp/impdp the same information?Might be an option; problem is, I'm dealing with a legacy system that was set up to use 'imp/exp', so altering backup and restore methods will require a lot of work.

Dilemma regarding function based indexes

Hello,
I have a dilemma regarding function based indexes.
I have read Note:66277.1 on the Metalink discussing thoroughly the subject of “Concepts and Usage of Function Based Indexes”.
This doc was revised on 30-May-2006 so I was sure it referred to 9i and 10g.
This doc as well as other docs on the web claim that in order to use FBI (function based indexes) one must set the following parameters (can be done also at session level)
QUERY_REWRITE_ENABLED = TRUE
QUERY_REWRITE_INTEGRITY = TRUSTED
Also the schema that is owner of the FBI should be granted with QUERY REWRITE sys priv and statistics should be collected since FBI is usable only by CBO (cost based optimizer).
I have tested it and it works, my problem was that it worked
(1)     Without granting the QUERY REWRITE to the owning schema.
(2)     QUERY_REWRITE_ENABLED was set to false.
(3)     QUERY_REWRITE_INTEGRITY was set to enforced.
I have conducted my tests on 9.2.0.6 and found no evidence in the docs (10g) saying the above is required or not.
I found at http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:1197786003246 the following:
“Oracle9iR2 relaxed this so that the FBI on the builtin function may be used.”
so I have tested it with my own function:
create or replace function upper2( p_str in varchar2 ) return
varchar2 DETERMINISTIC
as
begin
return upper(p_str);
end;
=>
Also (yes you guessed right), without any privilege granted nor parameter setting the optimizer picked my FBI.
Can anyone refer me to a place documenting this behavior as a correct one?
Other comments?
Regards,
Tal Olier ([email protected])

Got an answer from Oracle support:
19-DEC-06 18:04:31 GMT
(Update for record id(s): 101017780,101017796)
QUESTION
========
Questions about the options required in 10g related to Function Based Indexes, and the correct
behaviors associated with them.
ANSWER
======
For 10g:
These requirements are no longer true in 10g. This has already clarified by
development in the Bug 3999326 which is available on metalink.
For 9I:
For the creation of a function-based index in your own schema, you must be
granted the QUERY REWRITE system privileges. To create the index in another
schema or on another schema's tables, you must have the CREATE ANY INDEX
and GLOBAL QUERY REWRITE privileges.
You must have the following initialization parameters defined to create a
function-based index:
QUERY_REWRITE_INTEGRITY set to TRUSTED
QUERY_REWRITE_ENABLED set to TRUE
COMPATIBLE set to 8.1.0.0.0 or a greater value
Additionally, to use a function-based index:
The table must be analyzed after the index is created.
The query must be guaranteed not to need any NULL values from the indexed
expression, since NULL values are not stored in indexes.
However, in 9.2.0.4 patchset, these prerequisites do not apply and one can
create function-based indexes without any of the above to be true. This is not
the case in 9.2.0.3, not in 8.1.7.
Reference: Oracle 9i R2 Administrators Guide
So as mentioned above that is why you didnt have any errors
Please back to us if any further information is need, and we will be pleased to
assist you further.
Thank You,
Best Regards,
Mina Anes

Auto Stats Collection on function based indexes

Similar Messages

Maybe you are looking for