2018/06/04

Using  compression in a not exist filter is a very bad idea.

A few days ago  ; one of customers had a problem about daily running jobs.

When they rebuilt some tables ; a huge performance problem occured. We had to spent some diagonastcs and analyzes to find out the root cause .

There a a not exist fileter ;
and the tablspace was default compression enabled ;  when the filter table was re-created it was in a compressed format ; which caused .




-----------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                         | Name             | Rows  | Bytes | Cost (%CPU)| Time     |    TQ  |IN-OUT| PQ Distrib |
-----------------------------------------------------------------------------------------------------------------------------------
|   0 | INSERT STATEMENT                  |                  |       |       |   150M(100)|          |        |      |            |
|   1 |  LOAD AS SELECT                   |                  |       |       |            |          |        |      |            |
|   2 |   FILTER                          |                  |       |       |            |          |        |      |            |
|   3 |    PX COORDINATOR                 |                  |       |       |            |          |        |      |            |
|   4 |     PX SEND QC (RANDOM)           | :TQ10002         |  9409K|   511M|   628  (35)| 00:00:04 |  Q1,02 | P->S | QC (RAND)  |
|   5 |      HASH JOIN BUFFERED           |                  |  9409K|   511M|   628  (35)| 00:00:04 |  Q1,02 | PCWP |            |
|   6 |       PX RECEIVE                  |                  |  8984K|   171M|   142  (63)| 00:00:01 |  Q1,02 | PCWP |            |
|   7 |        PX SEND HASH               | :TQ10000         |  8984K|   171M|   142  (63)| 00:00:01 |  Q1,00 | P->P | HASH       |
|   8 |         PX BLOCK ITERATOR         |                  |  8984K|   171M|   142  (63)| 00:00:01 |  Q1,00 | PCWC |            |
|   9 |          TABLE ACCESS STORAGE FULL| ACCTSTATUS       |  8984K|   171M|   142  (63)| 00:00:01 |  Q1,00 | PCWP |            |
|  10 |       PX RECEIVE                  |                  |  7383K|   260M|   471  (25)| 00:00:03 |  Q1,02 | PCWP |            |
|  11 |        PX SEND HASH               | :TQ10001         |  7383K|   260M|   471  (25)| 00:00:03 |  Q1,01 | P->P | HASH       |
|  12 |         PX BLOCK ITERATOR         |                  |  7383K|   260M|   471  (25)| 00:00:03 |  Q1,01 | PCWC |            |
|  13 |          TABLE ACCESS STORAGE FULL| KEY_SUBSCRIPTION |  7383K|   260M|   471  (25)| 00:00:03 |  Q1,01 | PCWP |            |
|  14 |    TABLE ACCESS BY INDEX ROWID    | SUBSCR_STATUS    |     1 |    35 |    16   (0)| 00:00:01 |        |      |            |
|  15 |     INDEX RANGE SCAN              | PK_SUBSCR_STATUS |    13 |       |     3   (0)| 00:00:01 |        |      |            |


-----------------------------------------------------------------------------------------------------------------------------------

on the left one ;   1M record is searhed just in 71 seconds;
on the right one; 185k
 record is searhed  in 125 seconds ; and counting on

roughtly  10X worse. 


No comments:

Post a Comment