Create Index to use Like Clause

Hi All,
I want one of my query to use a index which runs with a LIKE Clause. I have not done that before but i have heard and seen through forums that its possible to create indexes for a column with Like Clause using function based index.
Function
Request the forum users to achieve my objective. Let me list down what i have done.
Function
CREATE OR REPLACE FUNCTION RND_LIKE(P_NO IN VARCHAR2)
RETURN VARCHAR2 IS
RESULT VARCHAR2(240);
BEGIN
RETURN P_NO||'%';
END RND_LIKE;
SELECT ENAME FROM EMP WHERE ENAME LIKE RND_LIKE('A')
Here based on this function i want to create a function based index and force the same to my query. Request the forum users to help me out in this.
Thanks
Edited by: ramarun on Dec 18, 2009 9:26 PM

In the case you had there , Oracle would use an index on ename in a query if you were to type A% in the ename item on a Form. You wouldn't need a function index for that.
Here's the link to the documentation to create a function based index http://download-uk.oracle.com/docs/cd/B28359_01/server.111/b28310/indexes003.htm#i1006674

Similar Messages

Using Like Clause in Prepared Statement

Hi,
I want to use LIKE clause in prepared statement. This is not returning any record.
This is the query. Please help me in this.
SELECT EMPLYR_GRP,EMPLYR_GRP_NAME FROM EMPLOYER_GROUP WHERE EMPLYR_GRP_NAME LIKE ? AND EMPLYR_GRP = ?
This is giving Oracle SQL Error.
SELECT EMPLYR_GRP,EMPLYR_GRP_NAME FROM EMPLOYER_GROUP WHERE EMPLYR_GRP_NAME LIKE %?% AND EMPLYR_GRP = ?

The first variant should work just fine as long as you use stmt.setString(1, '%' + pattern + '%') to set the parameter. The second query is just plain wrong.
Alin.

Query not using index when using 'or' clause

I have a problem with something I can't understand about indexes in Oracle 11g.
We can create test data with:
create table test2(field1 varchar2(100),field2 varchar2(100),field3 number,field4 varchar2(100));
create index test2_idx1 on test2(upper(field1));
create index test2_idx1b on test2(field1);
create index test2_idx2 on test2(field3);
DECLARE
j NUMBER :=1;
BEGIN
FOR i IN 1..500000
LOOP
INSERT
INTO test2
(field1,field2, field3, field4)
VALUES
('field1='||i,'a', j, 'i' );
IF (i mod 1000)=0 THEN
j := j+1;
END IF;
END LOOP;
COMMIT;
END;
EXEC DBMS_STATS.GATHER_TABLE_STATS ('system', 'test2');
Then I make some explain plans which result I can't understand
Query 1:
SELECT * FROM test2 WHERE field3=1;
Explain plan:
Explain plan for query 01
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1003 | 28084 | 10 (0)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| TEST2 | 1003 | 28084 | 10 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | TEST2_IDX2 | 1003 | | 5 (0)| 00:00:01 |
Everything OK here. Index is used.
Query 2:
SELECT * FROM test2 WHERE upper(field1)='FIELD1=1';
Explain plan
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 28 | 4 (0)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| TEST2 | 1 | 28 | 4 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | TEST2_IDX1 | 1 | | 3 (0)| 00:00:01 |
Everything OK again. Index is used.
Query 3:
SELECT /*+ USE_CONCAT */ * FROM test2 WHERE field1='FIELD1=1' OR field3=1;
Explain plan
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1004 | 28112 | 14 (0)| 00:00:01 |
| 1 | CONCATENATION | | | | | |
| 2 | TABLE ACCESS BY INDEX ROWID| TEST2 | 1 | 28 | 4 (0)| 00:00:01 |
|* 3 | INDEX RANGE SCAN | TEST2_IDX1B | 1 | | 3 (0)| 00:00:01 |
|* 4 | TABLE ACCESS BY INDEX ROWID| TEST2 | 1003 | 28084 | 10 (0)| 00:00:01 |
|* 5 | INDEX RANGE SCAN | TEST2_IDX2 | 1003 | | 5 (0)| 00:00:01 |
Indenxes are used in concatenation. No problem again.
Query 4:
SELECT /*+ USE_CONCAT */ * FROM test2 WHERE upper(field1)='FIELD1=1' OR field3=1;
Explain plan
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1004 | 28112 | 641 (4)| 00:00:08 |
| 1 | CONCATENATION | | | | | |
|* 2 | TABLE ACCESS FULL | TEST2 | 1 | 28 | 631 (4)| 00:00:08 |
|* 3 | TABLE ACCESS BY INDEX ROWID| TEST2 | 1003 | 28084 | 10 (0)| 00:00:01 |
|* 4 | INDEX RANGE SCAN | TEST2_IDX2 | 1003 | | 5 (0)| 00:00:01 |
Here my problem arises. Why is test2_idx1 not being used? Is it because it is a function index? Is there any workaround in this cases?
Thanks a lot in advance.

Interesting. A "workaround" which I thought first was:
SELECT /*+ USE_CONCAT */ * FROM test2 WHERE upper(field1)='FIELD1=1'
UNION ALL
SELECT /*+ USE_CONCAT */ * FROM test2 WHERE field3=1;
| Id | Operation                    | Name       | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT             |            | 1001 | 28042 |    15 (74)| 00:00:01 |
|   1 | UNION-ALL                   |            |       |       |            |          |
|   2 |   TABLE ACCESS BY INDEX ROWID| TEST2      |     1 |    42 |     4   (0)| 00:00:01 |
|* 3 |    INDEX RANGE SCAN          | TEST2_IDX1 |     1 |       |     3   (0)| 00:00:01 |
|   4 |   TABLE ACCESS BY INDEX ROWID| TEST2      | 1000 | 28000 |    11   (0)| 00:00:01 |
|* 5 |    INDEX RANGE SCAN          | TEST2_IDX2 | 1000 |       |     5   (0)| 00:00:01 |
-------------------------------------------------------------------------------------------   But I do not like using UNION for such tricks. So I thought, what would ORACLE do without hint?
SELECT * FROM test2 WHERE upper(field1)='FIELD1=1' or field3=1;
| Id | Operation                        | Name       | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT                 |            | 1001 | 42042 |   176   (0)| 00:00:03 |
|   1 | TABLE ACCESS BY INDEX ROWID     | TEST2      | 1001 | 42042 |   176   (0)| 00:00:03 |
|   2 |   BITMAP CONVERSION TO ROWIDS    |            |       |       |            |          |
|   3 |    BITMAP OR                     |            |       |       |            |          |
|   4 |     BITMAP CONVERSION FROM ROWIDS|            |       |       |            |          |
|* 5 |      INDEX RANGE SCAN            | TEST2_IDX2 |       |       |     5   (0)| 00:00:01 |
|   6 |     BITMAP CONVERSION FROM ROWIDS|            |       |       |            |          |
|* 7 |      INDEX RANGE SCAN            | TEST2_IDX1 |       |       |     3   (0)| 00:00:01 |
----------------------------------------------------------------------------------------------- Thist looks perfect to me. (Please ignore the "higher" cost on the second plan. On your real data, it should be faster. Is it?)

Create index without using temp tablespace

Hello,
i have a great table with over 2.000.000.000 rows. Therefor i want to create an index on column1:
CREATE INDEX "SCHEMA"."INDEX_TABLE1" ON "SCHEMA"."TABLE1" ("STR1")
PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS NOCOMPRESS LOGGING
STORAGE( INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)
TABLESPACE "USERS" ;
If i execute this my temp tablespace will be used and if its full (max 20gb) the creation will be aborted.
Where is my fault to create the index?
With best

