Performance-to-many problem (using the model of the FAQ)

After reading "HOW TO: post a request for tuning SQL - model showing statement" I gathered:

I have included some general information at the bottom of the post

The following SQL statement has been identified as a bad performance. It takes ~ 160 seconds to run, but similar (indicated below first statement) SQL statements run in ~ 1 second.

SQL taking 160 seconds:

SELECT
a.*
FROM
table_a a
INNER JOIN table_a_b ab ON a.id = ab.media_fk
WHERE
ab.channel_fk IN (7, 1);

SQL in ~ 1 second or less

...
ab.channel_fk IN (7);

Or:

...
ab.channel_fk IN (6, 9, 170, 89);

The purpose of the SQL is to return lines from table_a associated table_b (not in SQL) through the junction table table_a_b.

The version of the database is 10.2.0.4.0

These are the parameters relevant for the optimizer:

show parameter optimizer;

NAME                                               TYPE        VALUE
-------------------------------------------------- ----------- -----------------------------------------
optimizer_dynamic_sampling                         integer     2
optimizer_features_enable                          string      10.2.0.4
optimizer_index_caching                            integer     0
optimizer_index_cost_adj                           integer     100
optimizer_mode                                     string      ALL_ROWS
optimizer_secure_view_merging                      boolean     TRUE

show parameter db_file_multi;

NAME                                               TYPE        VALUE
-------------------------------------------------- ----------- -----------------------------------------
db_file_multiblock_read_count                      integer     16

show parameter db_block_size;

NAME                                               TYPE        VALUE
-------------------------------------------------- ----------- -----------------------------------------
db_file_multiblock_read_count                      integer     16

select sname, pname, pval1, pval2 from sys.aux_stats$;

SNAME                          PNAME                          PVAL1                  PVAL2
------------------------------ ------------------------------ ---------------------- -------------------
SYSSTATS_INFO                  STATUS                                                COMPLETED
SYSSTATS_INFO                  DSTART                                                07-18-2006 23:19
SYSSTATS_INFO                  DSTOP                                                 07-25-2006 23:19
SYSSTATS_INFO                  FLAGS                          0
SYSSTATS_MAIN                  SREADTIM                       5.918
SYSSTATS_MAIN                  MREADTIM                       7.889
SYSSTATS_MAIN                  CPUSPEED                       1383
SYSSTATS_MAIN                  MBRC                           8
SYSSTATS_MAIN                  MAXTHR                         1457152
SYSSTATS_MAIN                  SLAVETHR                       -1

Here is the output of the EXPLAIN PLAN of:

PLAN_TABLE_OUTPUT
Plan hash value: 3781163428

----------------------------------------------------------------------------------------------------
| Id  | Operation             | Name               | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT      |                    |  1352K|   771M|       | 60042   (3)| 00:05:56 |
|*  1 |  HASH JOIN            |                    |  1352K|   771M|    27M| 60042   (3)| 00:05:56 |
|*  2 |   INDEX FAST FULL SCAN| SYS_IOT_TOP_316310 |  1352K|    11M|       |  1816   (4)| 00:00:11 |
|   3 |   TABLE ACCESS FULL   | TABLE_A            |  2190K|  1230M|       | 32357   (4)| 00:03:12 |
----------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - access(""AB"".""MEDIA_FK""=""A"".""ID"")
   2 - filter(""AB"".""CHANNEL_FK""=1 OR ""AB"".""CHANNEL_FK""=7)

Note
-----
   - 'PLAN_TABLE' is old version

For reference, the EXPLAIN PLAN when using

...
ab.channel_fk IN (6, 9, 170, 89);

that runs in ~ 1 second is:

PLAN_TABLE_OUTPUT
Plan hash value: 794334170

----------------------------------------------------------------------------------------
| Id  | Operation          | Name      | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |           |   143K|    81M|       | 58982   (3)| 00:05:50 |
|*  1 |  HASH JOIN         |           |   143K|    81M|  2952K| 58982   (3)| 00:05:50 |
|   2 |   INLIST ITERATOR  |           |       |       |       |            |          |
|*  3 |    INDEX RANGE SCAN| C_M_INDEX |   143K|  1262K|       |  1264   (1)| 00:00:08 |
|   4 |   TABLE ACCESS FULL| TABLE_A   |  2190K|  1230M|       | 32357   (4)| 00:03:12 |
----------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - access(""AB"".""MEDIA_FK""=""A"".""ID"")
   3 - access(""AB"".""CHANNEL_FK""=6 OR ""AB"".""CHANNEL_FK""=9 OR
              ""AB"".""CHANNEL_FK""=89 OR ""AB"".""CHANNEL_FK""=170)

Note
-----
   - 'PLAN_TABLE' is old version

