Mohamed Houri’s Oracle Notes

December 25, 2013

Tuning via row source execution plan

Filed under: explain plan — hourim @ 4:25 pm

Browsing over draft blogs I have not finished and forget to come back to, I found one article about a sub optimal execution plan of a query suffering terrible performance problem. If my memory is still servicing me well, I think this execution plan has been sent to me by one of my ex-colleague with whom I have had several e-mail exchange and have supplied him with a proposition. I was waiting for his answer before publishing this blog article. It seems he has never answered since then :-). Anyway, I thought it is, nevertheless, worth sharing with you at least my starting investigations on this query performance problem.

This is the execution plan with row source statistics showing the estimations done by the CBO based on available statistics

 ----------------------------------------------------------------------------------------------------------------------
 | Id  | Operation                            | Name                          | Starts | E-Rows | A-Rows |   A-Time   |
 ----------------------------------------------------------------------------------------------------------------------
 |   1 |  SORT UNIQUE                         |                               |      1 |      1 |    109 |00:00:35.22 | --> 35sec
 |   2 |   WINDOW BUFFER                      |                               |      1 |      1 |    109 |00:00:35.22 |
 |*  3 |    FILTER                            |                               |      1 |        |    109 |00:00:35.21 |
 |   4 |     SORT GROUP BY                    |                               |      1 |      1 |    760 |00:00:35.21 |
 |*  5 |      FILTER                          |                               |      1 |        |   9938 |00:00:35.00 |
 |   6 |       NESTED LOOPS OUTER             |                               |      1 |      1 |  14546 |00:00:34.93 |
 |   7 |        NESTED LOOPS                  |                               |      1 |      1 |  14546 |00:00:33.58 |
 |   8 |         NESTED LOOPS OUTER           |                               |      1 |      1 |    952 |00:00:00.52 |
 |   9 |          NESTED LOOPS OUTER          |                               |      1 |      1 |    952 |00:00:00.31 |
 |* 10 |           TABLE ACCESS BY INDEX ROWID| XXX_TABLE1                    |      1 |      2 |    760 |00:00:00.09 |
 |* 11 |            INDEX RANGE SCAN          | XXX_TAB1_IND_1                |      1 |      2 |   8766 |00:00:00.02 |
 |  12 |           TABLE ACCESS BY INDEX ROWID| XXX_TABLE2                    |    760 |      1 |    248 |00:00:00.22 |
 |* 13 |            INDEX RANGE SCAN          | XXX_TAB2_IND_FK               |    760 |      4 |    248 |00:00:00.19 |
 |* 14 |          TABLE ACCESS BY INDEX ROWID | XXX_TABLE3                    |    952 |      1 |    952 |00:00:00.20 |
 |* 15 |           INDEX RANGE SCAN           | XXX_TABLE3_PK                 |    952 |      1 |   4833 |00:00:00.12 |
 |* 16 |         TABLE ACCESS BY INDEX ROWID  | XXX_TABLE1                    |    952 |      1 |  14546 |00:00:33.04 |
 |* 17 |          INDEX RANGE SCAN            | XXX_TAB1_IND_1                |    952 |      1 |   7980K|00:00:00.05 |
 |* 18 |        TABLE ACCESS BY INDEX ROWID   | XXX_TABLE5                    |  14546 |      1 |     15 |00:00:01.29 |
 |* 19 |         INDEX RANGE SCAN             | XXX_TAB5_IND_1                |  14546 |      1 |     15 |00:00:01.21 |
 |  20 |       SORT AGGREGATE                 |                               |      3 |      1 |      3 |00:00:00.01 |
 |* 21 |        TABLE ACCESS BY INDEX ROWID   | XXX_TABLE2                    |      3 |      1 |     11 |00:00:00.01 |
 |* 22 |         INDEX RANGE SCAN             | XXX_TAB2_IND_FK               |      3 |      4 |     11 |00:00:00.01 |
 ----------------------------------------------------------------------------------------------------------------------
 

where I have deliberately omitted the predicate part for clarity (I will show it in a moment).

Have you already pointed out the most time consuming operation?

If not yet then look at the different operations (from 1 to 22) and isolate  the most consuming child/parent operation  by looking at the A-Time column.

Have you already found it?

