Function based indexes available in Standard Edition ?

Is the function based index available in the standard or only the enterprise edition ?
Thanks
Oliver

They're available in EE only. Same with bitmap indexes too.

Similar Messages

Problem creating a function based index

Hi,
Database: 8.0.6
OS: win 2000 server
I want to create a function based index as shown below:
sql> create index new_index on A_INP_PATIENTS_ADMT(bus_unit, admit_status_flag, nvl(clinical_discharge_yn,'N'), ward_code)
When i press return its showing error,
"ORA-00907: missing right parenthesis"
Please show me how to rewrite this query to build function based index.
Best Regards,
Edited by: ateeqrahman on Jun 6, 2010 2:34 PM

Your sql is fine:
SQL> CREATE TABLE A_INP_PATIENTS_ADMT(
2                                   bus_unit number,
3                                   admit_status_flag varchar2(1),
4                                   clinical_discharge_yn varchar2(1),
5                                   ward_code varchar2(10)
6                                  )
7 /
Table created.
SQL> create index new_index on A_INP_PATIENTS_ADMT(bus_unit, admit_status_flag, nvl(clinical_discharge_yn,'N'), ward_code)
2 /
Index created.
SQL> You did not post Oracle version. Most likely, you are on some older version that does not support FBI. Otherwise, post your version and table description and create index statement execution showing all errors you are getting.
SY.

Whether Function Based indexes are included in Oracle10 Standard edition?

Hi
Could you please tell me whether Function Based indexes are included in Oracle Standard edition 10.2.
Can you provide me the link to check the features available with 10.2 standard edition.
Thanks in advance...

Hi Madrid
Function Based Indexes is a feature from Enterprise Edition.Interesting... But why do you think so? I mean, if it is the case, the documentation should mention it...
IMO the reference is the guide about licensing. But if you know that somewhere else such an information is provided, please, give us a link.
Thank you,
Chris

Feature availability: Function Based Indexes

I am currently unable to download the techspecs on Oracle's Standard Edition One to determine if function based indexs are available with this particular licensing option. Does anyone know which licensing versions this feature is available within? I suspect it is only available with the Enterprise Edition.
Thank you for your time.
Adam

Never mind, found the answer within the Oracle Database 10g Product Family (PDF), yes Function based indexes are included with all versions of 10g.

Err ORA-00439 feature not enabled: function-based indexes

How can I enable function based indexes?
Database Version is 8i Release 8.1.6.0.0.
I've done the following steps:
The init-parameter compatible is set to 8.1.0.0.0.
I've altered the session parameters
QUERY_REWRITE_INTEGRITY to TRUSTED and
QUERY_REWRITE_ENABLED to TRUE.
But it still doesn't work.
I would appreciate your help.
Martin

Function Based Index feature is not available in the Standard Edition of Oracle. This feature is available ONLY in the Enterprise and Personal Editions.
Use the V$OPTION view to see the list of installed options.
If the option is installed, you will see for "Function-based indexes":
PARAMETER VALUE
Function-based indexes TRUE
null

Fail to create a function-based index

Hello,
I'm trying to create a function-based index using the following syntax :
CREATE INDEX fb_name_idx on employees (UPPER(name));
And i've got an ORA-00439 error (function not enabled).
I'm running on Oracle 9.2 Standard edition.
Is this functionality really disabled on standard edition ?
Thanks in advance for your answer,
Guillaume Basilico

No.
According to this document http://otn.oracle.com/products/database/oracle10g/pdf/twp_general_10gdb_product_family_0104.pdf in the 3rd row on page 12 you can see that Function-Based Indexes are available on Standard Edition.
According to metalink note 69492.1 FBI are available on standard edition.
As for me, I'm too using Oracle 9.2 SE and in my version they are available.
SQL> CREATE INDEX fb_name_idx on tt(trunc(dt));
Index created
SQL> select * from v$version;
BANNER
----------------------------------------------------------Oracle9i Release 9.2.0.4.0 - Production
PL/SQL Release 9.2.0.4.0 - Production
CORE 9.2.0.3.0 Production
TNS for Linux: Version 9.2.0.4.0 - Production
NLSRTL Version 9.2.0.4.0 - Production
Please check exect version number of database and contact your DBA.

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

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

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

Hi All,
select * from v$version;
BANNER
Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - 64bit Production
PL/SQL Release 11.1.0.7.0 - Production
CORE 11.1.0.7.0 Production
TNS for Linux: Version 11.1.0.7.0 - Production
NLSRTL Version 11.1.0.7.0 - ProductionI have a 10GB partitioned table which has INVOICE_DUE_DATE column. Table is partitioned on CREATION_DATE. All records which has CREATION_DATE less than 01-jan-2010 have INVOICE_DUE_DATE set to NULL and new records (for year 2011)are updated with recent date(i.e. sysdate) by 'due_date_update' process. Some developers want indexing on INVOICE_DUE_DATE column as they have SLA critical reports running against INVOICE_DUE_DATE column. (where INVOICE_DUE_DATE > :B1) B1 could be any date in 2011.
As of now, ~85% records are having INVOICE_DUE_DATE set to NULL.
Given above scenarios,Can i use function based index to index all rows where INVOICE_DUE_DATE is any date in 2011 ?
Edited by: OraDBA02 on Jan 11, 2011 4:00 AM

