0

I saw the unusable index slow down the performance of a query by more than 4 hrs...

In general, will unusable index will slow down the query? In which conditions it will improve the performance.

Thanks.

Kathir
  • 2,733
  • 12
  • 39
  • 67
  • Your question requires a somewhat long answer. Regarding select queries, having an index which is not being used should not really slow anything down. As for inserts and updates, if you have a dead-weight index, Oracle would have to maintain that index, and this could degrade performance. – Tim Biegeleisen Nov 04 '19 at 14:04
  • What sort of table is this? Specifically is it partitioned? What are the characteristics of the unusable index? Also, what is the nature of this sluggish query? How long would you expect it to run? – APC Nov 04 '19 at 14:09
  • Both the select and delete causes the performance issue. However selects takes minutes and delete query takes several hours when the index is unusable. Now the problem only with delete as it takes hrs.. – Kathir Nov 04 '19 at 14:13
  • Please, post the SQL and [execution plan](https://stackoverflow.com/a/34975420/4808122) - without details everything can either *slow down* or *speed up*. Be consistent, if *you saw* that *unusable index slow down the performance of a query*; do not ask: *will unusable index will slow down the query?*. – Marmite Bomber Nov 04 '19 at 18:02

1 Answers1

1

When an index, or some partitions or subpartitions of an index, are created UNUSABLE, no segment is allocated for the unusable object. The unusable index or index partition consumes no space in the database.

For more documentation you can refer below link :

https://docs.oracle.com/en/database/oracle/oracle-database/12.2/sqlrf/CREATE-INDEX.html#GUID-1F89BBC0-825F-4215-AF71-7588E31D8BFE

You can check query optimizer plan or query execution plan to check the performance of the query.

Having many indexes on a table degrades DML performance because the database must also update the indexes. Indexes can be usable (default) or unusable. An unusable index is not maintained by DML operations and is ignored by the optimizer. An unusable index can improve the performance of bulk loads.

I can see you can try below two scenarios:

  1)  Deleting from large table without having index

Drop indexes - Dropping indexes before a mass delete and rebuilding them afterwards can improve delete performance because each individual delete would have to remove itself from the index, causing slowdowns. Oracle removes index entries without re-balancing the index tree (a "logical delete"), but this is still time-consuming, especially if you have lots of indexes on the target table

   2) Parallel Delete

You can also check your delete query performance using parallel dml:

ALTER SESSION ENABLE PARALLEL DML;
DELETE /*+ parallel(table, 20) */
  FROM  table

You can then decide from the above two scenario which one works faster for your delete query

Andrew
  • 3,632
  • 24
  • 64
  • 113
  • Do you convey it will slow down or improve? – Kathir Nov 04 '19 at 14:06
  • depends on the scenario and your query statistics..for this i have edited my answer where you can choose query optimizer plan or query execution plan to check the performance of the query and depends on the situation you can see the impact of index – Andrew Nov 04 '19 at 14:07
  • The explain plan or execution plan says CPU is more ...I told the DB administrator and causes the issue..However they want a proof that it because of the unusable index. How to prove them it is due to bad index. – Kathir Nov 04 '19 at 14:09
  • the best way is to run the query and check the execution plan/query running time with unusable index and then remove or disable this unusable index and run the query again and check the performance...compare this two scenario and u will find your result – Andrew Nov 04 '19 at 14:12
  • Both the select and delete causes the performance issue. However selects takes minutes and delete query takes several hours when the index is unusable. Now the problem only with delete as it takes hrs....when the index is usable, the query is fast...Do we need to improve the query or fix the index is the question from DBA. – Kathir Nov 04 '19 at 14:14
  • edited the answer...fix the index ...if your table contains huge data then u can use parallelization to improve performance but in your case i would suggest to fix the index as you mentioned the delete runs quiet faster so instead of changing query u can fix the index – Andrew Nov 04 '19 at 14:23
  • edited answer again where you can also check performance using parallel delete and then decide which one works faster either fixing index or parallel delete...i see you have this two options – Andrew Nov 04 '19 at 14:30
  • Thanks a lot, Andrew. I will check on this. – Kathir Nov 04 '19 at 14:33
  • @Kathir depending on a low index selectivity a optimizer most likely simply ignore the index as random disk i/o lookups generally ~4 - 10 ms delay per lookup on HDD are much lower then streaming the complete table if alot of records match your filter.. You indeed should get more performance in those cases when using parallel options.. By the way index lookups on SSD are also not faster then simply stream that complete table most RMDS optimizesr have hardcoded delay values for disk I/O wait time and do not take in account for disk hardware for the calculations.. – Raymond Nijland Nov 04 '19 at 14:40
  • 1
    @RaymondNijland We are using HDD and thanks for your input as well. I will check and get back to you with the result. – Kathir Nov 04 '19 at 14:41
  • 1
    *"i didnn't understand and can you please explain in detail "* @Kathir if i would explain that in even more detail how a SQL optimizer works in general i could write a book about it as that topic is that wide – Raymond Nijland Nov 04 '19 at 14:41