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

Similar Messages

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.

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

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

Compound index vs separate indexes

Hi,
I am having a table with 12 million records.
My query will be always having 2 conditions in WHERE clause.
SELECT * FROM TABLE WHERE c1='some integer' and c2 in (some values)In this case which index will be appropriate.?
a)Creating separate indexes on c1 and c2
b)creating a compound index on (c1,c2)
What are the things i need to consider before creating index in this case>
Thanks

>
In this case which index will be appropriate.?
a)Creating separate indexes on c1 and c2
b)creating a compound index on (c1,c2)
What are the things i need to consider before creating index in this case>
>
Well I must say I disagree with ALL of the answers provided so far because none of them take into account those 'things you need to consider' before creating an index (or indexes).
1. What is the selectivity of column C1? How many distinct values? How are the data values clustered?
2. What is the selectivity of column C2? How many distinct values? How are the data values clustered?
3. What will the clustering factor of the index be? That is, is the table data in any particular order that would result in an exceptionally good, or poor, cluster factor for the index?
4. Will any queries only need column 'c2' for filtering?
5. Will any queries only need column C2 for filtering?
Without knowing at least the above information there is no way to tell if ANY index is appropriate, let alone how many or the ordering of columns for a composite index.
Just consider point #1 above. If there are only two values for C1 and 6 million records have each value what good would an index be?
But if column C1 is unique then an index would be very selective and you don't need to consider the C2 value at all.
Likewise if the cardinality of C1 is low (few records have the same value) but cardinality of C2 is high the index should be on C1 only since including C2 would dilute the index and require more records to be read to get the ROWIDs of interest. And in cardinality of C2 is low but C1 is high then C2 might be better as the lead colum since an INDEX SKIP SCAN could be used.
If you can provide the information asked for above then better recommendations can be provided.

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.

Column order in the index and its effects

Lets say i've an index called ind_tab3 which is made up of two columns in the following order (col1,col2). If query comes against the table with WHERE clause like 'WHERE col2 =35' , will the ind_tab3 index be used. If this index is not used for this query, then what is the point of creating composite indexes? I know that an Index is created automatically for a primary key , which can be composite . So lets ignore this on our discussion.

My point is:
1) review every query on your system
2) then choose an appropriate indexing strategy
So if the col2 value is not used in an AND
clause either, the ind_tab3 index wouldn't be
used at all. Right?David replied to that. Index skip scan or index fast full scan MIGHT kick in.

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.

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

Multi-column Index vs One index for each column

Hello everyone,
i have one table about 20 000 000 rows, some developers have to generate reports on it and i want to create indexes on this table.
The table has 34 columns, no primary key, no unique keys.
The "where..." clause of the reports usually use 8 columns but some reports uses 8 + some other columns.
can any one help me on what kind of indexes do i have to create?
1. one index for each column used in "where clause"
2. one index for 8 columns and some other indexes for other used columns
3. one index for all columns
or something else etc...
br flag

i have one table about 20 000 000 rows, some developers have to generate reports on it and i want to create indexes on this table.
The table has 34 columns, no primary key, no unique keys.
The "where..." clause of the reports usually use 8 columns but some reports uses 8 + some other columns.
can any one help me on what kind of indexes do i have to create?
1. one index for each column used in "where clause"
2. one index for 8 columns and some other indexes for other used columns
3. one index for all columns
or something else etc...What's the version of your data base? what kind of database you have, DWH or OTLP? The answer might depend on the type of database as far as bitmap indexes might suit or might not depending if you are runing DWH or OLTP kind of database
Let me suppose that you are runing OLTP database and you have a where clause with 8 columns.
1) are all those where clause equalities (where col1 = and col2 =) or there are inequalities?
2) could you evaluate the most repetitive columns?
3) could you know the column that could have the best clustering factor (the column which most follow a certain order in the table)
Based on that I would suggest to create one b-tree index having 8 columns (even though that it seems for me to high) this index should follow the following points:
1) put the most repetitive column at the leading edge (and compress the index if necessary)
2) put the columns that are used in equalitity predicate first
3) put the column having the best clustering factor first
The most precise index you have the best access you could gain.
Of course that you have to know that an index access is not always good and a FULL table scan is not always bad.
Best regards
Mohamed Houri
www.hourim.wordpress.com

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

Deadlock when updating different rows on a single table with one clustered index

Deadlock when updating different rows on a single table with one clustered index. Can anyone explain why?
<event name="xml_deadlock_report" package="sqlserver" timestamp="2014-07-30T06:12:17.839Z">
<data name="xml_report">
<value>
<deadlock>
<victim-list>
<victimProcess id="process1209f498" />
</victim-list>
<process-list>
<process id="process1209f498" taskpriority="0" logused="1260" waitresource="KEY: 8:72057654588604416 (8ceb12026762)" waittime="1396" ownerId="1145783115" transactionname="implicit_transaction"
lasttranstarted="2014-07-30T02:12:16.430" XDES="0x3a2daa538" lockMode="X" schedulerid="46" kpid="7868" status="suspended" spid="262" sbid="0" ecid="0" priority="0"
trancount="2" lastbatchstarted="2014-07-30T02:12:16.440" lastbatchcompleted="2014-07-30T02:12:16.437" lastattention="1900-01-01T00:00:00.437" clientapp="Internet Information Services" hostname="CHTWEB-CH2-11P"
hostpid="12776" loginname="chatuser" isolationlevel="read uncommitted (1)" xactid="1145783115" currentdb="8" lockTimeout="4294967295" clientoption1="671088672" clientoption2="128058">
<inputbuf>
UPDATE analyst_monitor SET cam_status = N'4', cam_event_data = N'sales1', cam_event_time = current_timestamp , cam_modified_time = current_timestamp , cam_room = '' WHERE cam_analyst_name=N'ABCD' AND cam_window= 2 </inputbuf>
</process>
<process id="process9cba188" taskpriority="0" logused="2084" waitresource="KEY: 8:72057654588604416 (2280b457674a)" waittime="1397" ownerId="1145783104" transactionname="implicit_transaction"
lasttranstarted="2014-07-30T02:12:16.427" XDES="0x909616d28" lockMode="X" schedulerid="23" kpid="8704" status="suspended" spid="155" sbid="0" ecid="0" priority="0"
trancount="2" lastbatchstarted="2014-07-30T02:12:16.440" lastbatchcompleted="2014-07-30T02:12:16.437" lastattention="1900-01-01T00:00:00.437" clientapp="Internet Information Services" hostname="CHTWEB-CH2-11P"
hostpid="12776" loginname="chatuser" isolationlevel="read uncommitted (1)" xactid="1145783104" currentdb="8" lockTimeout="4294967295" clientoption1="671088672" clientoption2="128058">
<inputbuf>
UPDATE analyst_monitor SET cam_status = N'4', cam_event_data = N'sales2', cam_event_time = current_timestamp , cam_modified_time = current_timestamp , cam_room = '' WHERE cam_analyst_name=N'12345' AND cam_window= 1 </inputbuf>
</process>
</process-list>
<resource-list>
<keylock hobtid="72057654588604416" dbid="8" objectname="CHAT.dbo.analyst_monitor" indexname="IX_Clust_scam_an_name_window" id="lock4befe1100" mode="X" associatedObjectId="72057654588604416">
<owner-list>
<owner id="process9cba188" mode="X" />
</owner-list>
<waiter-list>
<waiter id="process1209f498" mode="X" requestType="wait" />
</waiter-list>
</keylock>
<keylock hobtid="72057654588604416" dbid="8" objectname="CHAT.dbo.analyst_monitor" indexname="IX_Clust_scam_an_name_window" id="lock18ee1ab00" mode="X" associatedObjectId="72057654588604416">
<owner-list>
<owner id="process1209f498" mode="X" />
</owner-list>
<waiter-list>
<waiter id="process9cba188" mode="X" requestType="wait" />
</waiter-list>
</keylock>
</resource-list>
</deadlock>
</value>
</data>
</event>

To be honest, I don't think the transaction is necessary, but the developers put it there anyway. The select statement will put the result cam_status
into a variable, and then depends on its value, it will decide whether to execute the second update statement or not. I still can't upload the screen-shot, because it says it needs to verify my account at first. No clue at all. But it is very simple, just
like:
Clustered Index Update
[analyst_monitor].[IX_Clust_scam_an_name_window]
cost: 100%
By the way, for some reason, I can't find the object based on the associatedObjectId listed in the XML
<keylock hobtid="72057654588604416" dbid="8" objectname="CHAT.dbo.analyst_monitor"
indexname="IX_Clust_scam_an_name_window" id="lock4befe1100" mode="X" associatedObjectId="72057654588604416">
For example:
SELECT * FROM sys.partition WHERE hobt_id = 72057654588604416
This return nothing. Not sure why.