OraDBA02 wrote:
Given above scenarios,Can i use function based index to index all rows where INVOICE_DUE_DATE is any date in 2011 ?I suppose you could, but you might not need to. If you had an index that just contained the INVOICE_DUE_DATE column it wouldn't index the NULL values anyways.

Function-Based Index enabling.

Hi...
I'm trying to create a function-based index along the lines of:
CREATE INDEX x_ssn4
ON table_y(SUBSTR(ssn,6,4))
UNRECOVERABLE;
...so as to be able to query the final 4 digits of social security numbers. Problem is that the above elicits an ORA-00439 "feature not enabled" message. I'm running 8.1.6 and have tried setting the Oracle parameter QUERY_REWRITE_ENABLED to 'TRUE' via an ALTER SESSION command, but to no avail.
Anyone know how to 'turn the feature on'?
Thanks, Rob

<BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:</font><HR>Originally posted by Rick Post:
I've always done it by logging on as SYS and executing a 'grant query rewrite to myuser'.
<HR></BLOCKQUOTE>
Thanks... but turns out that the privilege is not really the issue, as the ALTER SESSION command works. I figured out that the problem was the setting for COMPATIBLE. It pointed to 8.0.0 instead of 8.1.x which is what was needed to permit function-based indexing.
~Rob
null

Function-based index error due to fine-grained security

Hi, i'm working on Oracle version 9.2.0.5.
I'm trying to create a function-based index but i'm getting an error due to fine-grained security. I checked resource_view but if i'm not wrong I should have all necessary roles. I also added xdbadmin to this user to be sure.
I tried also to alter my session but it didn't worked.
Connected to Oracle9i Enterprise Edition Release 9.2.0.5.0
Connected as test_ste
SQL>
SQL> create index fbidx_schede_xml
2 on schede_progetti_xml p
3 (p.PROGETTO.extract('/Project/Elenco_unita/Unita/Responsabile/Cognome/text()').getStringVal());
create index fbidx_schede_xml
on schede_progetti_xml p
(p.PROGETTO.extract('/Project/Elenco_unita/Unita/Responsabile/Cognome/text()').getStringVal())
ORA-28133: full table access is restricted by fine-grained security
ORA-06512: at "SYS.XMLTYPE", line 0
ORA-06512: at line 1
SQL>
SQL> alter session set query_rewrite_enabled = true;
Session altered
SQL> alter session set query_rewrite_integrity = trusted;
Session altered
SQL> create index fbidx_schede_xml
2 on schede_progetti_xml p
3 (p.PROGETTO.extract('/Project/Elenco_unita/Unita/Responsabile/Cognome/text()').getStringVal());
create index fbidx_schede_xml
on schede_progetti_xml p
(p.PROGETTO.extract('/Project/Elenco_unita/Unita/Responsabile/Cognome/text()').getStringVal())
ORA-28133: full table access is restricted by fine-grained security
ORA-06512: at "SYS.XMLTYPE", line 0
ORA-06512: at line 1
SQL> select * from user_role_privs;
USERNAME                       GRANTED_ROLE                   ADMIN_OPTION DEFAULT_ROLE OS_GRANTED
TEST_STE                      CONNECT                        NO           YES          NO
TEST_STE                      CTXAPP                         NO           YES          NO
TEST_STE                      RESOURCE                       NO           YES          NO
TEST_STE                      XDBADMIN                       NO           YES          NO
SQL> This are ACL on my schema:
<ACL>
    <acl description="Private:All privileges to OWNER only and not accessible to others" xmlns="http://xmlns.oracle.com/xdb/acl.xsd" xmlns:dav="DAV:"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.oracle.com/xdb/acl.xsd                           http://xmlns.oracle.com/xdb/acl.xsd">
      <ace>
        <principal>dav:owner</principal>
        <grant>true</grant>
        <privilege>
          <all/>
        </privilege>
      </ace>
    </acl>
</ACL>I tried to create a similar function-based index on Oracle 10.2.0.3 without any problem and without touching any ACL, is an Oracle 9.2.0.5 problem?
Thanks for your attention.

I didn't really (production wise)work yet with VPD. I know a lot is based on DBMS_RLS and I guess (IF it is VPD related) it should be to hard to find in the doc's how you could check what is beyond your privileges. As a DBA I noticed that even the dba account SYSTEM isn't always allow to export the full content for the tables anymore.
There is a privilege that grants you all access that you need, despite the fact that you are not allowed to read certain rows from a table. Look it up.
In all, as I said, it looks like account is not allowed to see all data from a table. In that respect it sounds logical that you also are, in that case, not allowed to build a function based index on that data

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

Function based indexes available in Standard Edition ?

Similar Messages

Maybe you are looking for