Here it is together with its predicate part:

 ----------------------------------------------------------------------------------------------------------------------
 | Id  | Operation                            | Name                          | Starts | E-Rows | A-Rows |   A-Time   |
 ----------------------------------------------------------------------------------------------------------------------
 |* 16 |         TABLE ACCESS BY INDEX ROWID  | XXX_TABLE1                    |    952 |      1 |  14546 |00:00:33.04 |
 |* 17 |          INDEX RANGE SCAN            | XXX_TAB1_IND_1                |    952 |      1 |   7980K|00:00:00.05 |
 ----------------------------------------------------------------------------------------------------------------------
 16 - filter(("TAB1_2"."N1">=20000 AND "TAB1"."XXX_ID"="TAB1_2"."XXX_ID"))
 17 - access("TAB1_2"."DATH">SYSDATE@!-.041666 AND "TAB1"."DAT_TRD"="TAB1_2"."DAT_TRD" AND "TAB1_2"."DATH" IS NOT NULL)
      filter("TAB1"."DAT_TRD"="TAB1_2"."DAT_TRD")
 

This is how to proceed generally to identify the most consuming operation in an execution plan. By the way, this is also my method of tuning a query not performing in a client acceptable response time i.e. (a) I get the row source execution plan including the estimations and actuals (b) and I then scrutinize or scan this plan looking through the A-Time column for the most consuming operation. Thanks to this method, I end up in the majority of cases (there are of course exceptions) by isolating the operation on which attention should be concentrated.

So back to my execution plan. The most consuming operation being found, what observations can be done? Well, without bothering yourself trying to understand the above filter operation, you can, however, obviously point out two major facts

  1. Looking at the high number (7980,000) of rowid the index range scan operation 17 has supplied its parent operation 16 and finally to the very small number of those row-rowids (14,546) that survived the filter operation number 16, I end up by realizing that this is an enormous waste of time and resource spent discarding rows that would have not been sent to the table access operation at all.
  2. Looking at the estimations done by the CBO and the actuals rows generated I ended up by realizing that there is obviously a statistics problem my colleague should look at very urgently.
  3. Almost all E-Rows of the above execution plan has a cardinality equal to one. This particular cardinality is typically suspicious. It is a clear indication of the absence of fresh statistics

Whether the most consuming operation is due to the not up-to-date statistics or to an imprecise index (XXX_TAB1_IND_1) depends on my colleague answer that will probably not come at all.

Bottom line: when you have to tune a query you can proceed using the following steps:

  1. get the row source execution plan from memory using dbms_xplan package that includes Estimations and Actuals, then track the most consuming operation and the accuracy of statistics (table and columns statistics)
  2. get a SQL monitoring report and analyze it if you have a license for
  3. use Tanel Poder snapper
  4. use Carlos Sierra SQLTXPLAN
  5. etc…

1 Comment »

  1. 5. Read Christian Antognini’s book
    6. Read Jonathan Lewis’s book :-)

    Few months ago,I met a similar statistics issue. The problem was due to some tables used as temporary tables i.e they are feeded only during application processing and are empty when the statistic gathering job is launched. As a result the CBO thinks that these tables are empty (0 is rounded to 1 in the execution plan) and that any query on these tables will return 0 rows.

    Comment by ahmed aangour — December 27, 2013 @ 3:04 pm | Reply


RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

The Rubric Theme. Create a free website or blog at WordPress.com.

Mohamed Houri’s Oracle Notes

Qui se conçoit bien s’énonce clairement

Oracle Database 11g

Oracle Database

Raheel's Blog

Things I have learnt as Oracle DBA

Coskan's Approach to Oracle

What I learned about Oracle

So Many Oracle Manuals, So Little Time

“Books to the ceiling, Books to the sky, My pile of books is a mile high. How I love them! How I need them! I'll have a long beard by the time I read them”—Lobel, Arnold. Whiskers and Rhymes. William Morrow & Co, 1988.

EU Careers info

Your career in the European Union

Oracle SQL Tuning Tools and Tips

SQL Tuning, eAdam, eDB360, SQLT, SQLHC

Oracle Scratchpad

Just another Oracle weblog

Tanel Poder's blog: Responsible data management

Linux, Oracle, Exadata and Hadoop.

OraStory

Dominic Brooks on Oracle Performance, Tuning, Data Quality & Sensible Design ... (Now with added Sets Appeal)

Follow

Get every new post delivered to your Inbox.

Join 81 other followers

%d bloggers like this: