Index firing for a column

i have a problem that the index is not firing for a particular column in my table when i check using plan table. I am checking using explain plan table. For another column, it is firing. What can i do to rectify it as this is very critical for me.
I hope, my question is clear. Please help in solving the doubt as it is urgent.
Regards.

> i have a problem that the index is not firing
btw, although it was clear what you meant, the word "firing" is normally used when referring to triggers. You can just say "the index is not being used".
Presumably either the query makes it impossible to use the index, due to a function being applied to the column for example, or else the optimizer has calculated that the index will not improve performance. Given correct statistics on the tables, it is usually right.

Similar Messages

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

How to create index for a column of a view

Hi,
I have created view for a table and then i am trying to create index for a column of that view. i am using the query "CREATE INDEX index_name ON view_name (col)". but Mysql is showing error like "view_name is not a base table".
How can i do that......

As mentioned this is a java forum not a mysql forum, but as I know the answer - you can't create an index directly on a view in mysql.

Spatial index creation for table with more than one geometry columns?

I have table with more than one geometry columns.
I'v added in user_sdo_geom_metadata table record for every column in the table.
When I try to create spatial indexes over geometry columns in the table - i get error message:
ERROR at line 1:
ORA-29855: error occurred in the execution of ODCIINDEXCREATE routine
ORA-13203: failed to read USER_SDO_GEOM_METADATA table
ORA-13203: failed to read USER_SDO_GEOM_METADATA table
ORA-06512: at "MDSYS.SDO_INDEX_METHOD", line 8
ORA-06512: at line 1
What is the the solution?

I'v got errors in my user_sdo_geom_metadata.
The problem does not exists!

More than one index for a column.

Hi,
I am trying to create more than one index for a particular column of the table.But oracle does not allow more than one index for a column.
I just want to make sure whether we can add more than one index for a column
and if yes what are the scenarios.
Because as far as i know some database allows more than one index for a single column.

You cannot create more than one index for the same column(s).This is not so true Nicolas. Look at following example:
SQL> create index idx_mytest_id on mytest(id);
Index created.
SQL> create index idx_mytest_id_desc on mytest(id desc);
Index created.
SQL> create index idx_fbi_mytest_id_upper on mytest(upper(id));
Index created.
SQL> create index idx_fbi_mytest_id_upper_desc on mytest(upper(id) desc);
Index created.
SQL> create index idx_fbi_mytest_id_lower_id on mytest(lower(id));
Index created.
SQL> create index idx_fbi_mytest_id_lower_id_dsc on mytest(lower(id) desc);
Index created.
SQL> create index idx_fbi_mytest_id_tr_up on mytest(trunc(upper(id)));
Index created.
-- I can still continue but for this example this will be enough
SQL> select index_name from dba_indexes where table_name = 'MYTEST';
INDEX_NAME
IDX_MYTEST_ID
IDX_FBI_MYTEST_ID_UPPER
IDX_MYTEST_ID_DESC
IDX_FBI_MYTEST_ID_UPPER_DESC
IDX_FBI_MYTEST_ID_LOWER_ID
IDX_FBI_MYTEST_ID_LOWER_ID_DSC
IDX_FBI_MYTEST_ID_TR_UP
7 rows selected.You can see 7 indexes for one column (ID) and I could still continue...
So according this test we can say you can't create more than one index for one column (or the same group of columns in case of composite index) with same condition(s).
Message was edited by:
Ivan Kartik
Or simplified: you can't create the same index for same column(s) twice :-)

WHat is the best index type for non uniqueness / Varchar columns in SQL 2008 R2

Hello All Greetings,
Please help me here with my doubt,
in my table i have two columns about a million rows, it has about 20 columns in it, three columns with name as Period, Gender so most of the time these two columns use in where clause,
Gender will contain Either M or F , Period contains YYYY-Month (2013-December, 2013-August) etc so i would like to add a Index to these two columns so that in will increase the performance, so please let me know what type of indexes i need to add to
these columns in the table,
please note that only one time we will add data to the table which will take only 2 minutes but we query the table every day
so my question what is the best index type that i need to create on columns with non uniqueness values in the column.,
Thank you In Advance,
Milan

