Oracle中如何查看索引是否被使用

Question

SELECT * 
FROM   (SELECT TEMP.*, 
               ROWNUM RNUM 
        FROM   (SELECT entry_guid 
                FROM   alertdevtest.ENTRY 
                WHERE  Upper(alert_name) = 'alertname' 
                       AND user_guid = 'AlertProductClientTest' 
                       AND product_code = '-101' 
                       AND status_code != 13) TEMP 
        WHERE  ROWNUM <= 2500) 
WHERE  rnum >= 0; 

SELECT * 
FROM   (SELECT TEMP.*, 
               ROWNUM RNUM 
        FROM   (SELECT entry_guid 
                FROM   alertdevtest.ENTRY 
                WHERE  Upper(alert_name) = 'alertname' 
                       AND user_guid = 'AlertProductClientTest' 
                       AND product_code = '-101' 
                       AND status_code != 13 
                       AND product_view IN ( 'PView' )) TEMP 
        WHERE  ROWNUM <= 2500) 
WHERE  rnum >= 0; 

Am running above queries and seeing performance degradation in the second query compare to the first one. The only difference is being the additional filter AND PRODUCT_VIEW IN ('PView') in second query. But it has index on that column. Please let me know what can be the reason for performance degradation and how can I check whether index being used or not? Am using Oracle SQL developer and tried checking explain plan but couldn't get much details.

Answer 1

In Oracle SQL Developer, when you have SQL in the worksheet, there is a button "Explain Plan", you can also hit F10. After you execute Explain plan, it will show in the bottom view of SQL Developer. There is a column "OBJECT_NAME", it will tell you what index is being used. For example, in a query I just ran, in the left column (OPERATION) it shows "SELECT STATEMENT" first, then SORT (AGGREGATE) and then INDEX (RANGE SCAN) and then in the OBJECT_NAME column it shows TICKER_IDX1, which is the name of an index on my table.

So you can see via the OBJECT_NAME column what indexes are being used.

It can happen that the Oracle Cost Based Optimizer chooses a sub-optimal execution plan. Many times updating statistics will solve the issue. Other choices are to add additional indexes, in other words a multi-column index. You can hint a SQL statement, but that is rarely needed. Also, it's possible to rewrite the query.

Answer 2

The EXPLAIN PLAN statement is the best way to check the execution plan. Graphical execution plans considered harmful.

EXPLAIN PLAN has many benefits over common graphical representation of execution plans:

1. Simple, Standard Format DBMS_XPLAN.DISPLAY works in any environment and produces output that every Oracle professional is familiar with. Anyone with access to Oracle can reproduce the issue, and everyone can discuss the issue with the same standard names. SQL Developer may be free but most developers and DBAs do not use it.
2. Easy to Process Output The output is easy to save and share - store the output in a table, copy the text into Notepad, etc. It's also much easier to compare using a program like WinMerge. Large queries may produce hundreds of lines in the execution plan, using a diff utility can make tuning much easier. For programming tasks text is better than a picture.
3. Includes Important Sections For some bizarre reason IDEs never include the Note section in execution plans. That section often includes important information. In your example, it's possible that a DBA fixed a SQL Plan Baseline for one of the queries but not the other. Without the Notes section we'll just have to guess if there's something weird going on.
4. More Accurate Some tools use a separate session to generate graphical execution plans and produce wrong results. For example, plans may be very different without alter session enable parallel dml; . This doesn't appear to be an issue with SQL Developer but I've seen it with other programs.
5. More Powerful DBMS_XPLAN can be scripted and has many powerful features, like format => '+outline' , dbms_xplan.display_awr , etc.

Below is a simple example of EXPLAIN PLAN . This plan is fine but it does have a huge red flag that most graphical execution plans would not show. The last line, dynamic statistics used: dynamic sampling (level=2) implies that one of the tables is missing optimizer statistics.

drop table test1;
create table test1(a number);
explain plan for insert into test1 select * from test1;
select * from table(dbms_xplan.display);

Plan hash value: 4122059633

----------------------------------------------------------------------------------
| Id  | Operation                | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------
|   0 | INSERT STATEMENT         |       |     1 |    13 |     2   (0)| 00:00:01 |
|   1 |  LOAD TABLE CONVENTIONAL | TEST1 |       |       |            |          |
|   2 |   TABLE ACCESS FULL      | TEST1 |     1 |    13 |     2   (0)| 00:00:01 |
----------------------------------------------------------------------------------