Here is the output of SQL * Plus AUTOTRACE, including CALENDAR information:

SQL> set autotrace traceonly arraysize 100;
SQL> SELECT
  2  a.*
  3  FROM
  4  table_a a
  5  INNER JOIN table_a_b ab ON a.id = ab.media_fk
  6  WHERE
  7  ab.channel_fk IN (7, 1);

1336148 rows selected.


Execution Plan
----------------------------------------------------------
Plan hash value: 3781163428
----------------------------------------------------------------------------------------------------
| Id  | Operation             | Name               | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT      |                    |  1352K|   771M|       | 60042   (3)| 00:05:56 |
|*  1 |  HASH JOIN            |                    |  1352K|   771M|    27M| 60042   (3)| 00:05:56 |
|*  2 |   INDEX FAST FULL SCAN| SYS_IOT_TOP_316310 |  1352K|    11M|       |  1816   (4)| 00:00:11 |
|   3 |   TABLE ACCESS FULL   | TABLE_A            |  2190K|  1230M|       | 32357   (4)| 00:03:12 |
----------------------------------------------------------------------------------------------------


Predicate Information (identified by operation id):
---------------------------------------------------

   1 - access("AB"."MEDIA_FK"="A"."ID")
   2 - filter("AB"."CHANNEL_FK"=1 OR "AB"."CHANNEL_FK"=7)

Note
-----
   - 'PLAN_TABLE' is old version


Statistics
----------------------------------------------------------
      10586  recursive calls
          0  db block gets
     200457  consistent gets
     408343  physical reads
          0  redo size
  498740848  bytes sent via SQL*Net to client
     147371  bytes received via SQL*Net from client
      13363  SQL*Net roundtrips to/from client
         49  sorts (memory)
          0  sorts (disk)
    1336148  rows processed

The TKPROF output for that statement looks like the following:

TKPROF: Release 10.2.0.4.0 - Production on Mon Oct 1 12:23:21 2012

Copyright (c) 1982, 2007, Oracle.  All rights reserved.

Trace file: ..._ora_4896.trc
Sort options: default

********************************************************************************
count    = number of times OCI procedure was executed
cpu      = cpu time in seconds executing
elapsed  = elapsed time in seconds executing
disk     = number of physical reads of buffers from disk
query    = number of buffers gotten for consistent read
current  = number of buffers gotten in current mode (usually for update)
rows     = number of rows processed by the fetch or execute call
********************************************************************************

ALTER SYSTEM SET TIMED_STATISTICS = TRUE


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.03          0          0          0           0
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        2      0.00       0.03          0          0          0           0

Misses in library cache during parse: 0
Parsing user id: 21
********************************************************************************

SELECT
a.*
FROM
table_a a
INNER JOIN table_a_b ab ON a.id = ab.media_fk
WHERE
ab.channel_fk IN (7, 1)

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.01       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        2     27.23     163.57     179906     198394          0          16
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        4     27.25     163.58     179906     198394          0          16

Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 21



********************************************************************************

OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        2      0.01       0.00          0          0          0           0
Execute      2      0.00       0.03          0          0          0           0
Fetch        2     27.23     163.57     179906     198394          0          16
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        6     27.25     163.62     179906     198394          0          16

Misses in library cache during parse: 1


OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        0      0.00       0.00          0          0          0           0
Execute      0      0.00       0.00          0          0          0           0
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        0      0.00       0.00          0          0          0           0

Misses in library cache during parse: 0

    2  user  SQL statements in session.
    0  internal SQL statements in session.
    2  SQL statements in session.
********************************************************************************
Trace file: ..._ora_4896.trc
Trace file compatibility: 10.01.00
Sort options: default

       1  session in tracefile.
       2  user  SQL statements in trace file.
       0  internal SQL statements in trace file.
       2  SQL statements in trace file.
       2  unique SQL statements in trace file.
      46  lines in trace file.
     187  elapsed seconds in trace file.

DBMS_XPLAN. Output DISPLAY_CURSOR:

select * from table(dbms_xplan.display_cursor('474frsqbc1n4d', null, 'ALLSTATS LAST'));

PLAN_TABLE_OUTPUT
SQL_ID  474frsqbc1n4d, child number 0
-------------------------------------
SELECT /*+ gather_plan_statistics */ c.* FROM table_a c INNER JOIN table_a_b ab ON c.id = ab.media_fk WHERE ab.channel_fk IN (7, 1)

Plan hash value: 3781163428