There is nothing whatever wrong with creating an index on a VARCHAR column, or set of columns.
Regarding the performance of VARCHAR/INT, as with everything in a RDBMS, it depends on what you are doing. What you may be thinking of is the fact that clustering a table on a VARCHAR key is (in SQL Server) marginally less efficient than clustering on a monotonically
increasing numerical key, and can introduce fragmentation.
Or you may be thinking of what you have heard about writing JOINs on VARCHAR columns - it is true, it is a little less efficient than a JOIN on numeric type, but it is only a little less efficient, nothing that would lead you to never join on varchar cols.
None of this does not mean that you should not create indexes on VARCHAR columns. A needed index on a VARCHAR column will boost query performance, often by orders of magnitude. If you need an index on a VARCHAR, create it. It makes no sense to try to find an
integer column to create the index on - the engine will never use it.
Check this reference: http://stackoverflow.com/questions/14041481/is-it-good-to-create-a-nonclustered-index-on-a-column-of-type-varchar
Mark ANSWER if this reply resolves your query, If helpful then VOTE HELPFUL
INSQLSERVER.COM
Mohammad Nizamuddin

DropDown By Index for a Column in ALV

Hi,
I am trying to create a dropdown for a column in ALV. I have used the following code for the same.
data:
          lr_drdn_by_index type ref to cl_salv_wd_uie_dropdown_by_idx.
        create object lr_drdn_by_index
          exporting
            selected_key_fieldname = ls_column-id.
        lr_drdn_by_index->set_valueset_fieldname( 'VALUESET' ).
        lr_drdn_by_index->set_type( if_salv_wd_c_uie_drdn_by_index=>type_key_value ).
        ls_column-r_column->set_cell_editor( lr_drdn_by_index ).
"VALUESET" Contains the Dropdown Data.
Is there any settings that I have to do which is missing?
Regards,
Shruthi

Hi,
follow these steps :
1) create a node for example (NODE_LIST)
2) crrate an attribute (LIST: type WDY_UIE_LIBRARY_ENUM_TYPE)
3) in your WDDOINIT method, populate your list :
lr_node = wd_context->get_child_node('NODE_LIST').
lr_node_info = lr_node->get_node_info( ).
ls_value_set-key = 10.
ls_value_set-value = 'tes'.
INSERT ls_value_set INTO TABLE lt_value_set.
ls_value_set-key = 20.
ls_value_set-value = 'tes'.
INSERT ls_value_set INTO TABLE lt_value_set.
lr_node_info->set_attribute_value_set(
name = 'LIST'
value_set = lt_value_set ).
4) in your table settings :
data :
list_field    TYPE REF TO cl_salv_wd_uie_dropdown_by_key.
CREATE OBJECT list_field
      EXPORTING selected_key_fieldname = ls_columns-id.
ls_columns-r_column->set_cell_editor( list_field ).
I hoep this helps, if not please clarify your question.
Regards

Which type of index is useful for date columns with time stamp

Hi all,
I am using date column in the where clause of an SQL Query. The values stored in the date column are includes timestamp. The query is very slow and there is no index on the date column.
Can any body suggest which index is better on date columns
Thanks

I am using date column in the where clause of an SQL Query.Dates a re hard queries to tune. This ...
WHERE start_date BETWEEN to_date('01-SEP-05') AND to_date('02-SEP-05')...probably requires a very different execution plan to this...
WHERE start_date BETWEEN to_date('01-JAN-01') AND to_date('02-SEP-05')Just bunging an index on the date column may speed up your specific query but break something else. So be careful.
Cheers, APC

Index usage depends on columns selected

Hi, somehow cannot understand why index is not used, please help.
in Oracle Database 11g Release 11.2.0.3.0 - 64bit Production
1.     Included only indexed column and got a perfect plan
explain plan for2 select s.x_cnt
3 from reported_summary s
4 where s.x_cnt>0;
PLAN_TABLE_OUTPUT
Plan hash value: 2674489506
| Id | Operation | Name | Cost (%CPU)|
| 0 | SELECT STATEMENT | | 306 (8)|
|* 1 | INDEX FAST FULL SCAN| S_NUI01 | 306 (8)|
Predicate Information (identified by operation id):
1 - filter("s"."x_CNT">0)
2.     Included some other column and got TABLE ACCESS FULL
explain plan for2 select s.x_cnt,s.ru_id
3 from reported_summary s
4 where s.x_cnt>0;
PLAN_TABLE_OUTPUT
Plan hash value: 2142873335
| Id | Operation | Name | Cost (%CPU)|
| 0 | SELECT STATEMENT | | 2421 (3)|
|* 1 | TABLE ACCESS FULL| REPORTED_SUMMARY | 2421 (3)|
Predicate Information (identified by operation id):
1 - filter("s"."x_CNT">0)
3.     Included all other columns and got TABLE ACCESS FULL as well
explain plan for2 select s.x_cnt,s.*
3 from reported_summary s
4 where s.x_cnt>0;
PLAN_TABLE_OUTPUT
Plan hash value: 2142873335
| Id | Operation | Name | Cost (%CPU)|
| 0 | SELECT STATEMENT | | 2421 (3)|
|* 1 | TABLE ACCESS FULL| REPORTED_SUMMARY | 2421 (3)|
Predicate Information (identified by operation id):
1 - filter("s"."x_CNT">0)
Thanks a lot

Thanks all, just to clarify
"select s.x_cnt from reported_summary s..." is using index;
"select 'Y' y from reported_summary s..." is using index;
"select <any ohter column> from reported_summary s..." is causing TABLE ACCESS FULL;
no differences in where clause, no order by at all
the index script is
CREATE INDEX S_NUI01 ON REPORTED_SUMMARY (OFFSET_CNT) TABLESPACE X_INDEXES;
jgarry, thanks for the answer, the only problem that I have clone of the database (32 bit) with same CBO parameters
where it does not behave this way:
explain plan for2 select s.offset_cnt
3 from reported_summary s
4 where s.offset_cnt>0;
PLAN_TABLE_OUTPUT
Plan hash value: 2359470296
| Id | Operation | Name | Cost (%CPU)|
| 0 | SELECT STATEMENT | | 9 (0)|
|* 1 | INDEX RANGE SCAN| S_NUI01 | 9 (0)|
Predicate Information (identified by operation id):
1 - access("s"."OFFSET_CNT">0)
explain plan for2 select s.offset_cnt,s.ru_id
3 from reported_summary s
4 where s.offset_cnt>0;
PLAN_TABLE_OUTPUT
Plan hash value: 3732627180
| Id | Operation | Name | Cost (%CPU)|
| 0 | SELECT STATEMENT | | 67 (0)|
| 1 | TABLE ACCESS BY INDEX ROWID| REPORTED_SUMMARY | 67 (0)|
|* 2 | INDEX RANGE SCAN | S_NUI01 | 9 (0)|
Predicate Information (identified by operation id):
2 - access("s"."OFFSET_CNT">0)
Thanks again.

Best Practice for "flag" columns

