Impact of composite index

Hi,
I have created a composite index on two columns in a table. I would like to know whether there will be any negative impact of this. For example, will there be any problem while inserting data into table? Please advise.

Sure - adding indexes on a table will have a negative impact on inserts, deletes and potentially updates, as now you have two (or more) things to update, rather than just the table.
But you have to ask yourself, does the benefit of that index when retrieving data from the table outweigh the performance hit when you insert/update/delete? Usually the answer is yes, otherwise there would be no point in having the index in the first place.
If you're asking whether having multiple columns in your index causes problems, then no, the impact is no higher than just a single column.

Similar Messages

Single column index vs composite index?

I am just wondering that what are the differences between the following?
create table test(
person_id number
name varchar2(50),
surname varchar2(50)
create index my_indx on test(name);
create index my_indx2 on test(surname);
OR
create index my_indx3 on test(name, surname);
OR
create index my_indx4 on test(surname, name);
What are the differences among these three indexes?
When I create name and surname columns in same index (composite index) in order to index scan should I use both of them in the where clause?
My last question is, Is the order important for composite indexes?
Thanks in advance.

What are the differences among these three indexes?
You should be able to answer that yourself by just trying some examples or by answering these questions:
1. Will an index on NAME help you if you want to search on SURNAME?
2. Will an index on SURNAME help you if you want to search on NAME?
When I create name and surname columns in same index (composite index) in order to index scan should I use both of them in the where clause?
You have it backwards. You create indexes based on the predicates in the WHERE clause of your queries. How can you use 'both of them' in the where clause if the query you want to execute doesn't have both of them available.
My last question is, Is the order important for composite indexes?
Not if you specify both columns. What is the difference between 'AB' and 'BA'? Or between 'ABCDE' and 'EDCBA'? If you only have one value available (e.g. SURNAME) then refer to my question #1 abov: will an index on NAME help you?
See 'Choosing Composite Indexes' in the Performance Tuning Guide
http://docs.oracle.com/cd/B28359_01/server.111/b28274/data_acc.htm#i2773

Why don't be used composite index in partition table.

A table has done range list partition.
Then, I create a composite index named INDEX_N2(COLUMN_005, COLUMN_002). --COLUMN_005 AND COLUMN_002 ARE VARCHAR2
When I run the SQL
select 1
from table1 T1
where T1.COLUMN_005 = 'x'
and T1.COLUMN_002 = 'y'
And view the explain plan, INDEX_N2 has been used.
But when I join the COLUMN_005 to other column, the index will not be used.
The SQL is like below.
select 1
from table1 T1, table T2
where T1.COLUMN_005 = T2.COLUMN_002 --T2.COLUMN_002 IS VARCHAR2
and T1.COLUMN_002 = 'y'
The explain plan is like below
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 426 | 44730 | 65367 (1)| 00:13:05 | | |
|* 1 | HASH JOIN | | 426 | 44730 | 65367 (1)| 00:13:05 | | |
| 2 | PARTITION RANGE ALL| | 8 | 792 | 5 (0)| 00:00:01 | 1 | 32 |
| 3 | PARTITION LIST ALL| | 8 | 792 | 5 (0)| 00:00:01 | 1 | 8 |
|* 4 | TABLE ACCESS FULL| TABLE1 | 8 | 792 | 5 (0)| 00:00:01 | 1 | 256 |
| 5 | PARTITION RANGE ALL| | 1112K| 6519K| 65355 (1)| 00:13:05 | 1 | 34 |
| 6 | PARTITION LIST ALL| | 1112K| 6519K| 65355 (1)| 00:13:05 | 1 | LAST |
| 7 | TABLE ACCESS FULL| TABLE2 | 1112K| 6519K| 65355 (1)| 00:13:05 | 1 | 442 |
Query Block Name / Object Alias (identified by operation id):
1 - SEL$1
4 - SEL$1 / T1@SEL$1
7 - SEL$1 / T2@SEL$1
Predicate Information (identified by operation id):
1 - access("T1"."COLUMN_005"="T2"."COLUMN_002")
4 - filter("T1"."COLUMN_002"='y')
Column Projection Information (identified by operation id):
1 - (#keys=1)
2 - "T1"."COLUMN_005"[VARCHAR2,150]
3 - "T1"."COLUMN_005"[VARCHAR2,150]
4 - "T1"."COLUMN_005"[VARCHAR2,150]
5 - "T2"."COLUMN_002"[VARCHAR2,20]
6 - "T2"."COLUMN_002"[VARCHAR2,20]
7 - "T2"."COLUMN_002"[VARCHAR2,20]
Note
- dynamic sampling used for this statement
My Questin is:
Two columns are include the columns of index.
Why it can't be used?
Thanks

I create a new index on column2, (INDEX_N3)
and change SQL to
select 1 from table T1 where
T1.COLUMN_002 = '848K 36892'
This time INDEX_N3 will be used.
but change SQL to
select 1 from table T1 where
T1.COLUMN_002 = '848K 36892'
and T1.COLUMN_004 = '1000'
The explain plan will show full scan.
Why？
Thanks.

How many is too many columns in a composite index

hi all, (using 10g r2)
i do realize that there is not an exact right answer, but im more curious to find out how others have handled this situation, for better or for worse...
i know the literal upper bound on the number of columns that can be part of a composite index but i was wondering if any of you had come up with what you feel to be practical or upper bounds on the number of columns in a composite index? Also, can anyone share info on what might be strategy to figure out at what point the number of columns in the index creates a situation where updating/maintaining the index outweighs any performance gain you get from the composite index? Thanks in advance! -- jp

user12241698 wrote:
i was wondering if any of you had come up with what you feel to be practical or upper bounds on the number of columns in a composite >index? Also, can anyone share info on what might be strategy to figure out at what point the number of columns in the index creates a >situation where updating/maintaining the index outweighs any performance gain you get from the composite index? sb92075 pointed out the practical limit can only be obtained by testing. This is situational - like everything else, it "depends".
Testing can be done by timing the results of the index variations you want to check. Time multiple uses of the index for DML and query operations involving the index. I like to track the numbers in seconds and put the values in spreadsheets for later reference and easy summation; you can put the data in tables to and use SQL for analysis if you want. I use dbms_utiltiy.get_time in pl/sql (get first time before run, get second time after run, time in fractiions of a second is second time minus first time) or set timing on in sql*plus (hour-minute-second) to obtain run times.
Efficiency depends on what the compsite index is for. Are you trying to enforce uniqueness? Use the composite for data retrieval? Adding exra columns to avoid table access?
Due to maintenance considerations indexes should not have more columns than needed. "duplicate" indexes with the same columns (like "id" vs "id, name") are usually redundant and one index (the one with the fewer columns) can usually be removed.

SQL Query not using Composite Index

Hi,
Please look at the below query:
SELECT pde.participant_uid
,pde.award_code
,pde.award_type
,SUM(decode(pde.distribution_type
,'FORFEITURE'
,pde.forfeited_quantity *
pde.sold_price * cc.rate
,pde.distributed_quantity *
pde.sold_price * cc.rate)) AS gross_Amt_pref_Curr
FROM part_distribution_exec pde
,currency_conversion cc
,currency off_curr
WHERE pde.participant_uid = 4105
AND off_curr.currency_iso_code =
pde.offering_currency_iso_code
AND cc.from_currency_uid = off_curr.currency_uid
AND cc.to_currency_uid = 1
AND cc.latest_flag = 'Y'
GROUP BY pde.participant_uid
,pde.award_code
,pde.award_type
In oracle 9i, i"ve executed this above query, it takes 6 seconds and the cost is 616, this is due to non usage of the composite index, Currency_conversion_idx(From_currency_uid, To_currency_uid, Latest_flag). I wonder why this index is not used while executing the above query. So, I've dropped the index and recreated it. Now, the query is using this index. After inserting many rows or say in 1 days time, if the same query is executed, again the query is not using the index. So everyday, the index should be dropped and recreated.
I don't want this drop and recreation of index daily, I need a permanent solution for this.
Can anyone tell me, Why this index goes stale after a period of time???? Please take some time and Solve this issue.
-Sankar

Hi David,
This is Sankar here. Thankyou for your reply.
I've got the plan table output for this problematic query, please go thro' it and help me out why the index CURRENCY_CONVERSION_IDX is used now and why it's not using while executing the query after a day or inserting some records...
PLAN_TABLE_OUTPUT
| Id | Operation | Name | Rows | Bytes | Cost |
| 0 | SELECT STATEMENT | | 26 | 15678 | 147 |
| 1 | TABLE ACCESS BY INDEX ROWID | PART_AWARD_PAYOUT_SCHEDULE | 1 | 89 | 2 |
|* 2 | INDEX UNIQUE SCAN | PART_AWARD_PAYOUT_SCHEDULE_PK1 | 61097 | | 1 |
| 3 | SORT AGGREGATE | | 1 | 67 | |
|* 4 | FILTER | | | | |
|* 5 | INDEX RANGE SCAN | PART_AWARD_PAYOUT_SCHEDULE_PK1 | 1 | 67 | 2 |
| 6 | SORT AGGREGATE | | 1 | 94 | |
|* 7 | FILTER | | | | |
|* 8 | TABLE ACCESS BY INDEX ROWID | PART_AWARD_PAYOUT_SCHEDULE | 1 | 94 | 3 |
|* 9 | INDEX RANGE SCAN | PART_AWARD_PAYOUT_SCHEDULE_PK1 | 1 | | 2 |
|* 10 | FILTER | | | | |
|* 11 | HASH JOIN | | 26 | 15678 | 95 |
|* 12 | HASH JOIN OUTER | | 26 | 11596 | 91 |
|* 13 | HASH JOIN | | 26 | 10218 | 86 |
| 14 | VIEW | | 1 | 82 | 4 |
| 15 | SORT GROUP BY | | 1 | 116 | 4 |
|* 16 | TABLE ACCESS BY INDEX ROWID | PART_AWARD_LEDGER | 1 | 116 | 2 |
|* 17 | INDEX RANGE SCAN | PARTICIPANT_UID_IDX | 1 | | 1 |
|* 18 | HASH JOIN OUTER | | 26 | 8086 | 82 |
|* 19 | HASH JOIN | | 26 | 6006 | 71 |
| 20 | NESTED LOOPS | | 36 | 5904 | 66 |
| 21 | NESTED LOOPS | | 1 | 115 | 65 |
| 22 | TABLE ACCESS BY INDEX ROWID | CURRENCY_CONVERSION | 18 | 756 | 2 |
|* 23 | INDEX RANGE SCAN | KLS_IDX_CURRENCY_CONV | 3 | | 1 |
| 24 | VIEW | | 1 | 73 | 4 |
| 25 | SORT GROUP BY | | 1 | 71 | 4 |
| 26 | TABLE ACCESS BY INDEX ROWID| PART_AWARD_VALUE | 1 | 71 | 2 |
|* 27 | INDEX RANGE SCAN | PAV_PARTICIPANT_UID_IDX | 1 | | 1 |
| 28 | TABLE ACCESS BY INDEX ROWID | PARTICIPANT_AWARD | 199 | 9751 | 1 |
|* 29 | INDEX UNIQUE SCAN | PARTICIPANT_AWARD_PK1 | 100 | | |
|* 30 | INDEX FAST FULL SCAN | PARTICIPANT_AWARD_TYPE_PK1 | 147 | 9849 | 4 |
| 31 | VIEW | | 1 | 80 | 10 |
| 32 | SORT GROUP BY | | 1 | 198 | 10 |
|* 33 | TABLE ACCESS BY INDEX ROWID | CURRENCY_CONVERSION | 1 | 42 | 2 |
| 34 | NESTED LOOPS | | 1 | 198 | 8 |
| 35 | NESTED LOOPS | | 2 | 312 | 4 |
| 36 | TABLE ACCESS BY INDEX ROWID| PART_DISTRIBUTION_EXEC | 2 | 276 | 2 |
|* 37 | INDEX RANGE SCAN | IND_PARTICIPANT_UID | 1 | | 1 |
| 38 | TABLE ACCESS BY INDEX ROWID| CURRENCY | 1 | 18 | 1 |
|* 39 | INDEX UNIQUE SCAN | CURRENCY_AK | 1 | | |
|* 40 | INDEX RANGE SCAN | CURRENCY_CONVERSION_AK | 2 | | 1 |
| 41 | VIEW | | 1 | 53 | 4 |
| 42 | SORT GROUP BY | | 1 | 62 | 4 |
|* 43 | TABLE ACCESS BY INDEX ROWID | PART_AWARD_VESTING | 1 | 62 | 2 |
|* 44 | INDEX RANGE SCAN | PAVES_PARTICIPANT_UID_IDX | 1 | | 1 |
| 45 | TABLE ACCESS FULL | AWARD | 1062 | 162K| 3 |
| 46 | TABLE ACCESS BY INDEX ROWID | CURRENCY | 1 | 18 | 2 |
|* 47 | INDEX UNIQUE SCAN | CURRENCY_AK | 102 | | 1 |
Predicate Information (identified by operation id):
2 - access("PAPS"."AWARD_CODE"=:B1 AND "PAPS"."PARTICIPANT_UID"=4105 AND "PAPS"."AWARD_TYPE"=:B2
"PAPS"."INSTALLMENT_NUM"=1)
4 - filter(4105=:B1)
5 - access("PAPS"."AWARD_CODE"=:B1 AND "PAPS"."PARTICIPANT_UID"=4105 AND "PAPS"."AWARD_TYPE"=:B2)
7 - filter(4105=:B1)
8 - filter("PAPS"."STATUS"='OPEN')
9 - access("PAPS"."AWARD_CODE"=:B1 AND "PAPS"."PARTICIPANT_UID"=4105 AND "PAPS"."AWARD_TYPE"=:B2)
10 - filter("CC_A_P_CURR"."FROM_CURRENCY_UID"= (SELECT /*+ */ "CURRENCY"."CURRENCY_UID" FROM
"EWAPDBO"."CURRENCY" "CURRENCY" WHERE "CURRENCY"."CURRENCY_ISO_CODE"=:B1))
11 - access("SYS_ALIAS_7"."AWARD_CODE"="A"."AWARD_CODE")
12 - access("SYS_ALIAS_7"."AWARD_CODE"="PVS"."AWARD_CODE"(+))
13 - access("SYS_ALIAS_8"."AWARD_CODE"="PALS"."AWARD_CODE" AND
"SYS_ALIAS_8"."AWARD_TYPE"="PALS"."AWARD_TYPE")
16 - filter(TRUNC("PAL1"."LEDGER_ENTRY_DATE")<=TRUNC(SYSDATE@!) AND "PAL1"."ALLOC_TYPE"='IPU')
17 - access("PAL1"."PARTICIPANT_UID"=4105)
filter("PAL1"."PARTICIPANT_UID"=4105)
18 - access("SYS_ALIAS_8"."AWARD_CODE"="PDES"."AWARD_CODE"(+) AND
"SYS_ALIAS_8"."AWARD_TYPE"="PDES"."AWARD_TYPE"(+))
19 - access("SYS_ALIAS_7"."AWARD_CODE"="SYS_ALIAS_8"."AWARD_CODE")
23 - access("CC_A_P_CURR"."TO_CURRENCY_UID"=1 AND "CC_A_P_CURR"."LATEST_FLAG"='Y')
27 - access("PAV"."PARTICIPANT_UID"=4105)
filter("PAV"."PARTICIPANT_UID"=4105)
29 - access("SYS_ALIAS_7"."AWARD_CODE"="SYS_ALIAS_9"."AWARD_CODE" AND
"SYS_ALIAS_7"."PARTICIPANT_UID"=4105)
30 - filter("SYS_ALIAS_8"."PARTICIPANT_UID"=4105)
33 - filter("CC"."LATEST_FLAG"='Y')
37 - access("PDE"."PARTICIPANT_UID"=4105)
filter("PDE"."PARTICIPANT_UID"=4105)
39 - access("OFF_CURR"."CURRENCY_ISO_CODE"="PDE"."OFFERING_CURRENCY_ISO_CODE")
40 - access("CC"."FROM_CURRENCY_UID"="OFF_CURR"."CURRENCY_UID" AND "CC"."TO_CURRENCY_UID"=1)
43 - filter("PV"."VESTING_DATE"<=SYSDATE@!)
44 - access("PV"."PARTICIPANT_UID"=4105)
filter("PV"."PARTICIPANT_UID"=4105)
47 - access("CURRENCY"."CURRENCY_ISO_CODE"=:B1)
Note: cpu costing is off
93 rows selected.
Please help me out...
-Sankar

Question about composite index and index skip scan

Hi,
I have a confusion.
I have read Burleson's post on composite index column ordering (http://www.dba-oracle.com/t_composite_index_multi_column_ordering.htm) where he writes that
"......for composite indexes the most restrictive column value(the column with the highest unique values) should be put first to trim down the result set..."
But 10g performance tuning book tells this about INDEX SKIP SCAN ::
"... Index Skip scanning lets a composite index be split logically into smaller subindexes. In skip
scanning, the initial column of the composite index is not specified in the query. In other words, it is skipped.
The number of logical subindexes is determined by the number of distinct values in the initial column.
Skip scanning is advantageous if there are few distinct values in the leading column of the composite index and many distinct values in the non-leading key of the index......."
So if we design Composite indexes acc. to what Burleson said then how can we take advantage of index skip scanning. These two staements oppose each other,don't they ?
Can anybody explain this ?

Dear,
For the moment forget the distinct values and the compressibility. I've tried to reproduce your case here below (using jonathan lewis table script)
create table t1
as
with generator as (
    select    --+ materialize
        rownum id
    from dual
    connect by
        rownum <= 10000
select
    rownum              c1,
    mod(rownum,1000)    c2,
    mod(rownum,5000)    c3,
    mod(rownum,10000)   c4,
    lpad(rownum,10,'0') c5,
    rpad('x',5)         c6
from
    generator    v1,
    generator    v2
where
    rownum <= 1000
alter table t1 add constraint t1_pk primary key (c3,c4,c5,C6);
create index idx_1 on t1 (c1,c2);
begin
     dbms_stats.gather_table_stats(
          ownname           => user,
          tabname           =>'T1',
          estimate_percent => 100,
          method_opt       => 'for all columns size 1'
end;
/and here are what I got with your two selects
mho.sql>> SELECT c1,c2
2 FROM t1
3 WHERE c2 = 3;
        C1         C2
         3          3
Elapsed: 00:00:00.00
mho.sql>> start dispcursor
PLAN_TABLE_OUTPUT
SQL_ID 4dbgq3m2utd9f, child number 0
SELECT c1,c2 FROM t1 WHERE c2 = 3
Plan hash value: 3723378319
| Id | Operation            | Name | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
|* 1 | INDEX FAST FULL SCAN| IDX_1 |      1 |      1 |      1 |00:00:00.01 |       7 |
Predicate Information (identified by operation id):
   1 - filter("C2"=3)
17 rows selected.
Elapsed: 00:00:00.34
mho.sql>> SELECT c3,c4,c5,c6
2 FROM t1
3 WHERE c4 = 3
4 AND c5 = '0000000003'
5 AND c6 = 'x    ';
        C3         C4 C5         C6
         3          3 0000000003 x
Elapsed: 00:00:00.00
mho.sql>> @dispcursor
PLAN_TABLE_OUTPUT
SQL_ID fv62c9uqtktw9, child number 0
SELECT c3,c4,c5,c6 FROM t1 WHERE c4 = 3 AND c5 = '0000000003' AND c6 = 'x    '
Plan hash value: 2969533764
| Id | Operation            | Name | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
|* 1 | INDEX FAST FULL SCAN| T1_PK |      1 |      1 |      1 |00:00:00.01 |       9 |
Predicate Information (identified by operation id):
   1 - filter(("C4"=3 AND "C5"='0000000003' AND "C6"='x    '))
17 rows selected.I didn't succeed to reproduce your index skip scan situation.
Best Regards
Mohamed Houri

Bitmap index or Composite index better on a huge table

Hi All,
I got a question regarding the Bitmap index and Composite Index.
I got a table which has got only two colums CUSTOMER(group_no NUMBER, order_no NUMBER)
This is a 100Million+ record table and here I got 100K Group_nos and and unique 100Million order numbers. I.E Each group should have 1000 order numbers.
I tested by creating a GLOBAL Bitmap index on this huge table(more than 1.5gb in size) and the GLOBAL Bitmap index that got created is under 50MB and when I query for a group number say SELECT * FROM CUSTOMER WHERE group_no=67677; --> 0.5 seconds to retrive all the 1000 rows. I checked for different groups and it is the same.
Now I dropped the BitMap Index and re-created a Composite index on( group_no and order_no). The index size more than the table size and is around 2GB in size and when I query using the same select statment SELECT * FROM CUSTOMER WHERE group_no=67677; -->0.5 seconds to retrive all the 1000 rows.
My question is which one is BETTER. BTree or BITMAP Index and WHY?
Appreciate your valuable inputs on this one.
Regars,
Madhu K.

Dear,
Hi All,
I got a question regarding the Bitmap index and Composite Index.
I got a table which has got only two colums CUSTOMER(group_no NUMBER, order_no NUMBER)
This is a 100Million+ record table and here I got 100K Group_nos and and unique 100Million order numbers. I.E Each group should have 1000 order numbers.
I tested by creating a GLOBAL Bitmap index on this huge table(more than 1.5gb in size) and the GLOBAL Bitmap index that got created is under 50MB and when I query for a group number say SELECT * FROM CUSTOMER WHERE group_no=67677; --> 0.5 seconds to retrive all the 1000 rows. I checked for different groups and it is the same.
Now I dropped the BitMap Index and re-created a Composite index on( group_no and order_no). The index size more than the table size and is around 2GB in size and when I query using the same select statment SELECT * FROM CUSTOMER WHERE group_no=67677; -->0.5 seconds to retrive all the 1000 rows.
My question is which one is BETTER. BTree or BITMAP Index and WHY?
Appreciate your valuable inputs on this one.First of all, bitmap indexes are not recommended for write intensive OLTP applications due to the locking threat they can produce in such a kind of applications.
You told us that this table is never updated; I suppose it is not deleted also.
Second, bitmap indexes are suitable for columns having low cardinality. The question is how can we define "low cardinality", you said that you have 100,000 distincts group_no on a table of 100,000,000 rows.
You have a cardinality of 100,000/100,000,000 =0,001. Group_no column might be a good candidate for a bitmap index.
You said that order_no is unique so you have a very high cardinality on this column and it might not be a candidate for your bitmap index
Third, your query where clause involves only the group_no column so why are you including both columns when testing the bitmap and the b-tree index?
Are you designing such a kind of index in order to not visit the table? but in your case the table is made only of those two columns, so why not follow Hermant advise for an Index Organized Table?
Finally, you can have more details about bitmap indexes in the following richard foot blog article
http://richardfoote.wordpress.com/2008/02/01/bitmap-indexes-with-many-distinct-column-values-wotsuh-the-deal/
Best Regards
Mohamed Houri

Using Composite Index Performance Issue

Hi,
Need help:
I have a table 'TABLEA' which has composite index on CODE and DEPT_CODE
While fetching the data from the table 'TABLEA' in the WHERE condition I am using only CODE and not DEPT_CODE.
Is the usage of the WHERE condition by using only the CODE column and not DEPT_CODE column affects the performance?
Any help will be needful for me

See the test case below
SQL> create table test_emp
2 (
3 emp_ssn number,
4 emp_name varchar2(50),
5 emp_state varchar2(15),
6 emp_city varchar2(20)
7 );
Table created
SQL> create index test_emp_idx on test_emp(emp_ssn,emp_name);
Index created
SQL> insert into test_emp values (123456789,'Robben','New York','Buffalo');
1 row inserted
SQL> insert into test_emp values (223456789,'Jack','Florida','Miami');
1 row inserted
SQL> insert into test_emp values (323456789,'Peter','Texas','Dallas');
1 row inserted
SQL> insert into test_emp values (423456789,'Johny','Georgia','Atlanta');
1 row inserted
SQL> insert into test_emp values (523456789,'Carmella','California','San Diego');
1 row inserted
SQL> commit;
Commit complete
SQL> explain plan for select /*+ index(test_emp test_emp_idx) */ * from test_emp where emp_ssn = 323456789;
Explained
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 2345760695
| Id | Operation                   | Name         | Rows | Bytes | Cost (%CPU)
|   0 | SELECT STATEMENT            |              |     1 |    61 |   163   (1)
|   1 | TABLE ACCESS BY INDEX ROWID| TEST_EMP     |     1 |    61 |   163   (1)
|* 2 |   INDEX RANGE SCAN          | TEST_EMP_IDX |     1 |       |     2   (0)
Predicate Information (identified by operation id):
   2 - access("EMP_SSN"=323456789)
Note
   - dynamic sampling used for this statement
18 rows selected
SQL> explain plan for select /*+ INDEX_SS(test_emp test_emp_idx) */ * from test_emp where emp_name = 'Robben';
Explained
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 85087452
| Id | Operation                   | Name         | Rows | Bytes | Cost (%CPU)
|   0 | SELECT STATEMENT            |              |     1 |    61 |    15   (0)
|   1 | TABLE ACCESS BY INDEX ROWID| TEST_EMP     |     1 |    61 |    15   (0)
|* 2 |   INDEX SKIP SCAN           | TEST_EMP_IDX |     1 |       |    11   (0)
Predicate Information (identified by operation id):
   2 - access("EMP_NAME"='Robben')
       filter("EMP_NAME"='Robben')
Note
   - dynamic sampling used for this statement
19 rows selectedThanks,
Andy

Impact of Logging INDEX on Nologging object(TABLE) at the time of Recoveryt

Hi All,
If I have a TABLE which is of NOLOGGING Mode and the index on this table is of LOGGING Mode. If I want to Recover this table in case of its lost. How It will impact? Will it give any Error? Please Explain.....
Thanks in Advance.

You could always do this at the time of the backup to ensure no logging objects are recoverable from the backup at that point in time.......
"alter database force logging "......... this enables the DBA to override no logging to ensure recoverability.

Performance - composite index with 'OR' in 'WHERE' clause

I have a problem with the performance of the following query:
select /*+ index_asc(omschact oma_index1) */ knr, projnr, actnr from omschact where ((knr = 100 and actnr > 30) or knr > 100)
and rownum = 1;
(rownum used only for test purpose)
index:
create index on omschact (knr, projnr);
Execution plan:
Id Operation
0 SELECT STATEMENT
1 COUNT STOPKEY
2 TABLE ACCESS BY INDEX ROWID
3 INDEX FULL SCAN
If I'm correct, the 'OR' in the 'WHERE' clause is responsible for the INDEX FULL SCAN, what makes the query slow.
A solution would be then to separate the 'WHERE' clause in 2 separate select's (1 with 'knr = 100 and actnr > 30' and 1 with 'knr > 100' and combine the results with a UNION ALL.
Since it's necessary to have all rows in ascending order (oma_index1) I still have to use an ORDER BY to make sure the order of the rows is correct. This results again in a (too) low performance.
Another solution that does the trick is to create an index with the 2 fields (knr, projnr) concatenated and to use the same in the 'WHERE' clause:
create index oma_index2 on omschact (knr || projnr);
select /*+ index_asc(omschact oma_index2) */ knr, projnr, actnr from omschact where (knr || projnr) > 10030;
I just can't believe this work-around is the only solution, so I was hoping that someone here knows of a better way to solve this.

padders,
I'll give the real data instead of the example. The index I really use consists of 4 fields. In this table the fields are just numbers, but in other tables I need to use char-fields in indexes, so that's why I concatenate instead of using formula's (allthough I would prefer the latter).
SQL> desc omschact
Name Null? Type
KNR NOT NULL NUMBER(8)
PROJNR NOT NULL NUMBER(8)
ACTNR NOT NULL NUMBER(8)
REGELNR NOT NULL NUMBER(3)
REGEL CHAR(60)
first methode:
SQL> create index oma_key_001(knr,projnr,actnr,regelnr);
Index created.
SQL> select /*+ index_asc(omschact oma_key_001) */ * from omschact where
2 (knr > 100 or
3 (knr = 100 and projnr > 30) or
4 (knr = 100 and projnr = 30 and actnr > 100000) or
5 (knr = 100 and projnr = 30 and actnr = 100000 and regelnr >= 0));
Execution Plan
Plan hash value: 1117430516
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 11M| 822M| 192K (1)| 00:38:26 |
| 1 | TABLE ACCESS BY INDEX ROWID| OMSCHACT | 11M| 822M| 192K (1)| 00:38:26 |
|* 2 | INDEX FULL SCAN | OMA_KEY_001 | 11M| | 34030 (1)| 00:06:49 |
Predicate Information (identified by operation id):
2 - filter("KNR">100 OR "KNR"=100 AND "PROJNR">30 OR "KNR"=100 AND "PROJNR"=30
AND "ACTNR">100000 OR "ACTNR"=100000 AND "KNR"=100 AND "PROJNR"=30 AND
"REGELNR">=0)
second method (same index):
SQL> select * from (
2 select /*+ index_asc(omschact oma_key_001) */ * from omschact where knr > 100
3 union all
4 select /*+ index_asc(omschact oma_key_001) */ * from omschact where knr = 100 and projnr > 30
5 union all
6 select /*+ index_asc(omschact oma_key_001) */ * from omschact where knr = 100 and projnr = 30 and actnr > 100000
7 union all
8 select /*+ index_asc(omschact oma_key_001) */ * from omschact where knr = 100 and projnr = 30 and actnr = 100000 and regelnr > 0)
9 order by knr, projnr, actnr, regelnr;
Execution Plan
Plan hash value: 292918786
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 11M| 1203M| | 477K (1)| 01:35:31 |
| 1 | SORT ORDER BY | | 11M| 1203M| 2745M| 477K (1)| 01:35:31 |
| 2 | VIEW | | 11M| 1203M| | 192K (1)| 00:38:29 |
| 3 | UNION-ALL | | | | | | |
| 4 | TABLE ACCESS BY INDEX ROWID| OMSCHACT | 11M| 822M| | 192K (1)| 00:38:26 |
|* 5 | INDEX RANGE SCAN | OMA_KEY_001 | 11M| | | 33966 (1)| 00:06:48 |
| 6 | TABLE ACCESS BY INDEX ROWID| OMSCHACT | 16705 | 1272K| | 294 (1)| 00:00:04 |
|* 7 | INDEX RANGE SCAN | OMA_KEY_001 | 16705 | | | 54 (0)| 00:00:01 |
| 8 | TABLE ACCESS BY INDEX ROWID| OMSCHACT | 47 | 3666 | | 4 (0)| 00:00:01 |
|* 9 | INDEX RANGE SCAN | OMA_KEY_001 | 47 | | | 3 (0)| 00:00:01 |
| 10 | TABLE ACCESS BY INDEX ROWID| OMSCHACT | 1 | 78 | | 4 (0)| 00:00:01 |
|* 11 | INDEX RANGE SCAN | OMA_KEY_001 | 1 | | | 3 (0)| 00:00:01 |
Predicate Information (identified by operation id):
5 - access("KNR">100)
7 - access("KNR"=100 AND "PROJNR">30)
9 - access("KNR"=100 AND "PROJNR"=30 AND "ACTNR">100000)
11 - access("KNR"=100 AND "PROJNR"=30 AND "ACTNR"=100000 AND "REGELNR">0)
third method:
SQL> create index oma_test(to_char(knr,'00000000')||to_char(projnr,'00000000')||to_char(actnr,'00000000')||to_char(regelnr,'000'));
Index created.
SQL> select /*+ index_asc(omschact oma_test) */ * from omschact where
2 (to_char(knr,'00000000')||to_char(projnr,'00000000')||
3 to_char(actnr,'00000000')||to_char(regelnr,'000')) >=
4 (to_char(100,'00000000')||to_char(30,'00000000')||
5* to_char(100000,'00000000')||to_char(0,'000'))
Execution Plan
Plan hash value: 424961364
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 553K| 55M| 1712 (1)| 00:00:21 |
| 1 | TABLE ACCESS BY INDEX ROWID| OMSCHACT | 553K| 55M| 1712 (1)| 00:00:21 |
|* 2 | INDEX RANGE SCAN | OMA_TEST | 99543 | | 605 (1)| 00:00:08 |
Predicate Information (identified by operation id):
2 - access(TO_CHAR("KNR",'00000000')||TO_CHAR("PROJNR",'00000000')||TO_CHAR("
ACTNR",'00000000')||TO_CHAR("REGELNR",'000')>=TO_CHAR(100,'00000000')||TO_CHAR(3
0,'00000000')||TO_CHAR(100000,'00000000')||TO_CHAR(0,'000'))

Impact of seconday indexes

Hi,
I want to create a few secondary indexes for my table.
But I could able to know that it's not good interms of performance. So Could anyone explain how the permance will be effected actually in detail and what's the alternative for my problem.
Thanks
G Kumari.
Moderator message - Please search before asking - post locked
Edited by: Rob Burbank on May 20, 2009 10:44 AM

Hi,
I want to create a few secondary indexes for my table.
But I could able to know that it's not good interms of performance. So Could anyone explain how the permance will be effected actually in detail and what's the alternative for my problem.
Thanks
G Kumari.
Moderator message - Please search before asking - post locked
Edited by: Rob Burbank on May 20, 2009 10:44 AM

Impact of Creating new index ?

Hi All, I am using 10.2.0.4.0 version of oracle.
I want expert advice in below scenario.
I need to create one index, as because a particular 'Search' query going slow and my customer frequently accessing that 'Search' Functionality. i have tried all alternative for tuning that query, and finally decided to go for creating New Composite index on two columns of a table that is used in the query.
So my question/concern is , what will be the impact on other 'Select' queries those are using these columns in their predicate? Whether there is any possibility of any negative impact(slow performance) on them due to this new index. What should be the right way to go for impact analysis in the above scenario?
( Please note in this case i am least bothered about the impact on 'INSERTS' due to this index creation).

>
Hi again,
For now, can you please confirm, As 'rp0428' mentioned there is chances of better performance in other 'Select' queries,
but there is no chance of performance degradation to this new index in other queries. As because oracle will evaluate the best among all.
Is the above statement always hold true or there may be deviations?Hmmm... I can see no good reason why an added index should adversely affect other SELECTs - the optimiser should
simply ignore the new index if it doesn't impact other queries - and may make use of it in ways you didn't forsee.
Having said that, I can't guarantee that this is the case. I would run tests before implementing it in production - at least
try and test your most common/frequently run queries - remember [url http://en.wikipedia.org/wiki/Pareto_principle]Paretos law.
A small fraction of your queries will have a large impact on the system and some will be "marginal" to performance/usage.
Sometimes the optimiser behaves in counter-intuitive ways - run at least some tests and then try it is what I would do if you
(can't | don't have the time to) test exhaustively.
HTH,
Paul...

Primary Key in DW and indexes - composite key of all dimensional FKs?

Hi guys,
I have a DW and indexing question. Our metadata DW and physical DW are the same (star schema, no snowflakes). Should all dimensional FKs (such as TIME_KEY, ORG_KEY) be included as a part of a fact table's PK (a composite key becomes a combination of the TIME_KEY, ORG_KEY, etc.) in the database. Second question is, should we create just 1 composite index per fact table (resembling fact table's PK) or should we build several indexes (1 per dimension) ? Also, does it pay to build indexes on dimension tables?
I'm mostly worried about fact table with a few hundred million records that has 7 dimensional-FK columns(only numeric codes), 1 value column, and several ETL-related date columns. I wonder what's the best course scenario be for that one.
Thank you.

You can use bitmap indexes on foreign keys to enable star transformations to be carried out. There are full details in the Datawarehouse documentation. Unfortunately I can't access it at the moment to show you where!
As with anything you can check your performance using oracle trace events (10046) to ensure its performing as you want.
http://www.dwoptimize.com/2007/06/101010-answer-to-life-universe-and.html
Edited by: Matt T on Oct 22, 2008 4:50 PM

Negative performance impact of index

A SELECT statement I've written references an otherwise unused VARCHAR2 column in a table that defaults to NULL, and which is set by another statement for some (not all) rows to a three-character string (like 'XYZ'). The query takes 2.5 hours to complete, but with an index added on the column, finishes in 2 to 3 minutes. I'm perfectly satisfied with this solution, but my extremely cautious colleagues (one in particular) are concerned that adding an index will negatively impact the performance of other INSERT or UPDATE statements that reference the table but not the column. I think they're being wildly overcautious, that an index on a column that can contain only 2 values will have minimal impact on other DML statements, if any. Am I right? Is there a reference I could consult to settle disputes like this?
Any opinions would be gratefully accepted.

djenkins99 wrote:
Is there a way to measure the impact of an index on inserts and updates? I could generate an explain plan, but I don't know how to translate the results of the explain plan into actual time (seconds less or more it takes a statement to execute). Even with my select statement, the explain plans taken before and after adding the index are definitely different, and the explain plan with the index shows it being used, although the total cost of the query with or without the index is minimally different.The "cost" of INDEX maintenance is not available as separate metric as far as I know.
It can be obtained indirectly.
1) CREATE TABLE BENCH(ID NUMBER);
2) INSERT INTO BENCH SELECT ID FROM MANY_ROWS_TABLE;
measure how long INSERT takes
SHUTDOWN IMMEDIATE
STARTUP
-- clears SGA of cached rows
3) TRUNCATE TABLE BENCH;
4) CREATE INDEX NDX_ID ON BENCH(ID);
5) INSERT INTO BENCH SELECT ID FROM MANY_ROWS_TABLE;
measure how long INSERT takes
the duration difference is cost to maintain the INDEX

Bitmap join indexes

Hi all,
here's the background to my problem: have 4 large tables (40 mill records) - each with an id (same id for all of them) and lots of low-cardinality columns ('classification'-columns).
The objective is to be able to do a fast count of the id's across the tables based on various criterias for the 'classification' columns.
I also need to be able to add tables of the same format ideally without having to rebuild the whole thing.
To this end I've been experimenting with bitmap-indexes and bitmap join indexes.
Quering one table with a bitmap index on each of the 'class' columns achieves the performance goal:
select count(*)
from cl_dumc1
where class1 in (1,2,3)
and class2 = 4
and class3=2
However when I need to select across 2 or more tables I do not get the required performance:
select count(*)
from cl_dumc1 c1,
cl_dumc2 c2
where c1.class1 in (1,2,3)
and c1.class2 = 4
and c1.class3=2
and c2.class21=5
and c1.id = c2.id
As you know a bitmap index is a map (one map per distinct value of the column) onto the rowid's in the table.
So what I really wanted was bitmap indexes that maps not to the the rowids but my ID column (since this is common across all the tables).
I figured I could do this by having a skinny table (cl_central) with only one column (ID), and then create bitmap join indexes that binds my 'real' tables together to one central id (being the rowid of my cl_central table).
Here's a sample script:
create sequence dum;
create table cl_central
(id number);
insert into cl_central
select dum.nextval,dum.nextval
from all_objects;
create table cl_dumc1(id number, class1 number, class2 number, class3 number, class4 number, class5 number);
insert into cl_dumc1
select id,mod(id,4), mod(id+1,4), mod(id+2,4), mod(id+3,4), mod(id+4,4) from cl_central;
create table cl_dumc2
(id number, class21 number, class22 number, class23 number, class24 number, class25 number);
insert into cl_dumc2
select id,mod(id,4),mod(id+1,4),mod(id+2,4),mod(id+3,4),mod(id+4,4) from cl_central;
create table cl_dumc3 (id number, class31 number, class32 number, class33 number, class34 number, class35 number);
insert into cl_dumc3
select id,mod(id,4),mod(id+1,4),mod(id+2,4),mod(id+3,4),mod(id+4,4)from cl_central;
create table cl_dumc4(id number, class41 number, class42 number, class43 number, class44 number, class45 number);
insert into cl_dumc4
select id,mod(id,4),mod(id+1,4),mod(id+2,4),mod(id+3,4),mod(id+4,4)from cl_central;
create unique index cl_central_pk on cl_central (id);
alter table cl_central add constraint cl_central_pk primary key (id);
create unique index cl_dumc1_pk on cl_dumc1 (id);
create unique index cl_dumc2_pk on cl_dumc2 (id);
create unique index cl_dumc3_pk on cl_dumc3 (id);
create unique index cl_dumc4_pk on cl_dumc4 (id);
alter table cl_dumc1 add constraint cl_dumc1_pk primary key (id);
alter table cl_dumc2 add constraint cl_dumc2_pk primary key (id);
alter table cl_dumc3 add constraint cl_dumc3_pk primary key (id);
alter table cl_dumc4 add constraint cl_dumc4_pk primary key (id);
declare
i number;
begin
for c in (select table_name,column_name from user_tab_columns where table_name in ('CL_DUMC1','CL_DUMC2','CL_DUMC3','CL_DUMC4') and column_name !='ID') loop
select count(*) into i from user_indexes where index_name=c.column_name;
if i = 0 then
EXECUTE IMMEDIATE 'CREATE BITMAP INDEX '||c.column_name||'
ON cl_central('||c.table_name||'.'||c.column_name||')
FROM cl_central, '||c.table_name||'
WHERE cl_central.id = '||c.table_name||'.id';
end if;
end loop;
end;
Test some queries:
select /*+INDEX(z class1)
count(*)
from cl_central z,
cl_dumc1 c1
where z.person_urn = c1.person_urn
and c1.class1=0
Explain plan:
SELECT STATEMENT Cost= 15
SORT AGGREGATE
BITMAP CONVERSION COUNT
BITMAP INDEX SINGLE VALUE CLASS1
So far so good - very quick with just selecting on the bitmap.
select /*+INDEX(z class1)
INDEX(z class21)
          INDEX(z class31)
          INDEX(z class41)
          INDEX(z class42)
count(*)
from cl_central z,
cl_dumc1 c1,
cl_dumc2 c2,
cl_dumc3 c3,
cl_dumc4 c4
where z.id= c1.id
and z.id = c2.id
and z.id = c3.id
and z.id = c4.id
and c1.class1=0
and c2.class21=0
and c3.class31=0
and c4.class41=0
SELECT STATEMENT Cost= 4
SORT AGGREGATE
BITMAP CONVERSION COUNT
BITMAP AND
BITMAP INDEX SINGLE VALUE CLASS1
BITMAP INDEX SINGLE VALUE CLASS21
BITMAP INDEX SINGLE VALUE CLASS31
BITMAP INDEX SINGLE VALUE CLASS41
Look great - very fast accessing just small bitmap indexes.
select /*+INDEX(z class1)
INDEX(z class21)
INDEX(z class31)
INDEX(z class41)
INDEX(z class42)
count(*)
from cl_central z,
cl_dumc1 c1,
cl_dumc2 c2,
cl_dumc3 c3,
cl_dumc4 c4
where z.id = c1.id
and z.id = c2.id
and z.id = c3.id
and z.id = c4.id
and c1.class1=0
and c2.class21=0
and c3.class31=0
and c4.class41=0
and c4.class42 =1
SELECT STATEMENT Cost= 16
SORT AGGREGATE
HASH JOIN
TABLE ACCESS FULL CL_DUMC4
TABLE ACCESS BY INDEX ROWID CL_CENTRAL
BITMAP CONVERSION TO ROWIDS
BITMAP AND
BITMAP INDEX SINGLE VALUE CLASS1
BITMAP INDEX SINGLE VALUE CLASS21
BITMAP INDEX SINGLE VALUE CLASS31
BITMAP INDEX SINGLE VALUE CLASS41
BITMAP INDEX SINGLE VALUE CLASS42
Disaster (well it is with my volumes...) - it visits the tables in addition to the bitmaps - AND I CANT SEE THE REASON FOR IT - all I did was to add a second condition to the last classification table.
Does anyone have any explanation for this?

Is the cardinality of
c4.class41 and c4.class42
combined also low?
Probably Oracle thinks that the cardinality of class41 and class42 column values is not low and it needs to do a full table access of table C4. Check the cardinality of class41 and class42 put together.
Did you try creating a bitmap index (or a regular composite index) on both class41 and class42 columns? A regular index on both the columns together will help in this case.
Shakti
(http://www.impact-sol.com)
(Developers of Guggi Oracle - Tool for DBAs and Developers)

Impact of composite index

Similar Messages

Maybe you are looking for