bladepit wrote:
The table description:
CREATE TABLE "SCHEMA"."TABLE1"
(     "STR1" VARCHAR2(20 BYTE),
     "STR2" VARCHAR2(20 BYTE),
     "VAL" NUMBER
) SEGMENT CREATION IMMEDIATE
PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)
TABLESPACE "USERS" ;
And i want to get the values like this:
select str1,str2,val from SCHEMA.TABLE1 where str1 = 'TEST1' or str2 = 'TEST1'
If this is the complete definition of the table, and if (str1, str2) are unique, and this really is the only way you use the table, then it looks as if your STRATEGIC move would be to rebuild the table as a hash partitioned IOT with something like 128 partitions. Since you probably can't do that in the short-term you could create a hash partitioned index on the table (assuming you have paid the partitioning licence) with enough partitions that you can create each one separately. Something like:
SQL> create index t1_i1 on t1(n1, n2, n3) unusable global partition by hash (n1, n2) partitions 4;
Index created.
SQL> select index_name, partition_name from user_ind_partitions;
INDEX_NAME           PARTITION_NAME
T1_I1                SYS_P8713
T1_I1                SYS_P8712
T1_I1                SYS_P8711
T1_I1                SYS_P8710
4 rows selected.
SQL> alter index t1_i1 rebuild partition sys_p8713 online;
Index altered.
-- repeat for each partition in turnRegards
Jonathan Lewis

Like clause and index access

Hi All,
I've gone through below link to how to use index while using LIKE operator in SQL.
[http://laurentschneider.com/wordpress/2009/07/how-to-tune-where-name-likebc.html]
I've tried the same approach in Employees Table,but index not being used.
--there is a normal Index on Job_id named by EMP_JOB_IX.
SQL10.2> select /*+ INDEX(employees EMP_JOB_IX)*/ e.job_id,e.first_name
from employees e where e.job_id like '%ABC%';
---Explain plan
SELECT STATEMENT, GOAL = ALL_ROWS               3     5     80
TABLE ACCESS FULL     HR     EMPLOYEES     3     5     80
Pls let me know why it is full table scan.(using version 10.2)
Thanks,

SQL>EXEC dbms_stats.gather_table_stats(user,'EMPLOYEES',cascade=>true);
SQL>select /*+ INDEX(employees ,EMP_JOB_IX)*/ e.job_id,e.first_name
from employees e where e.job_id like '%ABC%' ;
SELECT STATEMENT, GOAL = ALL_ROWS               3     5     80
TABLE ACCESS FULL     HR     EMPLOYEES     3     5     80
Still showing the Table full scan.

Tunning query with LIKE clause

Hi, is there any chance to improve execution plan for SQL query which is using LIKE clause?
Query:
SELECT * FROM [TABLE_NAME] WHERE ADDRESS LIKE :1 ESCAPE '\';
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 112K| 18M| 11361 (1)| 00:02:17 |
|* 1 | TABLE ACCESS FULL| [TABLE_NAME] | 112K| 18M| 11361 (1)| 00:02:17 |
Execution plan is far from ideal. Table has several millions of records.
This query is used by application to seach using patterns...
Any ideas?
Thx in advance!

This example isn't entirely realistic. Your table T has only 1 column which is also indexed. Apparently, for small enough tables of one column it will search the entire index for the wildcard value. But if I add a second column, or base the single column version on a larger table, the optimizer uses a full table scan:
SQL> drop   table t;
Table dropped.
SQL> CREATE TABLE t AS SELECT DBMS_RANDOM.STRING('a',100) a
2                          ,DBMS_RANDOM.STRING('a',100) b
3                    FROM user_objects;
Table created.
SQL>
SQL> CREATE INDEX t_idx ON t (a) COMPUTE STATISTICS;
Index created.
SQL>
SQL> SET autotrace traceonly explain
SQL>
SQL> SELECT *
2 FROM t
3 WHERE a LIKE '%acb%';
Execution Plan
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=2 Card=1 Bytes=100)
   1    0   TABLE ACCESS (FULL) OF 'T' (Cost=2 Card=1 Bytes=100)