Hello Experts!
This is more of a design/architecture/performance? question. Suggestions welcome, of course!
Oracle Server version 11.2.0.3
Scenario:
I plan to use one of my columns in the table as a "flag" field. Meaning, this field will have some type of static value. Our document management system leverages Oracle as the database and provides a front-end user interface for the user. When the user searches for their documents, the records will be displayed accordingly. If the user wants to "delete" the document, they would change the flag field from "No" to "Yes". The custom search that we would have already built for them would have a hidden where clause of "where column_flag = 'No'" to show the records that they searched and of course if they change the flag to "Yes" (to be deleted), it will no longer appear in their search results. The field would be a string datatype.
My Second Thought:
Same scenario above, except for 1 change. Instead of the "No" and "Yes" value, I would replace the value to a blank/null value and "Delete". Essentially, the drop-down value would change from "No" and "Yes" values to a blank value and "Delete". Visually, this would make more sense to our users when they see the data and for when they decide to choose to "delete" a document. At this point, the where clause would of course change to "where column_flag is null".
My Question:
From a performance perspective, which is a better practice?
Is it faster to query the database with "where column_flag = 'No'" / "where column_flag = 'Yes'" OR "where column_flag is null" / "where column_flag = 'Delete'"?
Should I even create an index on the column? (I would assume no because it would serve no benefit because of the static values).
Keep in mind that I will have millions and millions of records/rows in the table. I am striving for the best possible answer in terms of long-term performance. In the past, I have had users complain about "slow searches" and that is what I would like to help prevent from happening.
Thanks in advance for all your help and suggestions!

rp0428 wrote:
When the user searches for their documents, the records will be displayed accordingly. If the user wants to "delete" the document, they would change the flag field from "No" to "Yes". The custom search that we would have already built for them would have a hidden where clause of "where column_flag = 'No'" to show the records that they searched and of course if they change the flag to "Yes" (to be deleted), it will no longer appear in their search results.
Why? If you user wants to delete the document just delete it. Then you don't need ANY of the mucking around.
What is it you aren't telling us? Why would you just mark it instead of actually delete it?
The reason is because of senior upper management policy, where they do not want to actually delete/remove the record from the system. They only want to "delete"/hide the record from the search result from the user if they choose to "delete" a document. Part of this is to help prevent a restore from happening. Lets say a user accidentally deletes (an actual real delete) of a document and the next day/week/month/year she says, "oops, I made a mistake can you undo it?" The answer is yes, but then we now lose more documents/data just to restore that 1 document because of all the other documents that were added to the system the previous day. Make sense? However, in this scenario, if they just mark it for "deletion" and they think that they are actually deleting it, but what it's really doing is hiding it from their search results, then if she comes and says, "oops, I made a mistake can you undo it?" We can simply change the flag/property from "Yes" to "No" (or from one to the other basically, and assuming she provides us with all the necessary information for the document for us to find it) and then we don't have to actually perform a system "restore" any thing.
rp0428 wrote:
Is it faster to query the database with "where column_flag = 'No'" / "where column_flag = 'Yes'" OR "where column_flag is null" / "where column_flag = 'Delete'"?
Not enough info to know. Query performance will depend on the query, all of the data needed for the query, indexes available and other things.
The query will always have this hidden where clause of "where column_flag = 'No'" in the front-end UI for the user. The UI for the user basically has pertinent information for them to search off of for a particular set of documents with the additional where clause to search for documents that are not marked for deletion. For instance, HR would have searchable fields, like FirstName, LastName, EmployeeID, SocialSecurityNumber, etc.. the user has the ability to search for any of these fields and when they populate any of these fields and clicks search, it goes out and retrieves all of the documents that are found based on the criteria entered. The additional where clause of "where column_flag = 'No'" will always be added somewhere in the where clause of the SQL query because we only want to display documents that are not marked for deletion. We have no reason nor should they have any reason to see documents that they "deleted" because to them they will think that they are actually deleting/removing the document from the system when they change the flag/property.
rp0428 wrote:
Should I even create an index on the column? (I would assume no because it would serve no benefit because of the static values).
Not enough info to know. If there are 5 million YES values and 5 million NO values what purpose would an index serve? As SB said if NULL means YES but nulls aren't indexed then what purpose would an index server?
The most likely case where an index on that one column would be used is if the mosts commonly queried value is rare. More likely the actual table row will need to be obtained from the table and the filter of Y/N can be applied then.
For a simple flag just use VARCHAR2(1). There is no need to store YES or NO; that just increase the amount of storage needed for no benefit.
The majority of the documents would not be marked for deletion or would not have "No". Lets say if I had 10 million records/rows in the database, I would probably say that less than 1%? would probably be marked for deletion by the users, which is 1 million documents or less. Realistically, I would probably even go further to say that out of 10 million, I could only imagine that maybe ~50,000 would only be marked for deletion? The number is not very high and would be uncommon for the users to consistently delete documents.

Finding source database table/column name for a column in a view

Hi i need to be able to identify the original database table/column name for a column in a view.
e.g. say i have a view like this
create v1 as select a.name fname, b.name bname, c.name cname,......
from u1.names a, u2.names b. u3.names c
where .....
Now I want to find out that the database table/column name for the fname, bname and cname columns in the view v1, which in this instance is u1.name.name, u2.names.name, u3.names.name.
But i need to be able to do it for any view. Short of parsing the SQL is there an easy way of doing this?
Now obviusly I can't do this for virtual columns but I will know my column is not virtual as it has an index on it.

But i need to be able to do it for any view. Short of
parsing the SQL is there an easy way of doing this?No, parsing the SQL is the only way. Good luck it is not something I would want to attempt.

How to get the index of a h:column element?

Hi!
I'd like to know how to get the index of a <h:column> element.
Here is the code of what I'm trying to do:
<h:column>
     <a:commandLink
          value="#{familyAction.familyDocsByPrj}"
          action="#{homeAction.search(ROW_INDEX)}"
          reRender="rightAppPanel" />
</h:column>When clicking a row, I'd like to make a "search" depending on the selected row.
Does anybode know how to do that?
Thanks a lot :)

Thanks a lot for all your answers! :)
I finally got to do something with my little knowledge =P
I created a new class containing all the data needed for the dataTable (including a "String id").
And that's what I get:
<h:column>
     <a:commandLink
          value="#{familyAction.familyDocsByPrj.name}"
          action="#{homeAction.search(familyAction.familydocsByPrj.id)}"
          reRender="rightAppPanel" />
</h:column>

Normal Indexes created for Primary/Unique Keys in Oracle8/8i

I remeber prior to Oracle8, when we create a Primary/Unique Key constraints, an unique index will be created by default. But I am noticing now in 8/8i when we create either Primary or Unique key, only normal/simple index is created. We are not able to override this normal index either by dropping and recreating the index alone. I believe it would be pretty much better in case of performance if we have a unique index for this columns. Can anybody help why is it changed so in 8/8i??
Thanks,
R. M.

Dear Rob,
since your answer was helpful and since it was the only one I will grant you full points on that.
Thanks again for your input. In case other developers should look this thread up being confronted
with the same kind of problem, here is how we solved it:
We added an artificial primary key (a number of type NUMC 8) to the table which is supposed to
include the structure. This key alone takes care of the uniqueness of eacht entry.
All the others fields that we want to have available for a fast direct access, including the ones
from the included structure, are put together in a secondary index.
best regards
Andreas

How to get AdvancedDataGrid ItemRenderer for hierarchal column to work

I have an advanced datagrid with 5 columns one of which is a
hierarchal (tree). This datagrid is populated by the following:
MyAdvancedDataGrid.dataProvider = new
HierarchicalData(MyXMLListCollection);
The first column is the tree and im trying to do a item
renderer on it in actionscript... I have the following code:
MyTreeColumn.itemRenderer = new ClassFactory(MyRenderer);
In order to get the icon and label to show up i need to
extend AdvancedDataGridGroupItemRenderer as such:
MyRenderer extends AdvancedDataGridGroupItemRenderer
This has one problem... the updateDisplayList function only
gets fired for the children not the root rows... So if you set the
this.icon.visible = false... the icon will show up on the root rows
but the most bottom children rows the icon will become invisible...
Now ... if i extend the class with
AdvancedDataGridItemRenderer then the tree functionality gets
overwritten and it doesn't function the way that I need it to..
Ultimately I'm trying to shift the default label over so I can add
another icon to the right of the the default icon so the user can
click on it... Any help from anyone would be greatly
appreciated...

var column:AdvancedDataGridColumn;
column = new AdvancedDataGridColumn("HeaderName");
column.width = 10;
column.dataField = "@label";
column.itemRenderer = new ClassFactory(MyItemRenderer);
MyAdvancedDataGrid.columns = [column];
code for MyItemRenderer:
package {
import mx.controls.dataGridClasses.DataGridListData;
import mx.controls.listClasses.BaseListData;
import mx.controls.listClasses.IDropInListItemRenderer;
import mx.controls.listClasses.IListItemRenderer;
import mx.core.UIComponent;
public class MyItemRenderer extends UIComponent implements
IDropInListItemRenderer, IListItemRenderer {
//class variables
private var _ListData:DataGridListData = null;
private var _data:Object = null;
public function PE_BaseRenderer() {
super();
public function get listData():BaseListData {
return _ListData;
public function set listData(value:BaseListData):void {
_ListData = value as DataGridListData;
public function get data():Object {
return _data;
public function set data(value:Object):void {
_data = value;
invalidateProperties ();
override protected function createChildren():void {
super.createChildren();
//create you children here
} //end of class declaration
} //end of package declaration
Within this renderer you can create whatever type of children
you want for the datagrid column

How is it possible to use Index Seek for LIKE %search-string% case?

Hello,
I have the following SP:
CREATE PROCEDURE dbo.USP_SAMPLE_PROCEDURE(@Beginning nvarchar(15))
AS
SELECT * FROM HumanResources.Employee
WHERE NationalIDNumber LIKE @Beginning + N'%';
GO
If I run the sp first time with param: N'94', then the following plan is generated and added to the cache:
SQL Server "sniffs" the input value (94) when compiling the query. So for this param using Index Seek for AK_Employee_NationalIDNumber index will be the best option. On the other hand, the query plan should be generic enough to be able to handle
any values specified in the @Beginning param.
If I call the sp with @Beginning =N'%94':
EXEC dbo.USP_SAMPLE_PROCEDURE N'%94'
I see the same execution plan as above. The question is how is it possible to reuse this execution plan in this case? To be more precise, how
Index Seek can be used in case LIKE %search-string% case. I expected that
ONLY Index Scan operation can be used here.
Alexey

The key is that the index seek operator includes both seek (greater than and less than) and a predicate (LIKE). With the leading wildcard, the seek is effectively returning all rows just like a scan and the filter returns only rows matching
the LIKE expression.
Do you want to say that in case of leading wildcard, expressions Expr1007 and Expr1008 (see image below) calculated such a way that
Seek Predicates retrieve all rows from the index. And only
Predicate does the real job by taking only rows matching the Like expression? If this is the case, then it explains how
Index Seek can be used to resolve such queries: LIKE N'%94'.
However, it leads me to another question: Since
Index Seek in
this particular case scans
all the rows, what is the difference between
Index Seek and Index Scan?
According to
MSDN:
The Index Seek operator uses the seeking ability of indexes to retrieve rows from a nonclustered index.
The storage engine uses the index to process
only those rows that satisfy the SEEK:() predicate. It optionally may include a WHERE:() predicate, which the storage engine will evaluate against all rows that satisfy the SEEK:() predicate (it does not use the indexes to do this).
The Index Scan operator retrieves
all rows from the nonclustered index specified in the Argument column. If an optional WHERE:() predicate appears in the Argument column, only those rows that satisfy the predicate are returned.
It seems like Index Scan is a special case of Index Seek,
which means that when we see Index Seek in the execution plan, it does NOT mean that storage engine does NOT scan all rows. Right?
Alexey

Index firing for a column

Similar Messages

Maybe you are looking for