---------------------------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation             | Name               | Starts | E-Rows | A-Rows |   A-Time   | Buffers | Reads  | Writes |  OMem |  1Mem | Used-Mem |
---------------------------------------------------------------------------------------------------------------------------------------------------
|*  1 |  HASH JOIN            |                    |      1 |   1352K|   1050 |00:00:40.93 |     198K|    182K|    209K|    29M|  5266K| 3320K (1)|
|*  2 |   INDEX FAST FULL SCAN| SYS_IOT_TOP_316310 |      1 |   1352K|   1336K|00:00:01.34 |   10874 |      0 |      0 |       |       |          |
|   3 |   TABLE ACCESS FULL   | TABLE_A            |      1 |   2190K|   2267K|00:02:45.56 |     187K|    182K|      0 |       |       |          |
---------------------------------------------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - access(""AB"".""MEDIA_FK""=""C"".""ID"")
   2 - filter((""AB"".""CHANNEL_FK""=1 OR ""AB"".""CHANNEL_FK""=7))

Thank you for reading I'm waiting for suggestions to improve the performance of this statement.

-----

H3. Backgroud

There are many years my company made decided to maintain many-to-many relationships in our database using pipe delimited fields. An example of field value:

'|ABC|XYZ|VTR|DVD|'

Each delimited value refers to a unique "short" code TABLE_B (there is also a real digital foreign key to TABLE_B, which is what I use in the junction table). We are regularly using these columns with the next SQL style:

...
WHERE
INSTR(pipedcolumn, '|ABC|') > 0
OR INSTR(pipedcolumn, '|XYZ|' > 0
...

Appropriate indexes have been created over the years to make this process as soon a possible.

We now have an opportunity to correct some of these errors of design and implementation of junction tables to replace the current field. Before that, we have decided to take a copy of a database to a client with the largest set of records and test. I created a new junction table:

TABLE_A_B DDL:

    CREATE TABLE TABLE_A_B (
        media_fk NUMBER,
        channel_fk NUMBER,
        PRIMARY KEY (media_fk, channel_fk),
        FOREIGN KEY (media_fk) REFERENCES TABLE_A (ID),
        FOREIGN KEY (channel_fk) REFERENCES TABLE_B (ID)
    ) ORGANIZATION INDEX COMPRESS;

    CREATE INDEX C_M_INDEX ON TABLE_A_B (channel_fk, media_fk) COMPRESS;

And the analysis on a pipe delimited field, populated by this new table.

I then compared the performance of the following SQL:

SELECT
a.*
FROM
table_a a
INNER JOIN table_a_b ab ON a.id = ab.media_fk
WHERE
ab.channel_fk IN (x, y, n); -- Can be Many Minutes

--vs.

SELECT
a.*
FROM
table_a a
WHERE
INSTR(OWNERS,'|x|')    >0
OR INSTR(OWNERS,'|y|')    >0
OR INSTR(OWNERS,'|n|')    >0; -- About 1 second seemingly regardless

When x, y, n are values that occur less frequently in the TABLE_A_B.CHANNEL_FK performance are comparable. However once the frequency of x, y, n increases, performance suffers. Here is a summary of the data CHANNEL_FK in TABLE_A_B:

--SQL For Summary Data
SELECT channel_fk, count(channel_fk) FROM table_a_b GROUP BY channel_fk ORDER BY COUNT(channel_fk) DESC;

CHANNEL_FK             COUNT(CHANNEL_FK)
---------------------- ----------------------
7                      780741
1                      555407
2                      422493
3                      189493
169                    144663
9                      79457
6                      53051
171                    28401
170                    19857
49                     12603
...

I noticed that whenever I use any combination of values that occur over approximately 800 000 times (i.e. IN (7, 1) = 780741 + 555407 = 1336148) then I get performance problems.

I find it very difficult to accept that the old pipe delimited fields are a better solution (without taking into account any other than this search criterion!).

Thank you for reading this far. I really look forward to suggestions on how to improve the performance of this statement.

Published by: user1950227 on October 1, 2012 12:06
Table of link renamed in DDL.

davebcast wrote:

The following SQL statement has been identified as a bad performance. It takes ~ 160 seconds to run, but similar (indicated below first statement) SQL statements run in ~ 1 second.

Keep in mind that the enforcement timeframe has elapsed is a poor metric to use for benchmarking of SQL. The reason is that the same workload does not mean that the same elapsed execution time.

The workload for example shows a block of 1000 readings. There will be a difference marked by this workload reading data of the slow physical disks, or making this workload by reading data from memory in memory cache. And if it happens to be in memory or on disk is a kind of "random" thing (depends on many environment and factors of execution).

Thus, rather than measure the elapsed time and use it to compare, rather compare actual workloads. A workload of 500 block reading is faster and better than a block of 1000 DSL - despite the fact that a point of elapsed time can show the 500 read being slow (e/s physical) block a block of 1000 to read (e/s logic).

Tags: Database

Performance-to-many problem (using the model of the FAQ)

Similar Questions

Maybe you are looking for