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 processedHi,
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
Steffencheck 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 problemTry
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?
ChinniOne 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.KishoreOne 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?
ThanksIt 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,
SYHi, 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. -
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 -
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,
BradHi,
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
-
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
-
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
-
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