Convert multiple rows into single rows for the respective index name

Dear Experts,
                         I want to convert multiple rows into single rows for the respective index name,
                        Here is my query.
SELECT user_tables.table_name, user_indexes.index_name, user_ind_columns.column_name
FROM user_tables
JOIN user_indexes on user_indexes.table_name = user_tables.table_name
join USER_IND_COLUMNS on USER_INDEXES.INDEX_NAME = USER_IND_COLUMNS.INDEX_NAME
where user_indexes.index_name not like '%PK%' AND user_ind_columns.column_name NOT LIKE '%SYS%'
ORDER BY user_tables.table_name,user_indexes.index_name;
Result of previous query
TABLE_NAME
INDEX_NAME
COLUMN_NAME
T1
IDX_ACCNTYPCFG1
ENABLE_SERVICE
T1
IDX_ACCTTYPCFG1
ACC_CODE
T1
IDX_ACCTTYPCFG1
ACCTYPE
T2
IDX_ACCTTYPCFGAPP1
ACCTYPE
T3
IDX_ACTLG1
MOBILE_NO
T3
IDX_ACTLG1
ID
Desired output required is
TABLE_NAME
INDEX_NAME
COLUMN_NAME
T1
IDX_ACCNTYPCFG1
ENABLE_SERVICE,ACC_CODE,ACCTYPE
T2
IDX_ACCTTYPCFGAPP1
ACCTYPE
T3
IDX_ACTLG1
ACCTYPE,MOBILE_NO
please help.

Maybe
with
user_tables as
(select 'T1' table_name,'IDX_ACCNTYPCFG1' index_name,'ENABLE_SERVICE' column_name from dual union all
select 'T1','IDX_ACCTTYPCFG1','ACC_CODE' from dual union all
select 'T1','IDX_ACCTTYPCFG1','ACCTYPE' from dual union all
select 'T2','IDX_ACCTTYPCFGAPP1','ACCTYPE' from dual union all
select 'T3','IDX_ACTLG1','MOBILE_NO' from dual union all
select 'T3','IDX_ACTLG1','ID' from dual
select table_name,
       case index_name when 'IDX_ACCNTYPCFG1' then 'IDX_ACCTTYPCFG1' else index_name end index_name,
       listagg(case column_name when 'ID' then 'ACCTYPE' else column_name end,',') within group (order by null) column_name
from user_tables
group by table_name,case index_name when 'IDX_ACCNTYPCFG1' then 'IDX_ACCTTYPCFG1' else index_name end
TABLE_NAME
INDEX_NAME
COLUMN_NAME
T1
IDX_ACCTTYPCFG1
ACCTYPE,ACC_CODE,ENABLE_SERVICE
T2
IDX_ACCTTYPCFGAPP1
ACCTYPE
T3
IDX_ACTLG1
ACCTYPE,MOBILE_NO
Regards
Etbin

How get column index and row index in gridpane of javafx

how get column index and row index in gridpane of javafx. see the code below
Text text1 = new Text("Text 1");
Text text2 = new Text("Text 2");
StackPane root = new StackPane();
GridPane gridPane = new GridPane();
gridPane.add(text1, 0, 0);
gridPane.add(text2, 1, 0);
When Mouse Entered On text1 i want to get the column index and row index of GridPane
text1.setOnMouseEntered(new EventHandler<MouseEvent>() {
            @Override
            public void handle(MouseEvent e) {
                //want to get column index =0 and row index=0
Please let me know.

Hi,
If I remember well:
[code]
text1.setOnMouseEntered(new EventHandler<MouseEvent>() {
            @Override
            public void handle(MouseEvent e) {
                //want to get column index =0 and row index=0
                System.out.println("Column: " + GridPane.getColumnIndex(text1));
[/code]
-- daniel

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

Single column index vs composite index?

Similar Messages

Maybe you are looking for