SQL> drop   table t;
Table dropped.
SQL> CREATE TABLE t AS SELECT DBMS_RANDOM.STRING('a',100) a
2                       --   ,DBMS_RANDOM.STRING('a',100) b
3                    FROM all_objects;
Table created.
SQL>
SQL> CREATE INDEX t_idx ON t (a) COMPUTE STATISTICS;
Index created.
SQL>
SQL> SET autotrace traceonly explain
SQL>
SQL> SELECT *
2 FROM t
3 WHERE a LIKE '%acb%';
Execution Plan
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=20 Card=399 Bytes=39900)
   1    0   TABLE ACCESS (FULL) OF 'T' (Cost=20 Card=399 Bytes=39900)

Difference between Create Index without and with Parallel Clause

Hi all.
I want to know the difference between Create Index with Parallel clause and Create Index without Parallel clause.
Any documentation.
Thanks,
Hassan

Sure?
dimitri@VDB> create table t parallel 3 as select * from all_objects;
Table created.
dimitri@VDB> set autotrace traceonly
dimitri@VDB> select * from t;
40934 rows selected.
Execution Plan
Plan hash value: 3050126167
| Id | Operation            | Name     | Rows | Bytes | Cost (%CPU)| Time     |    TQ |IN-OUT| PQ Distrib |
|   0 | SELECT STATEMENT     |          | 40601 | 5075K|    50   (0)| 00:00:01 |        |      |            |
|   1 | PX COORDINATOR      |          |       |       |            |          |        |      |            |
|   2 |   PX SEND QC (RANDOM)| :TQ10000 | 40601 | 5075K|    50   (0)| 00:00:01 | Q1,00 | P->S | QC (RAND) |
|   3 |    PX BLOCK ITERATOR |          | 40601 | 5075K|    50   (0)| 00:00:01 | Q1,00 | PCWC |            |
|   4 |     TABLE ACCESS FULL| T        | 40601 | 5075K|    50   (0)| 00:00:01 | Q1,00 | PCWP |            |
--------------------------------------------------------------------------------------------------------------Looks like PQ to me.
alter table t noparallel;
Table altered.
dimitri@VDB> select * from t;
40934 rows selected.
Execution Plan
Plan hash value: 1601196873
| Id | Operation         | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |      | 40601 | 5075K|   135   (1)| 00:00:02 |
|   1 | TABLE ACCESS FULL| T    | 40601 | 5075K|   135   (1)| 00:00:02 |
--------------------------------------------------------------------------Same if we use an Index:
dimitri@VDB> create index t_idx on t(object_name) parallel 3;
Index created.
dimitri@VDB> select object_name from t;
40934 rows selected.
Execution Plan
Plan hash value: 4278805225
| Id | Operation               | Name     | Rows | Bytes | Cost (%CPU)| Time     |    TQ |IN-OUT| PQ Distrib |
|   0 | SELECT STATEMENT        |          | 40601 |   674K|    50   (0)| 00:00:01 |        |      |            |
|   1 | PX COORDINATOR         |          |       |       |            |          |        |      |            |
|   2 |   PX SEND QC (RANDOM)   | :TQ10000 | 40601 |   674K|    50   (0)| 00:00:01 | Q1,00 | P->S | QC (RAND) |
|   3 |    PX BLOCK ITERATOR    |          | 40601 |   674K|    50   (0)| 00:00:01 | Q1,00 | PCWC |            |
|   4 |     INDEX FAST FULL SCAN| T_IDX    | 40601 |   674K|    50   (0)| 00:00:01 | Q1,00 | PCWP |            |
-----------------------------------------------------------------------------------------------------------------Everything done on a single CPU (also only one core in the CPU) AMD Box.
Dim

Create index in SQL using a variable

Hello, need to programatically create an index in a SQL script using a variable for the tablespace name.
VARIABLE ts_name VARCHAR2(50)
BEGIN
SELECT tablespace_name INTO :ts_name
from user_indexes
where TABLE_NAME = 'PREFERRED_CUSTOMER';
end;
How would I now issue a create index statement like the one below but substituting the tablespace name with the ts_name variable from above?
CREATE UNIQUE INDEX XAK2PREFERRED_CUSTOMER ON FOCUS.PREFERRED_CUSTOMER (PREFERRED_CUST_NUM) TABLESPACE FOCUSPCIX;
Thank you,
David