Note
-----
   - dynamic statistics used: dynamic sampling (level=2)

For a quick check it's easier to hit F10, F5, ctrl+E, or whatever the shortcut is in your specific IDE. But for serious analysis that will be shared with others, always use EXPLAIN PLAN .

Answer 3

Best thing to understand reason of poor performance is to get SQL*Trace. There are several ways to enable tracing http://docs.oracle.com/cd/B19306_01/server.102/b14211/sqltrace.htm#g33356 For example

EXECUTE DBMS_SESSION.SESSION_TRACE_ENABLE(waits => TRUE, binds => TRUE);

You need to enable trace, run these queries, fetch data to the end (because usually most of work Oracle perform during fetch), close session (cursor need to be closed to make execution plan with time statistics appear in trace file).
Then you should go to dump folder on database server, get trace file, user tkprof utility to convert it to more readable way, find these queries inside, enjoy :).
Benefits of SQL Trace is that it gives real plan that was used during SQL execution, and it gives very precise time,reads,gets, consistent reads, cpu statistics for each step of the plan (unfortunately I don't know any other tool that can do this).
Disadvantage is that you need privilege to start tracing and you need access to dump folder (or you need to ask DBA to execute query with tracing and server admin to get file).
More rough option is to enable monitoring for this SQL (for example by /*+ monitor */ hint) and use DBMS_SQLTUNE.REPORT_SQL_MONITOR http://docs.oracle.com/cd/B28359_01/appdev.111/b28419/d_sqltun.htm#CHDBHIBG - it may generate pretty HTML with stats for each step of execution plan (like in SQL Trace)
Advantage is ease of use (you don't need to have access to server folder to use this).
Disadvantage is that grain of statistics in this case is usually 1 second, so it is useful only for long-running queries (10 seconds and more).
If you need just check if index was used during SQL execution, you may query v$sql_plan view and v$sql, v$sql_monitor views to find appropriate plan.

Answer 4

You can Run this query to check usage of index.

select ius.* , 
(select  sum(trunc(bytes / 1024 / 1024/ 1024  ,2)) 
 from dba_segments sgm 
 where  sgm.owner = ius.OWNER
   and sgm.segment_name = ius.name ) Used_Space 
   ,ind.DISTINCT_KEYS, ind.Total_Ind_Rows , ind.Total_Leaf_Block,
   trunc((ius.bucket_0_access_count / nullif(ius.total_access_count,0)) *100 ,2)Access_0_PCT,
   trunc((ius.bucket_1_access_count / nullif(ius.total_access_count,0)) *100 ,2) Access_1_PCT,
   trunc((ius.bucket_2_10_access_count / nullif(ius.total_access_count,0)) *100,2) Access_2_10_PCT,
   trunc((ius.bucket_11_100_access_count / nullif(ius.total_access_count,0)) *100,2) Access_11_100_PCT,
   trunc((ius.bucket_101_1000_access_count / nullif(ius.total_access_count,0)) *100,2) Access_101_1000_PCT,
   trunc((ius.bucket_1000_plus_access_count / nullif(ius.total_access_count,0)) *100,2) Access_1000_plus_PCT
from dba_index_usage ius , 
 (select ind.OWNER,ind.INDEX_NAME,ind.DISTINCT_KEYS, sum(ind.num_rows)Total_Ind_Rows,sum(ind.LEAF_BLOCKS)Total_Leaf_Block,
         trunc(sum(ind.num_rows)/nullif(sum(ind.LEAF_BLOCKS),0),2) RowsInBlocks
  from all_indexes ind 
  where ind.owner = &SchemaName
  group by ind.OWNER,ind.INDEX_NAME,ind.DISTINCT_KEYS
  ) ind
where ius.owner = &SchemaName 
  and ius.name = ind.INDEX_NAME

Also, you can add v$sql_plan and dba_hist_sql_plan to filter unused indexes.

and not exists 
      (select 'x'
       from v$sql_plan pln
       where  pln.OPERATION = 'INDEX'
        and pln.OBJECT_OWNER = ius.owner
        and pln.OBJECT_NAME = ius.name)