I am upgrading a customer database to unicode and I need to convert certain columns to NCHAR base. I am using an alter table command to do this. To make it fasted I need to drop indexes and recreate them at the end. Not all of our customers have used the default tablespace naming conventions so rather than having to change the script each time I was hoping to make the tablespace name portion of the create index DDL dynamic. Thank you,
David

Why CBO don't use function-base index when I use like and bind variable

Hello
I have litle problem with function-base index and like with bind variable.
When I use like with bind variable, the CBO don't use my function-base index.
For example when I create table and index:
ALTER SESSION SET NLS_SORT='BINARY_CI';
ALTER SESSION SET NLS_COMP='LINGUISTIC';
alter session set nls_language='ENGLISH';
-- DROP TABLE TEST1;
CREATE TABLE TEST1 (K1 VARCHAR2(32));
create index test1_idx on test1(nlssort(K1,'nls_sort=BINARY_CI'));
INSERT INTO TEST1
SELECT OBJECT_NAME FROM ALL_OBJECTS;
COMMIT;
When I run:
ALTER SESSION SET NLS_SORT='BINARY_CI';
ALTER SESSION SET NLS_COMP='LINGUISTIC';
SELECT * FROM TEST1 WHERE K1 = 'abcd';
or
SELECT * FROM TEST1 WHERE K1 LIKE 'abcd%';
CBO use index.
PLAN_TABLE_OUTPUT
SQL_ID 4vrmp7cshbvqy, child number 1
SELECT * FROM TEST1 WHERE K1 LIKE 'abcd%'
Plan hash value: 1885706448
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | | | 1 (100)| |
| 1 | TABLE ACCESS BY INDEX ROWID| TEST1 | 2 | 98 | 1 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | TEST1_IDX | 2 | | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
2 - access("TEST1"."SYS_NC00002$">=HEXTORAW('6162636400') AND
"TEST1"."SYS_NC00002$"<HEXTORAW('6162636500') )
but when I run
SELECT * FROM TEST1 WHERE K1 LIKE :1;
CBO don't use index
PLAN_TABLE_OUTPUT
SQL_ID 9t461s1669gru, child number 0
SELECT * FROM TEST1 WHERE K1 LIKE :1
Plan hash value: 4122059633
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | | | 89 (100)| |
|* 1 | TABLE ACCESS FULL| TEST1 | 2 | 48 | 89 (3)| 00:00:02 |
Predicate Information (identified by operation id):
1 - filter("K1" LIKE :1)
What should I change to force CBO to use index.
I don't wont use index hint in query.
My oracle version:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
PL/SQL Release 11.2.0.1.0 - Production
CORE 11.2.0.1.0 Production
TNS for 64-bit Windows: Version 11.2.0.1.0 - Production
NLSRTL Version 11.2.0.1.0 - Production

OK. But why if I create normal index (create index test1_idx on test1(K1)) and return to default nls settings this same query use index.
PLAN_TABLE_OUTPUT
SQL_ID 9t461s1669gru, child number 0
SELECT * FROM TEST1 WHERE K1 LIKE :1
Plan hash value: 598212486
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | | | 1 (100)| |
|* 1 | INDEX RANGE SCAN| TEST1_IDX | 1 | 18 | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
1 - access("K1" LIKE :1)
filter("K1" LIKE :1)
Note
- dynamic sampling used for this statement (level=2)
when index is function-base (create index test1_idx on test1(nlssort(K1,'nls_sort=BINARY_CI')))
PLAN_TABLE_OUTPUT
SQL_ID 9t461s1669gru, child number 1
SELECT * FROM TEST1 WHERE K1 LIKE :1
Plan hash value: 4122059633
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | | | 89 (100)| |
|* 1 | TABLE ACCESS FULL| TEST1 | 3 | 54 | 89 (3)| 00:00:02 |
Predicate Information (identified by operation id):
1 - filter("K1" LIKE :1)
Note
- dynamic sampling used for this statement (level=2)
when I create index with upper function "index test1_idx on test1(upper(K1))" the query use index
SELECT * FROM TEST1 WHERE upper(K1) LIKE :1
Plan hash value: 1885706448
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | | | 1 (100)| |
| 1 | TABLE ACCESS BY INDEX ROWID| TEST1 | 4481 | 157K| 1 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | TEST1_IDX | 806 | | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
2 - access("TEST1"."SYS_NC00002$" LIKE :1)
filter("TEST1"."SYS_NC00002$" LIKE :1)
Note
- dynamic sampling used for this statement (level=2)

Newly created index not being used

Hello friends,
I am observing that a newly created index on a z table with mandt & a new field is not being used. I have already rebuild index & updated stats for table.
when we query on this table with where clause having same 2 fields mandt & other.. we expected this index to be used. This table is very large. What more i can do now ?
In trace/SQL session, we can see it is going full table scan.. and takes very long time.
this new field contain no data as of now for all existing rows. Is this the reason ? or sometihng else ?
SQL Statement
SELECT
FROM
"ABSA"
WHERE
"MANDT" = :A0 AND "ZABCD" = :A1
Execution Plan
Explain from v$sql_plan not possible -> Explain from PLAN_TABLE is displayed !
No values in v$sql_plan for Address: 0000000166710240 Hash_value: 3891403872 Child_number: 0 Sql_id:
SELECT STATEMENT ( Estimated Costs = 905.739 , Estimated #Rows = 110.190.667 )
        1 TABLE ACCESS FULL ZABSA
          ( Estim. Costs = 905.739 , Estim. #Rows = 110.190.667 )
          Estim. CPU-Costs = 152.614.535.266 Estim. IO-Costs = 899.784
          Filter Predicates
NONUNIQUE Index   ZABSA~Z01
Column Name                     #Distinct
MANDT                                          1
ZABCD                                         1
thanks & regards
ashish
Edited by: ashish vikas on Mar 3, 2012 9:05 PM

ashish vikas wrote:
> Execution Plan
> Explain from v$sql_plan not possible -> Explain from PLAN_TABLE is displayed !
> No values in v$sql_plan for Address: 0000000166710240 Hash_value: 3891403872 Child_number: 0 Sql_id:
>
> SELECT STATEMENT ( Estimated Costs = 905.739 , Estimated #Rows = 110.190.667 )
>
>         1 TABLE ACCESS FULL ZABSA
>           ( Estim. Costs = 905.739 , Estim. #Rows = 110.190.667 )
>           Estim. CPU-Costs = 152.614.535.266 Estim. IO-Costs = 899.784
>           Filter Predicates
>
> NONUNIQUE Index   ZABSA~Z01
> Column Name                     #Distinct
> MANDT                                          1
> ZABCD                                         1
Hi,
with this WHERE clause, both columns just one distinct value, the Full Table Scan is indded the best approach, beside
the point you only need a check to evaluate a value is NOT in the result.
In this case you should HINT the statement to the new index, because the DB will always assume that this index is non-selective.
Volker

What resources are used for "create index" ?

In the context of creating an index on a heavily loaded table....
What Oracle resources are consumed>? Any caches or buffers? Sort files? Temp Tables?
(trying to speed up an index create)

Like any other read/write database activities, CREATE INDEX uses blocks in the buffer cache. If your table is large, I would recommend increase your buffer cache.
No temporary tables is used as far as I know. There are no sort files in Oracle. Temporary tablespace may be used because sorting is generally needed when creating an index, but I am not sure about that.
When creating a index, Oracle creates a temporary segment in your permanent tablespace: if the CREATE INDEX fails, the temporary segment is removed. If the CREATE INDEX succeeds, the temporary segment is made permanent.
Message was edited by:
Pierre Forstmann

Why do we create indexes for DSOs and Cubes.What is the use of it?

Hi All,
Can you please tell me why are indexes created for DSOs and Cubes.
What is the use with the creation of indexes.
Thanks,
Sravani

HI ,
An index is a copy of a database table that is reduced to certain fields. This copy is always in sorted form. Sorting provides faster access to the data records of the table, for example, when using a binary search. A table has a primary index and a secondary index. The primary index consists of the key fields of the table and is automatically created in the database along with the table. You can also create further indexes on a table in the Java Dictionary. These are called secondary indexes. This is necessary if the table is frequently accessed in a way that does not take advantage of the primary index. Different indexes for the same table are distinguished from one another by a separate index name. The index name must be unique. Whether or not an index is used to access a particular table, is decided by the database system optimizer. This means that an index might improve performance only with certain database systems. You specify if the index should be used on certain database systems in the index definition. Indexes for a table are created when the table is created (provided that the table is not excluded for the database system in the index definition). If the index fields represent the primary keys of the table, that is, if they already uniquely identify each record of the table, the index is referred to as an unique index.
they are created on DSO and cube for the performance purpose ..and reports created on them wil be also more efficent ..
Regards,
shikha

WHEN TO USE LOGGER IN CREATE INDEX?

HI ALL,
WHEN TO USE LOGGER IN CREATE INDEX STATEMENT? AND WHEN TO USE NOLOGGING?
HOW IS INDEX PHYSICALLY STORED IN DATABASE?
THANKS IN ADVANCE.
SANDESH

NOLOGGING means that information is not written into the redo logs (relatively faster than LOGGING). However, this also means that if you need to recover your database, the index cannot be recovered (since the info cannot be found in the redo logs).
Use NOLOGGING if you need the speed (big indexes) and/or you don't care about being able to recover the index (i.e. if it is acceptable if you recreate it manually after possible database recovery). Alternatively, create the index with NOLOGGING, alter the index to LOGGING and backup the database. Only after the successfull backup will the index be recoverable (with that backup, not an older one).
Typically you should use LOGGING rather than NOLOGGING because the overhead of creating the backup/recovery and insecurity on being able to recover (and pressure that goes along with it) is to great. This option will be handy only in rare cases (e.g. when creating staging area tables/indexes in a datawarehouse. They don't need recovery and will therefore speed up when using NOLOGGING).
Hope this helps,
Lennert

What app would I use to create an online report like this?

What Adobe CC app would I use to create a web based report like this?
http://sowc2015.unicef.org
Could it be done with Muse or does it need something like Dreamweaver and bespoke coding?

HI,
Yes, you can create such site using Adobe Muse. You will need anchors points to scroll down. You can take a look this article
http://www.lynda.com/Muse-tutorials/Understanding-anchor-links/161871/179008-4.html
Do let me know if you have any question.

XSQL Using bind params with sql LIKE clause

I am unable to use a bind-param with the LIKE clause in a SELECT statement.
eg call .../temp.xsql?name=N
XSQL query is this:
<xsql:query max-rows="-1" bind-params="name">
SELECT last_name
FROM emp
WHERE last_name LIKE '?%'
</xsql:query>
I have tried a few combinations so far with no success eg:
WHERE last_name LIKE '{@name}%'
WHERE last_name LIKE ?||%
Any ideas?

I highly recommend using XSQL's real bind variable feature wherever you can. You can read about it in the XSQL Online Documentation (Search for the "Using Bind Variables" section).
Using this feature is more performant and more secure than using textual substitution variables.
Here's what your page looks like using textual substitution:
<page connection="UTD4" xmlns:xsql="urn:oracle-xsql">
<xsql:query null-indicator="yes" >
SELECT * FROM TC_HL7_SEG WHERE SEGMENT_CODE LIKE '{@code}%'
</xsql:query>
</page> .
And here's what it would look like using real bind variables:
<page connection="UTD4" xmlns:xsql="urn:oracle-xsql">
<xsql:query null-indicator="yes" bind-params="code">
SELECT * FROM TC_HL7_SEG WHERE SEGMENT_CODE LIKE ?||'%'
</xsql:query>
</page> .
Using real bind variables allows the database to avoid reparsing the SQL statement everytime, which improves performance.
Steve Muench
JDeveloper/BC4J Development Team
Author, Building Oracle XML Applications

Create Index to use Like Clause

Similar Messages

Maybe you are looking for