Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
Топик располагается на нескольких страницах: 1 2 3 4 5      [все]
 Проседание времени выполнения запроса  [new]
Ryuu
Member [заблокирован]

Откуда:
Сообщений: 545
Доброго времени суток.

Хотелось бы задать следующий вопрос. Но, прежде всего:

Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production 0
PL/SQL Release 12.1.0.2.0 - Production 0
"CORE 12.1.0.2.0 Production" 0
TNS for Linux: Version 12.1.0.2.0 - Production 0
NLSRTL Version 12.1.0.2.0 - Production 0


Итак. Есть некий запрос, который еще две недели назад работал хорошо. Потом что-то случилось. Лично я грешу на наших админов, что ковырнули настройки БД, в чем они конечно же не признаются. Как результат, запрос стал работать на несколько порядков дольше, а именно, время работы увеличилось с двух минут до двух часов.

Само проседание начинается, когда связывается два "куска", несколько отличные от оригиналов, но полностью удовлетворяют условиям тестирование, и которые в отдельности работают быстро, то есть исправно.

автор
SELECT
  tobj.*
FROM
  sysdba.tc_obj2link tobj,
  sysdba.tp_zag tpz,
  sysdba.tp_zag_d tpzd,
  sysdba.tp_zag_f tpzf,
  sysdba.tp_zag_s tpzs,
  sysdba.tp_zag_s tpzss,
  sysdba.articles art,
  zebra.zebra_all_sect zas0,
  sysdba.articles art2,
  zebra.zebra_all_sect zas
WHERE
  tobj.f_obj_type     = 3
AND tobj.f_obj_key    = tpz.f_key
AND tobj.f_obj_key    = tpzd.f_parentkey
AND tpz.f_status      = 0
AND tpzd.f_entity     = 'Мкдо'
AND tpzs.F_PARENTKEY  = tpz.F_KEY
AND tpzs.F_ROW        = 1
AND tpzs.F1          IS NOT NULL
AND tpzss.F_PARENTKEY = tpz.F_KEY
AND tpzss.F_ROW       = 8
AND tpzss.F4         IS NOT NULL
AND tpzf.f_parentkey  = tpz.f_key
AND tpzf.f_row        = 1
AND art.art_id        = tobj.f_art_id
AND art.purchased    IS NULL
AND zas0.kod_odi_p    = tpzd.f_value
AND zas0.kod_odi_p   IS NOT NULL
AND art2.ART_ID       = zas0.ART_ID
AND zas.art_id        = tobj.f_art_id
AND zas.kod_odi      IS NOT NULL
AND zas0.tech_char LIKE '%2590%';


автор
-- Информация по входимости.
SELECT
  lvl,
  root_part_aid,
  root_proj_aid,
  proj_aid,
  count_pc,
  ROUND(SUM(
  (
    SELECT
      exp(SUM(ln(regexp_substr(paths,'[^*]+',1,level))))
    FROM
      dual
      CONNECT BY instr( NULLIF(paths, '0') , '*', 1, level-1 ) > 0
  )
  ) over (partition BY root_proj_aid, proj_aid) , 10 ) AS paths
FROM
  (
    SELECT
      lvl,
      ISLEAF,
      root_part_aid,
      root_proj_aid,
      part_aid,
      proj_aid,
      count_pc ,
      (
        CASE
          WHEN
            (
              instr(paths, '*0') != 0
            )
          OR
            (
              SUBSTR(paths, 1, 2) = '0*'
            )
          OR
            (
              paths = '0'
            )
          THEN NULL
          ELSE paths
        END) AS paths
    FROM
      (
        SELECT
          level                    AS lvl,
          CONNECT_BY_ISLEAF        AS ISLEAF,
          CONNECT_BY_ROOT part_aid AS root_part_aid,
          CONNECT_BY_ROOT proj_aid AS root_proj_aid,
          part_aid,
          proj_aid,
          count_pc ,
          ltrim(SYS_CONNECT_BY_PATH(count_pc, '*'),'*') AS paths
        FROM
          (
            SELECT
              part_aid,
              proj_aid,
              count_pc,
              vargrp,
              varnum
            FROM
              sysdba.pc pc,
              zebra.zebra_all_sect zas,
              sysdba.articles art
            WHERE
              pc.part_aid       = zas.art_id
            AND zas.otr_konstr IS NOT NULL
            AND SN NOT         IN (1, 148)
            AND pc.proj_aid     =art.art_id
            AND pc.proj_ver_id  = art.art_ver_id
          )
          START WITH part_aid      IS NOT NULL
        AND vargrp                  = 0
        AND varnum                  = 0
          CONNECT BY PRIOR proj_aid = part_aid
      )
  )
WHERE
  ISLEAF = 1;


Собственно при их соединении и начинаются проблемы.

автор
SELECT
  tobj.*
FROM
  sysdba.tc_obj2link tobj,
  sysdba.tp_zag tpz,
  sysdba.tp_zag_d tpzd,
  sysdba.tp_zag_f tpzf,
  sysdba.tp_zag_s tpzs,
  sysdba.tp_zag_s tpzss,
  sysdba.articles art,
  zebra.zebra_all_sect zas0,
  sysdba.articles art2,
  zebra.zebra_all_sect zas,
  (-- Информация по входимости.
    SELECT
      lvl,
      root_part_aid,
      root_proj_aid,
      proj_aid,
      count_pc,
      ROUND(SUM(
      (
        SELECT
          exp(SUM(ln(regexp_substr(paths,'[^*]+',1,level))))
        FROM
          dual
          CONNECT BY instr( NULLIF(paths, '0') , '*', 1, level-1 ) > 0
      )
      ) over (partition BY root_proj_aid, proj_aid) , 10 ) AS paths
    FROM
      (
        SELECT
          lvl,
          ISLEAF,
          root_part_aid,
          root_proj_aid,
          part_aid,
          proj_aid,
          count_pc ,
          (
            CASE
              WHEN
                (
                  instr(paths, '*0') != 0
                )
              OR
                (
                  SUBSTR(paths, 1, 2) = '0*'
                )
              OR
                (
                  paths = '0'
                )
              THEN NULL
              ELSE paths
            END) AS paths
        FROM
          (
            SELECT
              level                    AS lvl,
              CONNECT_BY_ISLEAF        AS ISLEAF,
              CONNECT_BY_ROOT part_aid AS root_part_aid,
              CONNECT_BY_ROOT proj_aid AS root_proj_aid,
              part_aid,
              proj_aid,
              count_pc ,
              ltrim(SYS_CONNECT_BY_PATH(count_pc, '*'),'*') AS paths
            FROM
              (
                SELECT
                  part_aid,
                  proj_aid,
                  count_pc,
                  vargrp,
                  varnum
                FROM
                  sysdba.pc pc,
                  zebra.zebra_all_sect zas,
                  sysdba.articles art
                WHERE
                  pc.part_aid       = zas.art_id
                AND zas.otr_konstr IS NOT NULL
                AND SN NOT         IN (1, 148)
                AND pc.proj_aid     = art.art_id
                AND pc.proj_ver_id  = art.art_ver_id
              )
              START WITH part_aid      IS NOT NULL
            AND vargrp                  = 0
            AND varnum                  = 0
              CONNECT BY PRIOR proj_aid = part_aid
          )
      )
    WHERE
      ISLEAF = 1
  )
  my_pc
WHERE
  tobj.f_obj_type       = 3
AND tobj.f_obj_key      = tpz.f_key
AND tobj.f_obj_key      = tpzd.f_parentkey
AND tpz.f_status        = 0
AND tpzd.f_entity       = 'Мкдо'
AND tpzs.F_PARENTKEY    = tpz.F_KEY
AND tpzs.F_ROW          = 1
AND tpzs.F1            IS NOT NULL
AND tpzss.F_PARENTKEY   = tpz.F_KEY
AND tpzss.F_ROW         = 8
AND tpzss.F4           IS NOT NULL
AND tpzf.f_parentkey    = tpz.f_key
AND tpzf.f_row          = 1
AND art.art_id          = tobj.f_art_id
AND art.purchased      IS NULL
AND zas0.kod_odi_p      = tpzd.f_value
AND zas0.kod_odi_p     IS NOT NULL
AND art2.ART_ID         = zas0.ART_ID
AND zas.art_id          = tobj.f_art_id
AND zas.kod_odi        IS NOT NULL
AND my_pc.root_part_aid = tobj.f_art_id
AND zas0.tech_char LIKE '%2590%';


Хочу заметить, что если в связки я заменю my_pc.root_part_aid на my_pc.root_proj_aid, где уникальность значительно меньше, следовательно, как и самих данных, всё работает, как и раньше, то есть быстро. А потому я считаю (разумеется, могу и ошибаться), что всё дело в кол-ве данных. К слову, сами поля part_aid и proj_aid индексные, и если подставлять связку с proj_aid и part_aid они ведут себя точно также, как и root_proj_aid и root_part_aid соответственно.

Подскажите, пожалуйста, какие настройки БД отвечают за подобное, или другие альтернативные методы решения проблемы.
3 дек 18, 14:01    [21752034]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
Ryuu
Member [заблокирован]

Откуда:
Сообщений: 545
Прошу прощение за
автор
, перепутал со спойлером. Поторопился. :(
3 дек 18, 14:02    [21752039]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 46356

Ryuu
другие альтернативные методы решения проблемы.

Проанализировать план не предлагать?..

Posted via ActualForum NNTP Server 1.5

3 дек 18, 14:04    [21752041]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
Ryuu
Member [заблокирован]

Откуда:
Сообщений: 545
Dimitry Sibiryakov, а что толку? Есть таблица а, есть пвседотаблица б, при их соединении оптимизатор уходит в запой. Как план в этом деле может помочь? Или я чего-то не знаю / не понимаю? Если же речь идёт о трассировке и о том, откуда и куда именно валяться данные, то боюсь, что здесь я бессилен, у меня этого нет.
3 дек 18, 14:08    [21752049]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 46356

Ryuu
Как план в этом деле может помочь?

Он покажет чем именно сервер занят два часа.

Posted via ActualForum NNTP Server 1.5

3 дек 18, 14:11    [21752053]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
Ryuu
Member [заблокирован]

Откуда:
Сообщений: 545
Dimitry Sibiryakov, а, это. Есть такое у меня.
SORT ORDER BY | | 205G| 403T| 509T| 13G (1)|142:25:29 | 30M| 1999K| 27M (0)|
3 дек 18, 14:13    [21752055]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
Ryuu
Member [заблокирован]

Откуда:
Сообщений: 545
+ explain plan
| Id  | Operation                                                    | Name                   | E-Rows |E-Bytes|E-Temp | Cost (%CPU)| E-Time   |  OMem |  1Mem | Used-Mem | Used-Tmp|
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                                             |                        |        |       |       |    13G(100)|          |       |       |          |         |
|   1 |  SORT AGGREGATE                                              |                        |      1 |       |       |            |          |       |       |          |         |
|   2 |   CONNECT BY WITHOUT FILTERING                               |                        |        |       |       |            |          |  2048 |  2048 | 2048  (0)|         |
|   3 |    FAST DUAL                                                 |                        |      1 |       |       |     2   (0)| 00:00:01 |       |       |          |         |
|   4 |  SORT ORDER BY                                               |                        |    205G|   403T|   509T|    13G  (1)|142:25:29 |    30M|  1999K|   27M (0)|         |
|   5 |   HASH UNIQUE                                                |                        |    205G|   403T|   509T|  6563M  (1)| 71:13:15 |    41M|  3851K|          |         |
|*  6 |    HASH JOIN RIGHT OUTER                                     |                        |    205G|   403T|       |  1518K (66)| 00:01:00 |  6271K|  1761K| 3615K (0)|         |
|   7 |     VIEW                                                     |                        |  54924 |  1072K|       | 16926   (2)| 00:00:01 |       |       |          |         |
|   8 |      HASH UNIQUE                                             |                        |  54924 |  5310K|  6112K| 16926   (2)| 00:00:01 |  7690K|  3198K| 5554K (0)|         |
|*  9 |       HASH JOIN                                              |                        |  54924 |  5310K|  7280K| 15895   (2)| 00:00:01 |    16M|  3954K|   20M (0)|         |
|* 10 |        FILTER                                                |                        |        |       |       |            |          |       |       |          |         |
|* 11 |         HASH JOIN RIGHT OUTER                                |                        |  85683 |  6275K|       | 10877   (2)| 00:00:01 |  2091K|  1761K| 2346K (0)|         |
|* 12 |          TABLE ACCESS BY INDEX ROWID                         | TP_ZAG_D               |  17910 |   472K|       |  3250   (1)| 00:00:01 |       |       |          |         |
|* 13 |           INDEX RANGE SCAN                                   | TP_ZAG_D_F_ENTITY      |  18608 |       |       |    45   (0)| 00:00:01 |       |       |          |         |
|* 14 |          HASH JOIN                                           |                        |    128K|  6001K|  2280K|  7626   (2)| 00:00:01 |  6448K|  2024K| 8783K (0)|         |
|  15 |           VIEW                                               |                        |  52888 |  1652K|       |  5396   (2)| 00:00:01 |       |       |          |         |
|* 16 |            FILTER                                            |                        |        |       |       |            |          |       |       |          |         |
|* 17 |             FILTER                                           |                        |        |       |       |            |          |       |       |          |         |
|* 18 |              HASH JOIN OUTER                                 |                        |  52888 |  1910K|  3184K|  5396   (2)| 00:00:01 |  7894K|  2748K| 8797K (0)|         |
|* 19 |               TABLE ACCESS FULL                              | TP_ZAG                 |    148K|  1445K|       |   533   (2)| 00:00:01 |       |       |          |         |
|* 20 |               TABLE ACCESS FULL                              | TP_ZAG_D               |    109K|  2892K|       |  4769   (2)| 00:00:01 |       |       |          |         |
|* 21 |           TABLE ACCESS FULL                                  | TC_OBJ2LINK            |   1299K|    19M|       |  1750   (2)| 00:00:01 |       |       |          |         |
|* 22 |        TABLE ACCESS FULL                                     | TP_ZAG_D               |    344K|  8067K|       |  4775   (2)| 00:00:01 |       |       |          |         |
|  23 |     VIEW                                                     |                        |   3914M|  7812G|       |   527K  (4)| 00:00:21 |       |       |          |         |
|* 24 |      HASH JOIN OUTER                                         |                        |   3914M|    12T|   699M|   527K  (4)| 00:00:21 |    25M|  4046K|   27M (0)|         |
|  25 |       VIEW                                                   |                        |    527K|   693M|       | 47155   (1)| 00:00:02 |       |       |          |         |
|  26 |        HASH UNIQUE                                           |                        |    527K|   156M|   171M| 47155   (1)| 00:00:02 |    53M|  3790K|          |         |
|  27 |         NESTED LOOPS                                         |                        |    527K|   156M|       | 17822   (2)| 00:00:01 |       |       |          |         |
|  28 |          NESTED LOOPS                                        |                        |     42 | 11676 |       | 17780   (2)| 00:00:01 |       |       |          |         |
|  29 |           NESTED LOOPS                                       |                        |     42 | 11382 |       | 17696   (2)| 00:00:01 |       |       |          |         |
|  30 |            NESTED LOOPS                                      |                        |     34 |  8772 |       | 17594   (2)| 00:00:01 |       |       |          |         |
|  31 |             NESTED LOOPS                                     |                        |     28 |  6832 |       | 17510   (2)| 00:00:01 |       |       |          |         |
|  32 |              NESTED LOOPS OUTER                              |                        |     28 |  6160 |       | 17454   (2)| 00:00:01 |       |       |          |         |
|* 33 |               HASH JOIN                                      |                        |     26 |  5018 |       | 17376   (2)| 00:00:01 |  2047M|    95M|   79M (1)|      16M|
|  34 |                NESTED LOOPS                                  |                        |        |       |       |            |          |       |       |          |         |
|  35 |                 NESTED LOOPS                                 |                        |   1414 |   233K|       | 15940   (1)| 00:00:01 |       |       |          |         |
|* 36 |                  HASH JOIN                                   |                        |    921 |   130K|       | 13488   (1)| 00:00:01 |  2047M|    50M|   79M (1)|         |
|* 37 |                   HASH JOIN                                  |                        |   1174 |   139K|       | 11599   (1)| 00:00:01 |    11G|   297M|   49M (1)|      42M|
|  38 |                    JOIN FILTER CREATE                        | :BF0000                |   4829 |   476K|       |  7815   (2)| 00:00:01 |       |       |          |         |
|* 39 |                     HASH JOIN                                |                        |   4829 |   476K|       |  7815   (2)| 00:00:01 |   114M|  9197K|  137M (0)|         |
|* 40 |                      HASH JOIN                               |                        |    394 | 33490 |       |  6059   (1)| 00:00:01 |    55M|  6638K|   76M (0)|         |
|  41 |                       VIEW                                   |                        |   3364 |   157K|       |  4677   (2)| 00:00:01 |       |       |          |         |
|  42 |                        WINDOW SORT                           |                        |   3364 |  6790K|  8984K|  4677   (2)| 00:00:01 |    48M|  2458K|   43M (0)|         |
|  43 |                         VIEW                                 |                        |   3364 |  6790K|       |  3468   (2)| 00:00:01 |       |       |          |         |
|* 44 |                          FILTER                              |                        |        |       |       |            |          |       |       |          |         |
|* 45 | -WITH                     CONNECT BY NO FILTERING WITH START |                        |        |       |       |            |          |    18M|  1590K|   16M (0)|         |
|* 46 |                            HASH JOIN                         |                        |   1086 | 96654 |       |  3467   (2)| 00:00:01 |    39M|  4580K|   48M (0)|         |
|* 47 |                             HASH JOIN                        |                        |   1086 | 87966 |       |  1953   (2)| 00:00:01 |    12M|  2487K|   13M (0)|         |
|  48 |                              VIEW                            | ZEBRA_ALL_SECT         |    600 | 34800 |       |  1380   (1)| 00:00:01 |       |       |          |         |
|  49 |                               UNION-ALL                      |                        |        |       |       |            |          |       |       |          |         |
|* 50 |                                FILTER                        |                        |        |       |       |            |          |       |       |          |         |
|  51 |                                 INDEX FULL SCAN              | SECT_0_PRIMARY         |      1 |    13 |       |     0   (0)|          |       |       |          |         |
|* 52 |                                FILTER                        |                        |        |       |       |            |          |       |       |          |         |
|* 53 |                                 TABLE ACCESS FULL            | SECT_1                 |  18097 |   123K|       |   192   (4)| 00:00:01 |       |       |          |         |
|* 54 |                                FILTER                        |                        |        |       |       |            |          |       |       |          |         |
|  55 |                                 INDEX FAST FULL SCAN         | SECT_107_PRIMARY       |  18599 | 92995 |       |     7   (0)| 00:00:01 |       |       |          |         |
|* 56 |                                FILTER                        |                        |        |       |       |            |          |       |       |          |         |
|  57 |                                 INDEX FAST FULL SCAN         | SECT_131_PRIMARY       |  21537 |   105K|       |     8   (0)| 00:00:01 |       |       |          |         |
|* 58 |                                FILTER                        |                        |        |       |       |            |          |       |       |          |         |
|  59 |                                 INDEX FAST FULL SCAN         | SECT_148_PRIMARY       |  12415 | 62075 |       |     5   (0)| 00:00:01 |       |       |          |         |
|* 60 |                                FILTER                        |                        |        |       |       |            |          |       |       |          |         |
|  61 |                                 INDEX FULL SCAN              | SECT_191_PRIMARY       |    140 |   700 |       |     1   (0)| 00:00:01 |       |       |          |         |
|* 62 |                                FILTER                        |                        |        |       |       |            |          |       |       |          |         |
|  63 |                                 INDEX FULL SCAN              | SECT_2_PRIMARY         |      1 |     5 |       |     1   (0)| 00:00:01 |       |       |          |         |
|* 64 |                                FILTER                        |                        |        |       |       |            |          |       |       |          |         |
|* 65 |                                 TABLE ACCESS FULL            | SECT_3                 |  31868 |  1618K|       |   196   (1)| 00:00:01 |       |       |          |         |
|* 66 |                                FILTER                        |                        |        |       |       |            |          |       |       |          |         |
|* 67 |                                 TABLE ACCESS FULL            | SECT_4                 |  65628 |  3268K|       |   545   (1)| 00:00:01 |       |       |          |         |
|* 68 |                                FILTER                        |                        |        |       |       |            |          |       |       |          |         |
|* 69 |                                 TABLE ACCESS FULL            | SECT_5                 |  11856 |   509K|       |   119   (1)| 00:00:01 |       |       |          |         |
|* 70 |                                FILTER                        |                        |        |       |       |            |          |       |       |          |         |
|* 71 |                                 TABLE ACCESS FULL            | SECT_53                |     94 |  5734 |       |     3   (0)| 00:00:01 |       |       |          |         |
|* 72 |                                FILTER                        |                        |        |       |       |            |          |       |       |          |         |
|  73 |                                 INDEX FAST FULL SCAN         | SECT_55_PRIMARY        |   1748 |  8740 |       |     2   (0)| 00:00:01 |       |       |          |         |
|* 74 |                                FILTER                        |                        |        |       |       |            |          |       |       |          |         |
|  75 |                                 INDEX FAST FULL SCAN         | SECT_56_PRIMARY        |   2012 | 10060 |       |     2   (0)| 00:00:01 |       |       |          |         |
|* 76 |                                FILTER                        |                        |        |       |       |            |          |       |       |          |         |
|  77 |                                 INDEX FAST FULL SCAN         | SECT_57_PRIMARY        |   1449 |  7245 |       |     2   (0)| 00:00:01 |       |       |          |         |
|* 78 |                                FILTER                        |                        |        |       |       |            |          |       |       |          |         |
|* 79 |                                 TABLE ACCESS FULL            | SECT_6                 |    415 |  2905 |       |   102   (2)| 00:00:01 |       |       |          |         |
|* 80 |                                FILTER                        |                        |        |       |       |            |          |       |       |          |         |
|  81 |                                 INDEX FULL SCAN              | SECT_63_PRIMARY        |    331 |  1655 |       |     1   (0)| 00:00:01 |       |       |          |         |
|* 82 |                                FILTER                        |                        |        |       |       |            |          |       |       |          |         |
|  83 |                                 INDEX FAST FULL SCAN         | SECT_7_PRIMARY         |  50623 |   247K|       |    17   (0)| 00:00:01 |       |       |          |         |
|* 84 |                                FILTER                        |                        |        |       |       |            |          |       |       |          |         |
|* 85 |                                 TABLE ACCESS FULL            | SECT_701               |   1668 | 95076 |       |    18   (0)| 00:00:01 |       |       |          |         |
|* 86 |                                FILTER                        |                        |        |       |       |            |          |       |       |          |         |
|* 87 |                                 TABLE ACCESS FULL            | SECT_8                 |    894 | 43806 |       |     8   (0)| 00:00:01 |       |       |          |         |
|* 88 |                                FILTER                        |                        |        |       |       |            |          |       |       |          |         |
|  89 |                                 INDEX FULL SCAN              | SECT_80_PRIMARY        |     98 |   490 |       |     1   (0)| 00:00:01 |       |       |          |         |
|* 90 |                                FILTER                        |                        |        |       |       |            |          |       |       |          |         |
|* 91 |                                 TABLE ACCESS FULL            | SECT_99                |    526 | 35768 |       |     6   (0)| 00:00:01 |       |       |          |         |
|  92 |                              TABLE ACCESS FULL               | PC                     |    411K|  9252K|       |   570   (3)| 00:00:01 |       |       |          |         |
|  93 |                             TABLE ACCESS FULL                | ARTICLES               |    691K|  5404K|       |  1511   (2)| 00:00:01 |       |       |          |         |
|  94 |                       VIEW                                   | ZEBRA_ALL_SECT         |  26654 |   963K|       |  1382   (1)| 00:00:01 |       |       |          |         |
|  95 |                        UNION-ALL                             |                        |        |       |       |            |          |       |       |          |         |
|* 96 |                         FILTER                               |                        |        |       |       |            |          |       |       |          |         |
|  97 |                          TABLE ACCESS FULL                   | SECT_0                 |      1 |   404 |       |     2   (0)| 00:00:01 |       |       |          |         |
|* 98 |                         FILTER                               |                        |        |       |       |            |          |       |       |          |         |
|  99 |                          TABLE ACCESS FULL                   | SECT_1                 |    226K|  4875K|       |   189   (3)| 00:00:01 |       |       |          |         |
|*100 |                         FILTER                               |                        |        |       |       |            |          |       |       |          |         |
| 101 |                          TABLE ACCESS FULL                   | SECT_107               |  18599 |   908K|       |    34   (0)| 00:00:01 |       |       |          |         |
|*102 |                         FILTER                               |                        |        |       |       |            |          |       |       |          |         |
| 103 |                          TABLE ACCESS FULL                   | SECT_131               |  21537 |   841K|       |    35   (0)| 00:00:01 |       |       |          |         |
|*104 |                         FILTER                               |                        |        |       |       |            |          |       |       |          |         |
| 105 |                          TABLE ACCESS FULL                   | SECT_148               |  12415 |   569K|       |    37   (0)| 00:00:01 |       |       |          |         |
|*106 |                         FILTER                               |                        |        |       |       |            |          |       |       |          |         |
| 107 |                          TABLE ACCESS FULL                   | SECT_191               |    140 |  1260 |       |     2   (0)| 00:00:01 |       |       |          |         |
|*108 |                         FILTER                               |                        |        |       |       |            |          |       |       |          |         |
| 109 |                          TABLE ACCESS FULL                   | SECT_2                 |      1 |    27 |       |     2   (0)| 00:00:01 |       |       |          |         |
|*110 |                         FILTER                               |                        |        |       |       |            |          |       |       |          |         |
| 111 |                          TABLE ACCESS FULL                   | SECT_3                 |  34340 |  1676K|       |   196   (1)| 00:00:01 |       |       |          |         |
|*112 |                         FILTER                               |                        |        |       |       |            |          |       |       |          |         |
| 113 |                          TABLE ACCESS FULL                   | SECT_4                 |  83424 |  3829K|       |   544   (1)| 00:00:01 |       |       |          |         |
|*114 |                         FILTER                               |                        |        |       |       |            |          |       |       |          |         |
| 115 |                          TABLE ACCESS FULL                   | SECT_5                 |  21443 |  1151K|       |   119   (1)| 00:00:01 |       |       |          |         |
|*116 |                         FILTER                               |                        |        |       |       |            |          |       |       |          |         |
| 117 |                          TABLE ACCESS FULL                   | SECT_53                |     97 |  5723 |       |     3   (0)| 00:00:01 |       |       |          |         |
|*118 |                         FILTER                               |                        |        |       |       |            |          |       |       |          |         |
| 119 |                          TABLE ACCESS FULL                   | SECT_55                |   1748 | 73416 |       |     4   (0)| 00:00:01 |       |       |          |         |
|*120 |                         FILTER                               |                        |        |       |       |            |          |       |       |          |         |
| 121 |                          TABLE ACCESS FULL                   | SECT_56                |   2012 |   110K|       |     6   (0)| 00:00:01 |       |       |          |         |
|*122 |                         FILTER                               |                        |        |       |       |            |          |       |       |          |         |
| 123 |                          TABLE ACCESS FULL                   | SECT_57                |   1449 | 91287 |       |     7   (0)| 00:00:01 |       |       |          |         |
|*124 |                         FILTER                               |                        |        |       |       |            |          |       |       |          |         |
| 125 |                          TABLE ACCESS FULL                   | SECT_6                 |  54627 |  2774K|       |   101   (1)| 00:00:01 |       |       |          |         |
|*126 |                         FILTER                               |                        |        |       |       |            |          |       |       |          |         |
| 127 |                          TABLE ACCESS FULL                   | SECT_63                |    331 | 13240 |       |     2   (0)| 00:00:01 |       |       |          |         |
|*128 |                         FILTER                               |                        |        |       |       |            |          |       |       |          |         |
| 129 |                          TABLE ACCESS FULL                   | SECT_7                 |  50623 |  2471K|       |    98   (2)| 00:00:01 |       |       |          |         |
|*130 |                         FILTER                               |                        |        |       |       |            |          |       |       |          |         |
| 131 |                          TABLE ACCESS FULL                   | SECT_701               |   1716 |   326K|       |    18   (0)| 00:00:01 |       |       |          |         |
|*132 |                         FILTER                               |                        |        |       |       |            |          |       |       |          |         |
| 133 |                          TABLE ACCESS FULL                   | SECT_8                 |   1012 |   195K|       |     8   (0)| 00:00:01 |       |       |          |         |
|*134 |                         FILTER                               |                        |        |       |       |            |          |       |       |          |         |
| 135 |                          TABLE ACCESS FULL                   | SECT_80                |     98 |  5684 |       |     2   (0)| 00:00:01 |       |       |          |         |
|*136 |                         FILTER                               |                        |        |       |       |            |          |       |       |          |         |
| 137 |                          TABLE ACCESS FULL                   | SECT_99                |    528 |   104K|       |     6   (0)| 00:00:01 |       |       |          |         |
|*138 |                      TABLE ACCESS FULL                       | TC_OBJ2LINK            |   1299K|    19M|       |  1750   (2)| 00:00:01 |       |       |          |         |
| 139 |                    VIEW                                      |                        |    130K|  2676K|       |  3784   (1)| 00:00:01 |       |       |          |         |
|*140 |                     FILTER                                   |                        |        |       |       |            |          |       |       |          |         |
| 141 |                      JOIN FILTER USE                         | :BF0000                |    130K|  4716K|       |  3784   (1)| 00:00:01 |       |       |          |         |
|*142 |                       HASH JOIN RIGHT OUTER                  |                        |    130K|  4716K|       |  3784   (1)| 00:00:01 |  2091K|  1761K| 2290K (0)|         |
|*143 |                        TABLE ACCESS BY INDEX ROWID           | TP_ZAG_D               |  17910 |   472K|       |  3250   (1)| 00:00:01 |       |       |          |         |
|*144 |                         INDEX RANGE SCAN                     | TP_ZAG_D_F_ENTITY      |  18608 |       |       |    45   (0)| 00:00:01 |       |       |          |         |
|*145 |                        TABLE ACCESS FULL                     | TP_ZAG                 |    148K|  1445K|       |   533   (2)| 00:00:01 |       |       |          |         |
|*146 |                   TABLE ACCESS FULL                          | TP_ZAG_S               |    102K|  2299K|       |  1888   (1)| 00:00:01 |       |       |          |         |
|*147 |                  INDEX RANGE SCAN                            | TP_ZAG_D_F_PARENTKEY   |     18 |       |       |     2   (0)| 00:00:01 |       |       |          |         |
|*148 |                 TABLE ACCESS BY INDEX ROWID                  | TP_ZAG_D               |      2 |    48 |       |     3   (0)| 00:00:01 |       |       |          |         |
| 149 |                VIEW                                          | ZEBRA_ALL_SECT         |   8181 |   191K|       |  1437   (5)| 00:00:01 |       |       |          |         |
| 150 |                 UNION-ALL                                    |                        |        |       |       |            |          |       |       |          |         |
|*151 |                  TABLE ACCESS BY INDEX ROWID                 | SECT_0                 |      1 |   277 |       |     0   (0)|          |       |       |          |         |
|*152 |                   INDEX FULL SCAN                            | SECT_0_KOD_ODI_P_NDX   |      1 |       |       |     0   (0)|          |       |       |          |         |
|*153 |                  TABLE ACCESS FULL                           | SECT_1                 |    104 |  1456 |       |   190   (3)| 00:00:01 |       |       |          |         |
|*154 |                  TABLE ACCESS FULL                           | SECT_107               |    930 | 45570 |       |    41  (18)| 00:00:01 |       |       |          |         |
|*155 |                  TABLE ACCESS FULL                           | SECT_131               |   1065 | 37275 |       |    43  (19)| 00:00:01 |       |       |          |         |
|*156 |                  TABLE ACCESS FULL                           | SECT_148               |    264 | 10296 |       |    39   (6)| 00:00:01 |       |       |          |         |
|*157 |                  FILTER                                      |                        |        |       |       |            |          |       |       |          |         |
| 158 |                   INDEX FULL SCAN                            | SECT_191_PRIMARY       |    140 |   700 |       |     1   (0)| 00:00:01 |       |       |          |         |
|*159 |                  TABLE ACCESS BY INDEX ROWID                 | SECT_2                 |      1 |    27 |       |     0   (0)|          |       |       |          |         |
|*160 |                   INDEX FULL SCAN                            | SECT_2_KOD_ODI_P_NDX   |      1 |       |       |     0   (0)|          |       |       |          |         |
|*161 |                  TABLE ACCESS FULL                           | SECT_3                 |     58 |  1450 |       |   196   (1)| 00:00:01 |       |       |          |         |
|*162 |                  TABLE ACCESS FULL                           | SECT_4                 |    213 |  5325 |       |   545   (1)| 00:00:01 |       |       |          |         |
|*163 |                  TABLE ACCESS FULL                           | SECT_5                 |    268 | 10184 |       |   120   (2)| 00:00:01 |       |       |          |         |
|*164 |                  TABLE ACCESS FULL                           | SECT_53                |      2 |    58 |       |     3   (0)| 00:00:01 |       |       |          |         |
|*165 |                  TABLE ACCESS BY INDEX ROWID                 | SECT_55                |      1 |    38 |       |     2   (0)| 00:00:01 |       |       |          |         |
|*166 |                   INDEX FULL SCAN                            | SECT_55_KOD_ODI_P_NDX  |      1 |       |       |     1   (0)| 00:00:01 |       |       |          |         |
|*167 |                  TABLE ACCESS BY INDEX ROWID                 | SECT_56                |      1 |    40 |       |     0   (0)|          |       |       |          |         |
|*168 |                   INDEX FULL SCAN                            | SECT_56_KOD_ODI_P_NDX  |      1 |       |       |     0   (0)|          |       |       |          |         |
|*169 |                  TABLE ACCESS BY INDEX ROWID                 | SECT_57                |      1 |    53 |       |     0   (0)|          |       |       |          |         |
|*170 |                   INDEX FULL SCAN                            | SECT_57_KOD_ODI_P_NDX  |      1 |       |       |     0   (0)|          |       |       |          |         |
|*171 |                  TABLE ACCESS FULL                           | SECT_6                 |   2720 |   124K|       |   120  (17)| 00:00:01 |       |       |          |         |
|*172 |                  FILTER                                      |                        |        |       |       |            |          |       |       |          |         |
|*173 |                   TABLE ACCESS FULL                          | SECT_63                |     17 |   680 |       |     2   (0)| 00:00:01 |       |       |          |         |
|*174 |                  TABLE ACCESS FULL                           | SECT_7                 |   2531 |   126K|       |   116  (17)| 00:00:01 |       |       |          |         |
|*175 |                  TABLE ACCESS BY INDEX ROWID                 | SECT_701               |      1 |   138 |       |     2   (0)| 00:00:01 |       |       |          |         |
|*176 |                   INDEX FULL SCAN                            | SECT_701_KOD_ODI_P_NDX |      1 |       |       |     1   (0)| 00:00:01 |       |       |          |         |
|*177 |                  TABLE ACCESS FULL                           | SECT_8                 |      2 |   302 |       |     8   (0)| 00:00:01 |       |       |          |         |
|*178 |                  FILTER                                      |                        |        |       |       |            |          |       |       |          |         |
|*179 |                   TABLE ACCESS FULL                          | SECT_80                |      5 |   110 |       |     2   (0)| 00:00:01 |       |       |          |         |
|*180 |                  TABLE ACCESS BY INDEX ROWID                 | SECT_99                |      1 |   162 |       |     0   (0)|          |       |       |          |         |
|*181 |                   INDEX FULL SCAN                            | SECT_99_KOD_ODI_P_NDX  |      1 |       |       |     0   (0)|          |       |       |          |         |
|*182 |               TABLE ACCESS BY INDEX ROWID                    | TP_ZAG_D               |      1 |    27 |       |     3   (0)| 00:00:01 |       |       |          |         |
|*183 |                INDEX RANGE SCAN                              | TP_ZAG_D_F_PARENTKEY   |     18 |       |       |     2   (0)| 00:00:01 |       |       |          |         |
| 184 |              TABLE ACCESS BY INDEX ROWID                     | ARTICLES               |      1 |    24 |       |     2   (0)| 00:00:01 |       |       |          |         |
|*185 |               INDEX UNIQUE SCAN                              | ARTICLES_PRIM_NDX      |      1 |       |       |     1   (0)| 00:00:01 |       |       |          |         |
|*186 |             TABLE ACCESS BY INDEX ROWID                      | TP_ZAG_S               |      1 |    14 |       |     3   (0)| 00:00:01 |       |       |          |         |
|*187 |              INDEX RANGE SCAN                                | TP_ZAG_S_F_PARENTKEY   |      3 |       |       |     2   (0)| 00:00:01 |       |       |          |         |
|*188 |            TABLE ACCESS BY INDEX ROWID                       | TP_ZAG_F               |      1 |    13 |       |     3   (0)| 00:00:01 |       |       |          |         |
|*189 |             INDEX RANGE SCAN                                 | TP_ZAG_F_F_PARENTKEY   |      2 |       |       |     2   (0)| 00:00:01 |       |       |          |         |
|*190 |           TABLE ACCESS BY INDEX ROWID                        | ARTICLES               |      1 |     7 |       |     2   (0)| 00:00:01 |       |       |          |         |
|*191 |            INDEX UNIQUE SCAN                                 | ARTICLES_PRIM_NDX      |      1 |       |       |     1   (0)| 00:00:01 |       |       |          |         |
| 192 |          VIEW                                                | ZEBRA_ALL_SECT         |  12647 |   419K|       |     1   (0)| 00:00:01 |       |       |          |         |
| 193 |           UNION-ALL PARTITION                                |                        |        |       |       |            |          |       |       |          |         |
|*194 |            TABLE ACCESS BY INDEX ROWID                       | SECT_0                 |      1 |   404 |       |     0   (0)|          |       |       |          |         |
|*195 |             INDEX FULL SCAN                                  | SECT_0_KOD_ODI_NDX     |      1 |       |       |     0   (0)|          |       |       |          |         |
|*196 |            TABLE ACCESS BY INDEX ROWID                       | SECT_1                 |      1 |    22 |       |     2   (0)| 00:00:01 |       |       |          |         |
|*197 |             INDEX UNIQUE SCAN                                | SECT_1_PRIMARY         |      1 |       |       |     1   (0)| 00:00:01 |       |       |          |         |
|*198 |            TABLE ACCESS BY INDEX ROWID                       | SECT_107               |      1 |    50 |       |     2   (0)| 00:00:01 |       |       |          |         |
|*199 |             INDEX UNIQUE SCAN                                | SECT_107_PRIMARY       |      1 |       |       |     1   (0)| 00:00:01 |       |       |          |         |
|*200 |            TABLE ACCESS BY INDEX ROWID                       | SECT_131               |      1 |    40 |       |     2   (0)| 00:00:01 |       |       |          |         |
|*201 |             INDEX UNIQUE SCAN                                | SECT_131_PRIMARY       |      1 |       |       |     1   (0)| 00:00:01 |       |       |          |         |
|*202 |            TABLE ACCESS BY INDEX ROWID                       | SECT_148               |      1 |    47 |       |     2   (0)| 00:00:01 |       |       |          |         |
|*203 |             INDEX UNIQUE SCAN                                | SECT_148_PRIMARY       |      1 |       |       |     1   (0)| 00:00:01 |       |       |          |         |
|*204 |            TABLE ACCESS BY INDEX ROWID                       | SECT_191               |      1 |     9 |       |     1   (0)| 00:00:01 |       |       |          |         |
|*205 |             INDEX UNIQUE SCAN                                | SECT_191_PRIMARY       |      1 |       |       |     0   (0)|          |       |       |          |         |
|*206 |            TABLE ACCESS BY INDEX ROWID                       | SECT_2                 |      1 |    27 |       |     0   (0)|          |       |       |          |         |
|*207 |             INDEX FULL SCAN                                  | SECT_2_KOD_ODI_NDX     |      1 |       |       |     0   (0)|          |       |       |          |         |
|*208 |            TABLE ACCESS BY INDEX ROWID                       | SECT_3                 |      1 |    50 |       |     2   (0)| 00:00:01 |       |       |          |         |
|*209 |             INDEX UNIQUE SCAN                                | SECT_3_PRIMARY         |      1 |       |       |     1   (0)| 00:00:01 |       |       |          |         |
|*210 |            TABLE ACCESS BY INDEX ROWID                       | SECT_4                 |      1 |    47 |       |     2   (0)| 00:00:01 |       |       |          |         |
|*211 |             INDEX UNIQUE SCAN                                | SECT_4_PRIMARY         |      1 |       |       |     1   (0)| 00:00:01 |       |       |          |         |
|*212 |            TABLE ACCESS BY INDEX ROWID                       | SECT_5                 |      1 |    55 |       |     2   (0)| 00:00:01 |       |       |          |         |
|*213 |             INDEX UNIQUE SCAN                                | SECT_5_PRIMARY         |      1 |       |       |     1   (0)| 00:00:01 |       |       |          |         |
|*214 |            TABLE ACCESS BY INDEX ROWID                       | SECT_53                |      1 |    59 |       |     1   (0)| 00:00:01 |       |       |          |         |
|*215 |             INDEX UNIQUE SCAN                                | SECT_53_PRIMARY        |      1 |       |       |     0   (0)|          |       |       |          |         |
|*216 |            TABLE ACCESS BY INDEX ROWID                       | SECT_55                |      1 |    42 |       |     0   (0)|          |       |       |          |         |
|*217 |             INDEX FULL SCAN                                  | SECT_55_KOD_ODI_NDX    |      1 |       |       |     0   (0)|          |       |       |          |         |
|*218 |            TABLE ACCESS BY INDEX ROWID                       | SECT_56                |      1 |    56 |       |     0   (0)|          |       |       |          |         |
|*219 |             INDEX FULL SCAN                                  | SECT_56_KOD_ODI_NDX    |      1 |       |       |     0   (0)|          |       |       |          |         |
|*220 |            TABLE ACCESS BY INDEX ROWID                       | SECT_57                |      1 |    63 |       |     0   (0)|          |       |       |          |         |
|*221 |             INDEX FULL SCAN                                  | SECT_57_KOD_ODI_NDX    |      1 |       |       |     0   (0)|          |       |       |          |         |
|*222 |            TABLE ACCESS BY INDEX ROWID                       | SECT_6                 |      1 |    52 |       |     2   (0)| 00:00:01 |       |       |          |         |
|*223 |             INDEX UNIQUE SCAN                                | SECT_6_PRIMARY         |      1 |       |       |     1   (0)| 00:00:01 |       |       |          |         |
|*224 |            TABLE ACCESS BY INDEX ROWID                       | SECT_63                |      1 |    40 |       |     1   (0)| 00:00:01 |       |       |          |         |
|*225 |             INDEX UNIQUE SCAN                                | SECT_63_PRIMARY        |      1 |       |       |     0   (0)|          |       |       |          |         |
|*226 |            TABLE ACCESS BY INDEX ROWID                       | SECT_7                 |      1 |    50 |       |     2   (0)| 00:00:01 |       |       |          |         |
|*227 |             INDEX UNIQUE SCAN                                | SECT_7_PRIMARY         |      1 |       |       |     1   (0)| 00:00:01 |       |       |          |         |
|*228 |            TABLE ACCESS BY INDEX ROWID                       | SECT_701               |      1 |   195 |       |     2   (0)| 00:00:01 |       |       |          |         |
|*229 |             INDEX UNIQUE SCAN                                | SECT_701_PRIMARY       |      1 |       |       |     1   (0)| 00:00:01 |       |       |          |         |
|*230 |            TABLE ACCESS BY INDEX ROWID                       | SECT_8                 |      1 |   198 |       |     2   (0)| 00:00:01 |       |       |          |         |
|*231 |             INDEX UNIQUE SCAN                                | SECT_8_PRIMARY         |      1 |       |       |     1   (0)| 00:00:01 |       |       |          |         |
|*232 |            TABLE ACCESS BY INDEX ROWID                       | SECT_80                |      1 |    58 |       |     1   (0)| 00:00:01 |       |       |          |         |
|*233 |             INDEX UNIQUE SCAN                                | SECT_80_PRIMARY        |      1 |       |       |     0   (0)|          |       |       |          |         |
|*234 |            TABLE ACCESS BY INDEX ROWID                       | SECT_99                |      1 |   203 |       |     2   (0)| 00:00:01 |       |       |          |         |
|*235 |             INDEX UNIQUE SCAN                                | SECT_99_PRIMARY        |      1 |       |       |     1   (0)| 00:00:01 |       |       |          |         |
| 236 |       VIEW                                                   |                        |   7847K|    14G|       |   260K  (1)| 00:00:11 |       |       |          |         |
| 237 |        SORT GROUP BY                                         |                        |   7847K|  1167M|  1251M|   260K  (1)| 00:00:11 |  7636K|  1177K| 6787K (0)|         |
|*238 |         HASH JOIN RIGHT OUTER                                |                        |   7847K|  1167M|       | 35960   (2)| 00:00:02 |  6271K|  1761K| 6696K (0)|         |
| 239 |          VIEW                                                |                        |  54924 |  1072K|       | 16926   (2)| 00:00:01 |       |       |          |         |
| 240 |           HASH UNIQUE                                        |                        |  54924 |  5310K|  6112K| 16926   (2)| 00:00:01 |  7690K|  3198K| 5559K (0)|         |
|*241 |            HASH JOIN                                         |                        |  54924 |  5310K|  7280K| 15895   (2)| 00:00:01 |    16M|  3954K|   20M (0)|         |
|*242 |             FILTER                                           |                        |        |       |       |            |          |       |       |          |         |
|*243 |              HASH JOIN RIGHT OUTER                           |                        |  85683 |  6275K|       | 10877   (2)| 00:00:01 |  2091K|  1761K| 2319K (0)|         |
|*244 |               TABLE ACCESS BY INDEX ROWID                    | TP_ZAG_D               |  17910 |   472K|       |  3250   (1)| 00:00:01 |       |       |          |         |
|*245 |                INDEX RANGE SCAN                              | TP_ZAG_D_F_ENTITY      |  18608 |       |       |    45   (0)| 00:00:01 |       |       |          |         |
|*246 |               HASH JOIN                                      |                        |    128K|  6001K|  2280K|  7626   (2)| 00:00:01 |  6448K|  2024K| 8744K (0)|         |
| 247 |                VIEW                                          |                        |  52888 |  1652K|       |  5396   (2)| 00:00:01 |       |       |          |         |
|*248 |                 FILTER                                       |                        |        |       |       |            |          |       |       |          |         |
|*249 |                  FILTER                                      |                        |        |       |       |            |          |       |       |          |         |
|*250 |                   HASH JOIN OUTER                            |                        |  52888 |  1910K|  3184K|  5396   (2)| 00:00:01 |  7894K|  2748K| 8797K (0)|         |
|*251 |                    TABLE ACCESS FULL                         | TP_ZAG                 |    148K|  1445K|       |   533   (2)| 00:00:01 |       |       |          |         |
|*252 |                    TABLE ACCESS FULL                         | TP_ZAG_D               |    109K|  2892K|       |  4769   (2)| 00:00:01 |       |       |          |         |
|*253 |                TABLE ACCESS FULL                             | TC_OBJ2LINK            |   1299K|    19M|       |  1750   (2)| 00:00:01 |       |       |          |         |
|*254 |             TABLE ACCESS FULL                                | TP_ZAG_D               |    344K|  8067K|       |  4775   (2)| 00:00:01 |       |       |          |         |
| 255 |          VIEW                                                |                        |    149K|    19M|       | 18997   (2)| 00:00:01 |       |       |          |         |
| 256 |           HASH UNIQUE                                        |                        |    149K|    14M|    16M| 18997   (2)| 00:00:01 |  4775K|  1274K| 3024K (0)|         |
|*257 |            FILTER                                            |                        |        |       |       |            |          |       |       |          |         |
|*258 |             HASH JOIN RIGHT OUTER                            |                        |    149K|    14M|       | 16051   (2)| 00:00:01 |  2091K|  1761K| 2341K (0)|         |
|*259 |              TABLE ACCESS BY INDEX ROWID                     | TP_ZAG_D               |  17910 |   472K|       |  3250   (1)| 00:00:01 |       |       |          |         |
|*260 |               INDEX RANGE SCAN                               | TP_ZAG_D_F_ENTITY      |  18608 |       |       |    45   (0)| 00:00:01 |       |       |          |         |
|*261 |              HASH JOIN                                       |                        |    170K|    12M|    11M| 12801   (2)| 00:00:01 |    20M|  3646K|   22M (0)|         |
|*262 |               TABLE ACCESS FULL                              | TP_ZAG_D               |    344K|  8067K|       |  4775   (2)| 00:00:01 |       |       |          |         |
|*263 |               HASH JOIN                                      |                        |    265K|    13M|  5256K|  7663   (2)| 00:00:01 |  3562K|  2193K| 3050K (0)|         |
|*264 |                HASH JOIN                                     |                        |    109K|  3963K|  3184K|  5396   (2)| 00:00:01 |  7894K|  2748K| 8745K (0)|         |
|*265 |                 TABLE ACCESS FULL                            | TP_ZAG                 |    148K|  1445K|       |   533   (2)| 00:00:01 |       |       |          |         |
|*266 |                 TABLE ACCESS FULL                            | TP_ZAG_D               |    109K|  2892K|       |  4769   (2)| 00:00:01 |       |       |          |         |
|*267 |                TABLE ACCESS FULL                             | TC_OBJ2LINK            |   1299K|    19M|       |  1750   (2)| 00:00:01 |       |       |          |         |
3 дек 18, 14:15    [21752057]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
MaximaXXL
Member

Откуда: Киев
Сообщений: 635
Ryuu,

Поправьте меня если я ошибаюсь, Вы сначала count_pc собераете в строку что-бы ... потом строку разобрать и сделать sum()?

Это конечно не запрещенно - но зачем?

Если есть пример, дайте его ... но я пока не понял в чем смысл, собрать через * что-бы потом парсить ...
3 дек 18, 15:20    [21752158]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
Ryuu
Member [заблокирован]

Откуда:
Сообщений: 545
MaximaXXL, вы невнимательны, и пишите не в тему. Вопрос был не об этом.
3 дек 18, 15:25    [21752164]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
DВА
Member

Откуда:
Сообщений: 5251
MaximaXXL,
Ryuu
MaximaXXL, вы невнимательны, и пишите не в тему. Вопрос был не об этом.


ему параметры нужны ))
Ведь не может же быть такое, чтоб работал две недели, а на третью сам по себе перестал
наверняка есть какие-то хитрые параметры, которые злобные админы постоянно дергают и не дают говнокоду прилично работать )
3 дек 18, 15:55    [21752189]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
Ryuu
Member [заблокирован]

Откуда:
Сообщений: 545
DВА, *пустил слезу умиления. Вы правы, я хочу, чтобы мой говнокод снова стал работать в пределах двух минут, а не часов. :)
3 дек 18, 16:15    [21752204]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
DВА
Member

Откуда:
Сообщений: 5251
Ryuu
DВА, *пустил слезу умиления. Вы правы, я хочу, чтобы мой говнокод снова стал работать в пределах двух минут, а не часов. :)


поищу тут что-нить полезное
http://ru.harrypotter.wikia.com/wiki/Бытовые_заклинания
3 дек 18, 16:26    [21752210]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
MaximaXXL
Member

Откуда: Киев
Сообщений: 635
Ryuu
DВА, *пустил слезу умиления. Вы правы, я хочу, чтобы мой говнокод снова стал работать в пределах двух минут, а не часов. :)


Если это единственная хотелка - удаляете данные из ZEBRA_ALL_SECT (чем больше удалите - тем быстрее будет) и все полетит.

Чем то напомнил старый анекдот
+
Разговор пользователя (П) и специалиста (С):
С: Что у вас за беда?
П: У меня идет дым из блока питания.
С: Вам нужно заменить блок питания.
П: Не может быть! Мне нужно просто поправить какой-то файл!
С: Помилуйте - у вас неисправный блок питания! Он должен быть заменен!
П: Ни за что. Мне сказали, что нужно добавить какую-то команду
в autoexec.bat или config.sys. Вы мне только скажите - какую.

Проходит десять минут. Пользователь уверен в своей правоте.
Специалист задолбан в доску.
С: Извините... мы обычно не говорим этого нашим клиентам, но
существует недокументированная команда ДОСа, которая решит ваши
проблемы.
П: Так я и знал!
С: Добавьте команду LOAD NOSMOKE.COM в конце файла CONFIG.SYS, и
сообщите, как оно - поможет, или нет.
Проходит десять минут.
П: Не помогло! Дым все равно идет.
С: Какая у вас версия ДОСа?
П: 6.22
С: Ааа! Вот в чем дело. В эту версию NOSMOKE не входит. Позвоните в
Микрософт, попросите их выслать вам нужный драйвер.

Проходит час.

П: Знаете, мне нужен новый блок питания.
С: Почему вы так решили?
П: Я позвонил в Микрософт, и они стали расспрашивать меня о том, кто
производитель моего блока питания.
С: И что?
П: Выяснилось, что мой блок питания не совместим с драйвером NOSMOKE.
3 дек 18, 16:31    [21752218]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
DВА
Member

Откуда:
Сообщений: 5251
Ну или как вариант - прогнуться перед админами, извиниться за высказанные подозрения в порче говнокода и просьба найти и закрепить план запроса, который был две недели назад.
3 дек 18, 16:42    [21752234]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
Ryuu
Member [заблокирован]

Откуда:
Сообщений: 545
DВА, они хотели закрепить план запроса, но не смогли. Причину не назвали. Или с планом всё хорошо, но почему-то проседать он от этого не перестал, либо... я не знаю. Но у меня от этого, если честно, подгорает. :-\

Ps. Спасибо за ссылку, посмотрю завтра. Не понял, как "чистка" вьюшки поможет.
3 дек 18, 16:51    [21752251]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
Ryuu
Member [заблокирован]

Откуда:
Сообщений: 545
А, ну да... заклинания. Хм. Такое, пожалуй, вечером почитаю. Да. Какой-нибудь фанфик. :)
3 дек 18, 16:52    [21752253]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
flexgen
Member

Откуда: Город на песке
Сообщений: 654
автор
Лично я грешу на наших админов, что ковырнули настройки БД, в чем они конечно же не признаются


Я на такое всегда отвечаю так - у меня под крышкой стола есть три кнопки, "Все не работает", "Все работает", "Все работает отлично". В зависимости от своего настроения я нажимаю соответствующую кнопку и все работает или не работает :-). Последний случай когда я это говорил был буквально вчера - пришли ко мне чудаки из BI с жалобой на то, что вдруг все перестало работать и с вопросом "А не подкрутил ли что-то в базе злобный DBA чтобы бедняжкам из BI нескучно было?". А то что четыре картезианских множества из двух таблиц объединенных при помощи UNION ALL, в сумме дающих 8 миллиардов записей, это не самый лучший вариант запроса им как-то в голову не пришло.
3 дек 18, 22:49    [21752458]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
Ryuu
Member [заблокирован]

Откуда:
Сообщений: 545
flexgen, вот только такой запрос изначально бы работал хреново. В любом случае, думаю, что я разобрался. У них маленькое значение для переменной сортировки под сессию.
4 дек 18, 08:05    [21752563]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
кит северных морей
Member

Откуда: Красноярск
Сообщений: 482
Ryuu,

из вашего поста не вполне понятно, съехал ли у вас план для запроса, полностью идентичного тому, что был две недели назад, или же запрос претерпел изменения, которые вы считаете незначительными, но СУБД имеет на этот счёт свое мнение.

в любом случае, попросите админов сделать отчет real time sql monitor. в нем будет четко видно, на что фактически уходит время при выполнении запроса. после этого можно будет о чем-то рассуждать, и делать какие-то выводы. без этой, или какой-то другой фактической информации, все, чего вы дождетесь в ответ - спекуляции и гадания на кофейной гуще. то, что вы уже показали здесь - это прогноз самой субд, который по ряду причин часто имеет мало общего с реальностью.
4 дек 18, 08:35    [21752569]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
env
Member

Откуда: Россия, Москва
Сообщений: 5916
Ryuu,

План, по которому выполняется запрос действительно такой? И всё ли хорошо со статистикой.
4 дек 18, 09:51    [21752619]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
env
Member

Откуда: Россия, Москва
Сообщений: 5916
Ryuu,

И есть большие сомнения, что это план приведённого запроса. Как раз из-за сортировки.
4 дек 18, 09:54    [21752624]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
env
Member

Откуда: Россия, Москва
Сообщений: 5916
Ryuu
Есть некий запрос, который еще две недели назад работал хорошо. Потом что-то случилось. Лично я грешу на наших админов


Разумеется за это время ни одной новой записи в таблицы не попадало, объёмы данных не менялись, статистика не трогалась никем и ничем, никаких доработок на бд не было, не решалось никем другим никаких других проблем производительности и т.п., ох уж эти злобные админы, которые просто так всё ломают!

Скорее всего план твоего запроса держался на границе merge/unnest за счёт статистки, и как только она перешла грань - произошло слияние подзапроса и "первого куска". Как вариант, прибей гвоздями материализацию подзапроса.
4 дек 18, 10:02    [21752630]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
DВА
Member

Откуда:
Сообщений: 5251
env
Ryuu
Есть некий запрос, который еще две недели назад работал хорошо. Потом что-то случилось. Лично я грешу на наших админов


Разумеется за это время ни одной новой записи в таблицы не попадало, объёмы данных не менялись, статистика не трогалась никем и ничем, никаких доработок на бд не было, не решалось никем другим никаких других проблем производительности и т.п., ох уж эти злобные админы, которые просто так всё ломают!

Скорее всего план твоего запроса держался на границе merge/unnest за счёт статистки, и как только она перешла грань - произошло слияние подзапроса и "первого куска". Как вариант, прибей гвоздями материализацию подзапроса.


курсоры из кэша не вытеснялись и адаптивные фичи оптимизатора не баламутили )
4 дек 18, 14:10    [21752913]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
MaximaXXL
Member

Откуда: Киев
Сообщений: 635
Ryuu,

Я конечно не внимателен, да и пишу не в тему и наверно многово не успею понять но для конкретно ЭТОГО запроса который Вы хотите ускорить ...
SELECT
  tobj.*
FROM ...

Т.е. Вам нужены только данные из sysdba.tc_obj2link tobj,

условие по соединиению AND my_pc.root_part_aid = tobj.f_art_id

итого Вы строите структуру из 5 subquery для того чтоб размножить данные tobj для количества кустов? Подход конечно ... "верный", но как по мне очень громоздкий.

Если Вы собераетесь использовать данные my_pc в дальнейшем, а это уже другой селект:
Из Ваших утверждений proj_aid и part_aid что это индексированные поля, то не проще пробежать по ним к листу (зная tobj.f_art_id), а не строить все дерево. Ну и если понадобиться сумма произведений еще раз пробежаться наверх (это 1-2 подзапроса) смотря что надо найти.
4 дек 18, 15:55    [21753181]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
A K
Member

Откуда:
Сообщений: 352
Смотрите. Тут ребята много разных дельных советов дали. Это все хорошо и правильно.

Но! Нужно прежде всего исключить одну вещь. Разберитесь со следующими вещами:
1. Проверьте - все ли условия по данным были тогда и сейчас идентичны (то есть вставок новых в таблицы не происходило ит.д.) , если есть возможность сравните планы выполнения тогда и сейчас (ну мало ли, вдруг вы где-то сохранили старый план). Если планы выполнения идентичны, тогда:
2. У вас виртуальная или реальная среда на которой крутиться БД ? Если виртуальная тогда:

прежде чем что-то предпринимать, поинтересуйтесь у админов степенью нагрузки общего физического дискового массива другими приложениями и базами. Учитывая модные тенденции сейчас все ставить на виртуалки, даже бд (особенно когда общее железо разделяют несколько баз, приложений и прочее.), - всегда нужно интересоваться нагрузками на дисковую подсистему. Возможно на СХД на одном луне повесили кучу аплекух и баз, и тогда на ровном месте вы можете получить сегодня идеальную работу, а завтра при тех же самых условиях у вас мистическим образом все упадет !
4 дек 18, 16:02    [21753211]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
DВА
Member

Откуда:
Сообщений: 5251
A K
прежде чем что-то предпринимать, поинтересуйтесь у админов степенью нагрузки общего физического дискового массива другими приложениями и базами. Учитывая модные тенденции сейчас все ставить на виртуалки, даже бд (особенно когда общее железо разделяют несколько баз, приложений и прочее.), - всегда нужно интересоваться нагрузками на дисковую подсистему. Возможно на СХД на одном луне повесили кучу аплекух и баз, и тогда на ровном месте вы можете получить сегодня идеальную работу, а завтра при тех же самых условиях у вас мистическим образом все упадет !


с трудом представляю себе, чтобы можно было "навешать", что бы время работы увеличилось с двух минут до двух часов и при этом оно все еще выглядело живым в целом )))
4 дек 18, 16:09    [21753241]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
A K
Member

Откуда:
Сообщений: 352
Поверьте, и не такое бывает. Вот с чем соглашусь - живым и целым. :) Да в этом случае, действительно наблюдается сильная общая деградация работы всей бд, при полном отсутствии объективных причин вызванных прикладным уровнем самой БД - запросы, хранимки . В AWR начинают попадать елементы, которых там в принципе быть не должно ит.д.

Понимаю, что у топикпастера скорее-всего банальное разрастание таблиц + возможное отсутствие необходимых индексов (ну или фактор кластеризации нужных индексов резко увеличился и поэтому вместо индекса, запрос начал фулить) - изучать в общем нужно план хороший и плохой...
Но, он же утверждает, что количество данных не менялось. А если ничего вообще не менялось и резко пошла деградация - тогда это одна из основных причин, при условии, что все остальные причины исключены.
4 дек 18, 16:37    [21753310]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
DВА
Member

Откуда:
Сообщений: 5251
A K,
грошь цена его утверждениям, он не напрягся даже план проверить )
4 дек 18, 17:15    [21753410]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
Stax
Member

Откуда: Ukraine,Lviv
Сообщений: 1418
DВА,

поменялась статистика (немножко) и етого хватило чтоб планы поплыли в сторону HASH JOIN
с минут можно влететь в часы и наоборот

мож изменили параматры (ресурсы) от которых зависит порог срабатывания для HASH JOIN

.....
stax
4 дек 18, 17:32    [21753452]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
казинак
Member

Откуда:
Сообщений: 1206
лично на меня не раз так наезжали:
"вчера работало а щас висит"

и в общем случае, в таких ситуациях, я даже причину не ищу
эта оракл, детка!!!
проще устранить трабл,
но это не всегда возможно,
к примеру, недавно базисникам я сказал:
"раз в вашем гребаном сапе низя в обход сапа в базе лазить
то сами и разбирайтесь
либо читайте сапноты либо в саппорт пишите
нехер на базу стрелки переводить"
4 дек 18, 17:35    [21753457]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
A K
Member

Откуда:
Сообщений: 352
DBA, В общем согласен. :)

А знаете, что самое смешное ?

Раньше, я бы сказал, что Stax, например абсолютно прав! И начал бы серьезно копать где накосячил CBO со своей аналитикой и копипастер со своими индексами и вставками. Но сейчас, все чаще становиться прав условный "казинак".
Потому, что от патча к патчу и от версии к версии - CBO становиться не таким тупым как было раньше. И, если копипастер явно с индексами не накосячил, то как правило CBO просто так не фулит, без серьезной на то причины, как было это раньше.
Но! вот эта любовь к виртуалкам везде - где надо и где не надо, невозможность установить БД на нормальном железе - приколов от этого сейчас просто немеренно.
4 дек 18, 17:47    [21753478]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
Ryuu
Member [заблокирован]

Откуда:
Сообщений: 545
Кхм, простите, что отсутствовал. Но проблема выявлена, только админы, вместо того, чтобы увеличить объем переменной, обратились, так сказать, к техподдержке выше. Теперь вот жду. И, видимо, это затянется.

Запросы, что я выложил, тестовые (немного измененное ядро запроса). Разумеется, оригинал гораздо сложнее, больше. И да, мне нужны не только данные из одной таблицы. Просто в данном случае, проблема полностью совпадает (провисание происходит уже на этой стадии), а потому вытаскивать какие-либо ещё поля я посчитал излишним.

Таблицы, понятное дело пополнялись, что как раз и показывает, что на обработку просто перестало хватать памяти и её надо увеличить. А время увеличения запроса происходит из-за того, что данные скидываются уже с оперативной памяти в дисковое пространство, темп, где обработка гораздо медленнее. И да, здесь уже на неё может сильно влиять кач-во железа и нагрузка сервера. Ну, я к таким выводам пришел. Админам лень что-либо проверять, или они просто не знают, как этот параметр называется. Знаю, что сейчас на сессию выделяет 1.5 Гб, и как раз их не хватает.

Ps. Админы вообще такие перлы выдавали, хоть стой, хоть падай. Например, указывали в "самый тяжелый HASH JOIN", который обрабатывает 8-10 секунд, и предложили его мне запихнуть в матвью. А то, что запрос работает 2 часа, а сам джоин двух таблиц происходит по ключу, т.е. по индексу, и быстрее быть в принципе не может... ну кого это волнует, право слово? Когда я им предложил это сделать самим, чтобы не тратить своё время, раз уж они считают, что это поможет, админы почему-то обиделись и нажаловались своему начальству, что их заставляют оптимизировать чужой запрос. Это дико смешно, но мне порой с них плакать хочется. Честно. Благо это не тот вопрос, который они могут "скинуть" с себя. :)
5 дек 18, 10:19    [21754001]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
-2-
Member

Откуда:
Сообщений: 14095
Ryuu
увеличить объем переменной
Ты своим админам дай ссылку на эту тему. Может они тоже какие перлы про тебя опубликуют.
5 дек 18, 10:24    [21754007]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
Ryuu
Member [заблокирован]

Откуда:
Сообщений: 545
И да, план давали админы, т.е. могу надеяться, что он достаточно объективен. По нему, кстати, хорошо видно, что запрос составлен грамотно. Проблема в сортировке, которая провисает.
5 дек 18, 10:24    [21754008]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
Ryuu
Member [заблокирован]

Откуда:
Сообщений: 545
-2-, смею надеяться, что я достаточно самоироничен, чтобы не обижаться на правду. Но нет, они слишком обидчивые, а мне с ними ещё работать. Найдут, ну и ладно. У меня от них неслабо так подгорело, пока разбирался в проблеме. В их проблеме. С их упорным отрицанием существования проблемы. Но вот намеренно провоцировать не стану.

А ты чего так подключился к флейму, сам админом подрабатываешь, задело? :)
5 дек 18, 10:28    [21754010]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
-2-
Member

Откуда:
Сообщений: 14095
Ryuu
админом подрабатываешь
Арбитром.
В игре в одни ворота нече на ворота пенять... Это воспринимается исключительно как продолжение небезызвестной присказки.
5 дек 18, 10:54    [21754023]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
Ryuu
Member [заблокирован]

Откуда:
Сообщений: 545
-2-, возможно, я несколько неправ, но, как я уже сказал ранее, у меня подгорело после общения с ними, а именно их желания сбросить эту проблему с себя, даже не пытаясь в нее вникнуть. А потому некоторый негатив все же проскальзывает. Всё-таки на работе себе я такого позволить не могу: резких и провокационных высказываний. Вернее могу, но зачем? В общем, ладно. Пустое.
5 дек 18, 11:30    [21754051]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
AlexFF__|
Member

Откуда:
Сообщений: 2814
Ryuu,

Все ты правильно сделал.
Может тебе и не достает знаний в понимании оптимизатора и прочего, но логика тут простая, не знаешь что делать - пинай админов.
Да и если знаешь - пинай, это такое племя, что сами лишний раз не пошевелятся, а так может что стоящее накопают =)

В твое случае админы либо лентяи либо дураки.
Если им жалко минутки своего времени на запуск скрипта, получающего планы и статистику запроса за различные периоды времени, то лентяи.
Если у них нет такого скрипта - дураки.
Не знаю, что хуже.
5 дек 18, 13:49    [21754323]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
env
Member

Откуда: Россия, Москва
Сообщений: 5916
Ryuu
пока разбирался в проблеме. В их проблеме.

Поддержу. Любой говнокод становится проблемой админа. Например, использование connect by в подзапросе (список багов смотри в металинке) с потенциальным or expansion в конкатенацию - это явно админы написали. Ух, нехорошие какие!
5 дек 18, 15:17    [21754496]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
Ryuu
Member [заблокирован]

Откуда:
Сообщений: 545
env, действительно, зачем разработчику использовать вложенные функции оракла, зачем эти мезкие програмеры вообще нагружают ИХ любимую базу данных этими бессмысленными запросами. Да?
5 дек 18, 15:43    [21754561]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
env
Member

Откуда: Россия, Москва
Сообщений: 5916
Ryuu
что на обработку просто перестало хватать памяти и её надо увеличить.

Распечатал и повесил.
5 дек 18, 15:45    [21754570]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
env
Member

Откуда: Россия, Москва
Сообщений: 5916
Ryuu
зачем разработчику использовать вложенные функции оракла
, не понимая, какой эффект могут получить. Забыли кусок фразы.

Зачем вообще разработчику думать, можно же просто брать функции и применять!
5 дек 18, 15:47    [21754573]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
DВА
Member

Откуда:
Сообщений: 5251
Расскажите плз чем эта эпопея закончится )
Кто кого - лентяи админы, не желающие вникать в ваш бредогенератор и решать чужие проблемы, или безгамотные разрабы, списывающие все проблемы говнокода на неправильные параметры )))

Извечная борьба )))
5 дек 18, 16:06    [21754611]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
Ryuu
Member [заблокирован]

Откуда:
Сообщений: 545
DВА, хорошо. :)

env, идите нах... :)
5 дек 18, 16:21    [21754631]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
-2-
Member

Откуда:
Сообщений: 14095
Ryuu
зачем разработчику использовать вложенные функции оракла
Вложенные функции это объявленные внутри другой и, соответственно, их область видимости ограничена охватывающей функцией. Функции оракла это sysdate, to_char и т.п.
В связи с этим, вопрос "зачем" можно задавать только после ответа на "как".
5 дек 18, 16:57    [21754702]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
Ryuu
Member [заблокирован]

Откуда:
Сообщений: 545
-2-, знаешь, я немного тебе завидую, ты тратишь своё время на пустой трёп, ведь за всё время, ты не сказал ничего по существу, а возможно и не планировал. Наверное, у тебя этого времени много. И да, хоть ты и расшифровал понятие "вложенности", но при этом как-то забыл, что у слов существуют синонимы и они, слова, вполне может иметь разные значения в зависимости от контекста. Но мы же хотим выебнуться, верно?
5 дек 18, 18:15    [21754810]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
Ryuu
Member [заблокирован]

Откуда:
Сообщений: 545
*могут.
Мда. Не люблю я этот форум из-за невозможности правки сообщений. Но кого это волнует, да? :)
5 дек 18, 18:17    [21754812]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
DВА
Member

Откуда:
Сообщений: 5251
Dimitry Sibiryakov
Ryuu
другие альтернативные методы решения проблемы.

Проанализировать план не предлагать?..


Ryuu
Dimitry Sibiryakov, а что толку?


После этого вряд ли кто-то тебе что-то скажет "по существу"
так, потролить разве что...
5 дек 18, 18:30    [21754818]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
mefman
Member

Откуда:
Сообщений: 2317
-2-
Ryuu
увеличить объем переменной
Ты своим админам дай ссылку на эту тему. Может они тоже какие перлы про тебя опубликуют.

да, думаю уже тут )
5 дек 18, 18:40    [21754829]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
кит северных морей
Member

Откуда: Красноярск
Сообщений: 482
Ryuu
ты не сказал ничего по существу, а возможно и не планировал

я еще на первой странице дал вам предельно конкретный ответ по существу - чтобы предметно разговаривать, нужно выполнить запрос, собрать статистики выполнения, например через RTSM, и проанализировать их. если вы готовы выложить RTSM - можно прямо здесь. не знаю, что за десятисекундный hash join вы там обсуждали с админами, но то, что вы выложили сюда ранее - это НЕ фактическая статистика выполнения запроса, и практической пользы от этого мало.

вы вместо этого продложаете абсолютно бессмысленные препирательства с админами на тему sort_area_size, или что вы там имеете в виду, и со всеми подряд здесь. у кого времени-то много?
5 дек 18, 18:52    [21754844]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
Ryuu
Member [заблокирован]

Откуда:
Сообщений: 545
кит северных морей, да, я имею ввиду sort_area_size. И мне, конечно, хотелось бы разобраться в проблеме и предоставить вам те или иные данные, которые помогли бы в её решении, но увы, я предоставил вам всё, что было в моих силах. Повторюсь, админы разбираться в проблеме НЕ хотят. Даже вышеуказанный параметр изменить, хотя бы на время теста, и теперь ждут ответ из службы поддержки выше. Поэтому всё и скатилось во флейм. В любом случае, мне это надоело. Что же до форума, я искренне надеялся, что у кого-то была схожая ситуация и мне дадут совет без какой-либо дополнительной информации от меня, сверх того, что я уже предоставил.
5 дек 18, 19:15    [21754855]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
DВА
Member

Откуда:
Сообщений: 5251
Ryuu
мне дадут совет без какой-либо дополнительной информации от меня, сверх того, что я уже предоставил.


бросай это дело сынок )
займись чем-нить менее напряжным для ума, ну там искусством, политикой ))
5 дек 18, 19:28    [21754866]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
кит северных морей
Member

Откуда: Красноярск
Сообщений: 482
Ryuu,

просевшая производительность запроса - это проблема разработчика, пока не доказано обратное (это я как разработчик говорю, а не как админ, если что). начинать разбираться, соответственно, должен разработчик, и не с подкрутки sort_area_size (параметры системы - это вообще самая распоследняя вещь, которую в этом случае нужно трогать). получить отчет RTSM можно элементарно одним запросом, либо через OEM.
5 дек 18, 19:29    [21754867]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
Ryuu
Member [заблокирован]

Откуда:
Сообщений: 545
mefman, возможно, но после переписки в жире, мне как-то всё равно.

DВА, план запроса я выложил, помогло? Нет. А других более существенных данных, которые помогли бы в решении задачи, у меня просто нет. И да, я уже пожалел о создании темы, только время потратил. Тем более, что всё скатилось до "мы написали в техподдержку, ждём". В любом случае, я разобрался, как мне кажется (перекрестился), в ситуации, а дальше... пусть делают, что хотят. Всех пользователей буду отправлять к ним.
5 дек 18, 19:29    [21754868]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
DВА
Member

Откуда:
Сообщений: 5251
Ryuu
Даже вышеуказанный параметр изменить, хотя бы на время теста, и теперь ждут ответ из службы поддержки выше.

теперь хренеет техподдержка, зачем какому-то птеродактилю понадобилось в 12 версии устанавливать sort_area_size вручную )))
5 дек 18, 19:31    [21754870]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
Ryuu
Member [заблокирован]

Откуда:
Сообщений: 545
кит северных морей, серьёзно? То есть, по вашему, если запрос исправно работал несколько лет, а потом бац, и стал выполняться вместо пары минут пару часов, это проблема разработчика? При этом последний никаких изменений не вносил.

DВА, спасибо, я уж как-нибудь сам решу чем заниматься.
5 дек 18, 19:33    [21754871]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
Ryuu
Member [заблокирован]

Откуда:
Сообщений: 545
DВА, о, тогда может большая жирная жаба в этом болоте жизни скажет в чем причина? Конечно же, я искренне надеюсь, что админы написали суть проблемы дальше, вместе со всеми имеющимися данными, нежели завели разговор о данном параметре, всё же я могу и ошибаться. И нет, новых данных я вам не предоставлю, только хардкор, только последний уровень сложности.
5 дек 18, 19:36    [21754873]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
кит северных морей
Member

Откуда: Красноярск
Сообщений: 482
Ryuu,

серьезно. например, подключили новый модуль в систему, прирост данных в какую-нибудь таблицу единовременно увеличился вдвоое-втрое, и с новой структурой данных в каком-нибудь старом отчете по этой таблице существующий план перестал быть оптимален. а новый оптимизатор построить не может, так как старый прибит хинтами.
5 дек 18, 19:39    [21754875]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
-2-
Member

Откуда:
Сообщений: 14095
Ryuu
Даже вышеуказанный параметр изменить
А анекдот-то 21752218 в тему. Похоже так достал админов, что они, вместо сказать "меняй сам", сослались на техподдержку.
5 дек 18, 19:41    [21754879]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
Ryuu
Member [заблокирован]

Откуда:
Сообщений: 545
кит северных морей, пример неудачный, старый прибит хинтами не был, кол-во данных сильно не менялось, хоть и немного увеличилось.

В любом случае, я вас понял. Я этим не занимался, мониторинг у нас документально закреплен за админами, как и его разбор. У нас вообще никто этим не занимался, из разработчиков. Во всяком случае, мне об этом неизвестно. Да и нужды не было. И да, я бы последовал вашему совету, но мне большое начальство уже сказало забить и ждать, чего они там придумают, а у меня и другие задачи есть. Это я уже после работы на форум зашел.
5 дек 18, 19:42    [21754880]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
DВА
Member

Откуда:
Сообщений: 5251
Ryuu
DВА, о, тогда может большая жирная жаба в этом болоте жизни скажет в чем причина?

за ваши деньги любой каприз )
5 дек 18, 19:47    [21754887]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
кит северных морей
Member

Откуда: Красноярск
Сообщений: 482
Ryuu,

я нигде не сказал, что это именно ваш случай. я привел абстрактный пример ситуации, в которой запрос начинает работать резко медленнее без изменения самого запроса и без видимых причин. таких ситуаций может быть масса. начинать разбираться с ними должен разработчик, а не админ. к админу я хожу, когда у меня dbms_stats.gather_table_stats падает со snapshot too old, или что-то подобное.
5 дек 18, 19:47    [21754888]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
Ryuu
Member [заблокирован]

Откуда:
Сообщений: 545
-2-, веришь нет, вообще наплевать. Если они откажутся от решения проблемы, то это их проблемы, не мои. Уж прости за тавтологию. И нет, никого я не доставал, как вам могло бы показаться, ведь в отличие от форума, послать кого-то на работе накуй или сказать, что он дебил, я к сожалению или счастью не могу, ибо не поймут. Да и воспитан я как-то иначе. Это здесь можно выплеснуть излишек эмоций, хотя я уже и успел пожалеть, что вообще создал данную тему. И да, я также понимаю, что я могу ошибаться и приводить неверные доводы, однако это не отменяет некоторых, скажем так, аспектов общения и того бреда, который мне пришлось прочесть, прежде, чем тема ушла дальше, в техподдержку.
5 дек 18, 19:49    [21754893]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 46356

Ryuu
план запроса я выложил, помогло? Нет.

А должно было? Все увидели самый дерьмовый план, который только можно представить. Все
поразились "а как ОНО вообще могло выполняться быстро". Все сказали "переписывай свой
запрос". Ты отказался. Конец истории.

Ryuu
То есть, по вашему, если запрос исправно работал несколько лет, а потом бац, и стал
выполняться вместо пары минут пару часов, это проблема разработчика?

Да. Ты в курсе "проблемы N+1"?

Posted via ActualForum NNTP Server 1.5

5 дек 18, 19:52    [21754899]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
Ryuu
Member [заблокирован]

Откуда:
Сообщений: 545
кит северных морей, как я уже сказал, я понимаю, что могу ошибаться. Однако, когда у меня запрос валиться на стадии связки двух таблиц, это явно не нормально. Пусть даже первая "таблица" это группа таблиц, а вторая это небольшой иерархический подзапрос. Причем связываю грамотно. Да, таблицы получились тяжелые. Но раньше такого дерьма не было. Уж простите за выражение. И со своей стороны я тупо бессилен что-либо изменить, ибо в том виде, как лежат данные в базе, я по другому их извлечь тупо не могу. Нет, конечно, можно потанцевать с бубном... но зачем? Когда я уже привел пример, что используя все те же данные, но связку делать по другому полю, которое имеет, скажем так, меньшую уникальность, все происходит замечательно? Логичный вывод, на мой скромный взгляд, что проблема в обработки большего кол-ва данных? В чем я не прав?

DВА, я в вас не сомневался. :)
5 дек 18, 19:57    [21754903]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
Ryuu
Member [заблокирован]

Откуда:
Сообщений: 545
Dimitry Sibiryakov, Вася, своё несомненно авторитетное мнение можешь засунуть себе в задницу.
5 дек 18, 20:00    [21754905]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
DВА
Member

Откуда:
Сообщений: 5251
Ryuu
к
DВА, я в вас не сомневался. :)

спасибо )
в отдельности спасибо за то, что не собираешься завязывать с программирование )
ибо только благодаря существованию таких разработчиков как ты, у меня всегда будет кусок хлеба ;) c маслом )
5 дек 18, 20:01    [21754908]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
Ryuu
Member [заблокирован]

Откуда:
Сообщений: 545
Dimitry Sibiryakov, и чтобы ты не обижался на несправедливость, мол как же так, я ему помочь хочу, а он меня ещё и посылает. Я же ничего такого не сказал. Так вот. Если у тебя есть несколько таблиц и ты их можешь связать по индексу, ты их связываешь. Если есть какие-то ещё условия, ты их выставляешь. Ничего сверхъестественного или сложного в запросе нет. Обычная связка. Абсолютно обычная. И если тебе в связке нескольких таблиц план видится дерьмовым, извини, но напиши лучше, я посмотрю. Мне вот даже интересно, как диванный эксперт свяжет две таблицы. Скажем, в одной миллион строк и есть поле ключ, в другой тоже миллион строк и тоже поле ключ. Скажи, если не по ключу, то как? Несомненно твоя гениальная идея будет лучше этого дерьмового плана.
5 дек 18, 20:04    [21754910]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
Ryuu
Member [заблокирован]

Откуда:
Сообщений: 545
DВА, рад за тебя, наверняка, ты не только гений программирования, но и вообще гений, раз смог так легко составить мнение о человеке и его навыках. Только не лопни от чувства собственной важности, я о тебе переживаю.
5 дек 18, 20:07    [21754913]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
DВА
Member

Откуда:
Сообщений: 5251
Ryuu
Dimitry Sibiryakov, и чтобы ты не обижался на несправедливость, мол как же так, я ему помочь хочу, а он меня ещё и посылает. Я же ничего такого не сказал. Так вот. Если у тебя есть несколько таблиц и ты их можешь связать по индексу, ты их связываешь. Если есть какие-то ещё условия, ты их выставляешь. Ничего сверхъестественного или сложного в запросе нет. Обычная связка. Абсолютно обычная. И если тебе в связке нескольких таблиц план видится дерьмовым, извини, но напиши лучше, я посмотрю. Мне вот даже интересно, как диванный эксперт свяжет две таблицы. Скажем, в одной миллион строк и есть поле ключ, в другой тоже миллион строк и тоже поле ключ. Скажи, если не по ключу, то как? Несомненно твоя гениальная идея будет лучше этого дерьмового плана.


а тебе точно нужно получить в исходном запросе весь миллион строк ?
5 дек 18, 20:09    [21754917]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
Ryuu
Member [заблокирован]

Откуда:
Сообщений: 545
DВА, прикинь да. Они ограничиваются данными, что в подзапросе (та иерархическая лабуда), вот только при связке с ним в настоящий момент всё отваливается. Под отваливается я подразумеваю, что запрос начинает работать слишком долго, когда раньше было ок.
5 дек 18, 20:11    [21754920]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
Ryuu
Member [заблокирован]

Откуда:
Сообщений: 545
Ryuu
DВА, прикинь да. Они ограничиваются данными, что в подзапросе (та иерархическая лабуда), вот только при связке с ним в настоящий момент всё отваливается. Под отваливается я подразумеваю, что запрос начинает работать слишком долго, когда раньше было ок.

Ну и лайк тоже ограничения накладывает. И нет, заменить лайк на что-то другое нельзя.
5 дек 18, 20:12    [21754922]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
кит северных морей
Member

Откуда: Красноярск
Сообщений: 482
Ryuu,

вы ДУМАЕТЕ, что запрос валится на связке двух таблиц, и ДУМАЕТЕ, что связываете их грамотно. узнать, на чем НА САМОМ ДЕЛЕ валится запрос, правильно ли они связаны, и что вообще происходит в БД, можно только изучив фактический (а не ожидаемый, который вы показали) план выполнения, и затраты ресурсов на каждый шаг.

вот вы утверждаете, что вы связали две таблицы. это не так. вы связали две inline view. при построении плана оптимизатор делает view merging - то есть, грубо говоря, выдергивает содержимое из ваших псевдотаблиц, и перемешивает в том порядке, который ему покажется оптимальным, не нарушая логики запроса. и если в тексте запроса ваша my_pc присоединяется последней, и как отдельная сущность - совершенно не обязательно, что при выполнении запроса оракл именно так и сделает.
5 дек 18, 20:13    [21754926]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
DВА
Member

Откуда:
Сообщений: 5251
Ryuu
DВА, рад за тебя, наверняка, ты не только гений программирования, но и вообще гений, раз смог так легко составить мнение о человеке и его навыках. Только не лопни от чувства собственной важности, я о тебе переживаю.

я очень, очень сомневающийся человек ))
поэтому до последнего надеялась, что в твою светлую голову прискачет мысль - "а может я не с того конца пытаюсь проблему решить"
но нет, не этот раз ))
возможно навыки "в области балета" у тебя и запредельные, но в оптимизации запросов ты даже не ноль, ты минус адын )
5 дек 18, 20:13    [21754927]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
DВА
Member

Откуда:
Сообщений: 5251
Ryuu
DВА, прикинь да. Они ограничиваются данными, что в подзапросе (та иерархическая лабуда), вот только при связке с ним в настоящий момент всё отваливается. Под отваливается я подразумеваю, что запрос начинает работать слишком долго, когда раньше было ок.


ну тогда от нашего стола вашему )
погугли хинт cardinality и пририсуй кардинальность своей лабуде, чтобы основной запрос считал, что оттуда прилетит не так уж и много
5 дек 18, 20:16    [21754931]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 46356

Ryuu
Мне вот даже интересно, как диванный эксперт свяжет две таблицы. Скажем, в одной миллион
строк и есть поле ключ, в другой тоже миллион строк и тоже поле ключ. Скажи, если не по
ключу, то как?

В твоём плане "FULL TABLE SCAN" и большая куча вложенных "NESTED LOOP" совсем-совсем не
выглядят на "связывание по ключу".

Posted via ActualForum NNTP Server 1.5

5 дек 18, 20:21    [21754939]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
Ryuu
Member [заблокирован]

Откуда:
Сообщений: 545
Dimitry Sibiryakov, а я знаю, почему он так себя вести начал? У меня нет таблиц, которые НЕ связаны по ключу.

кит северных морей, вы абсолютно правы. Но фишка в том, что фактического плана я от админов не добился, сам его получить не могу. Возможно, мог, если бы разбирался в этой теме чуть лучше. Но уже поезд уехал и разбираться дальше я в этой проблеме не буду. Эта обязанность висит не на мне. Да, вас это может возмущать, но у нас это так.

DВА, мне так важна твоя оценка, я почти прослезился. И нет, мне приходила в голову мысль о том, чтобы переписать запрос. Вот только моё начальство мне время на это не даст. Да и почему я должен это делать? Считайте, что я уперся рогом, и пока админы не докажут, что проблема НЕ на их стороне, делать что-либо со своим запросом я не буду. Да и связывать как-то по другому, грубо говоря, это просто перебор вариантов.

И да, хинты у нас не работают. Прелесть, да? Всё, я ушел.
5 дек 18, 20:24    [21754942]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
кит северных морей
Member

Откуда: Красноярск
Сообщений: 482
Ryuu
Эта обязанность висит не на мне. Да, вас это может возмущать, но у нас это так.
мне абсолютно всё равно, на ком в вашей организации висит эта обязанность, поверьте. я просто пытался вас натолкнуть на чуть более правильный ход мыслей при решении данных проблем, чтобы в следующий раз, случись он, вы лучше представляли, что нужно делать. судя по всему, получилось плохо :)
5 дек 18, 20:28    [21754945]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
mefman
Member

Откуда:
Сообщений: 2317
кит северных морей,
Вообще не получилось.))
5 дек 18, 20:50    [21754971]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
Ryuu
Member [заблокирован]

Откуда:
Сообщений: 545
кит северных морей, вы простите меня, пожалуйста. Я понимаю, что веду себя... несдержанно. У меня от данной проблемы изжога, метафорически говоря. Началось всё с общения с админами, вернее с одним конкретным индивидуумом. А потому и на колкие замечания реагирую, как оказалось, остро. Я сейчас даже не вас имею ввиду. Фактический план запроса я просил в своё время (пока проблема не ушла дальше), мне его не предоставили. С сегодняшнего дня, или лучше сказать, вчерашнего вечера, эта проблема уже не моя. И всё это скатилось... впрочем, вы прекрасно видите, во что это скатилось.
5 дек 18, 20:53    [21754978]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
AlexFF__|
Member

Откуда:
Сообщений: 2814
кит северных морей
Ryuu,
просевшая производительность запроса - это проблема разработчика, пока не доказано обратное...

Нет, просевший запрос - это проблема бизнеса.
И тут либо у dba есть адекватный мониторинг и они его сами отловят, либо бизнес поднимет инцидент.
И тут нет виноватых по умолчанию, может и железо виновато и кривой запрос и хайсизон в конце концов.

НО, в большинстве случаев, первичный анализ проблемы делают dba, по той простой причине, что разработчики, опять же в большинстве случаев, не имеют доступа к боевой БД.
А админы должны уметь находить причину. Не устранять ее, а именно находить. Хотя бы "план поменялся", если возможно, то почему.

И если бы у нас запрос, который не менялся, стал работать хуже, то наши вменяемые админы скинули бы мне полный анализ ситуации (просто выполнив определенный набор скриптов), а я бы уже смотрел, стоит ли разрабам переделывать запрос, либо просто дать им четкие рекомендации.

А то, что происходит у ТС, это простое отфутболивание проблемы, начатое админами.
Серьезно, я даже не могу представить, чтобы в серьезной организации, админы могли просто отписаться "ваш запрос стал медленно работать".
Это как профессиональный тестировщик описывал проблему "ваша программа не работает".
5 дек 18, 21:17    [21755009]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
-2-
Member

Откуда:
Сообщений: 14095
План получить сам ты не в состоянии, пеняешь на параметр сессии, который тоже изменить не умеешь. При таких компетенциях предъявляешь публике претензии к своим админам.
Пришел попалкаться на форум, может кто посочувствует. А тут такое...
5 дек 18, 21:17    [21755010]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
Ryuu
Member [заблокирован]

Откуда:
Сообщений: 545
-2-, увы и ах, я надеялся исключительно на то, что с минимальной информацией с моей стороны мне кто-нибудь подскажет что-то дельное, т.е. уже сталкивался с чем-то подобным или предполагает... что-то конкретное. Но, повторюсь, я уже сто раз пожалел, что создал здесь тему, тем более, что она с сегодняшнего дня и вовсе перестала быть актуальной. Сам не знаю, почему до сих пор здесь. И ваше "не умею" отнюдь не равно моему "не имею возможности".
5 дек 18, 21:37    [21755030]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
-2-
Member

Откуда:
Сообщений: 14095
Ryuu
И ваше "не умею" отнюдь не равно моему "не имею возможности".
Поручили решать вопрос с производительностью, а доступа к БД не дали?
5 дек 18, 21:57    [21755047]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
кит северных морей
Member

Откуда: Красноярск
Сообщений: 482
AlexFF__|,

я не думаю, что у админа, на группe которого могут висеть десятки или сотни БД, есть желание (и даже обязанность) разбираться именно с бизнес-инцидентами в каждой из них - для этого нужно иметь хотя бы поверхностное представление о бизнес-процессах в этих БД, без этого никакой мониторинг не поможет.

у нас инцидент от бизнеса сначала идет в application support, дальше - как правило, прикладной разработчик-владелец кода, еще дальше - DB dev team с расширенным read-only доступом в продуктив (я), и только потом DBA.

плюс, запросы ломаются не только на проде. есть, например, несколько препродуктивных сред, на которых в условиях нагрузки, приближенной к боевой, обкатываются доработки после первоначального тестирования. там может твориться что угодно, и на каждый чих админа не выдернешь - надо разбираться самим.
5 дек 18, 22:05    [21755060]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
кит северных морей
Member

Откуда: Красноярск
Сообщений: 482
Ryuu
т.е. уже сталкивался с чем-то подобным или предполагает... что-то конкретное.

поставьте сюда no_merge. вдруг поможет (я не знаю, что вы имели в виду, когда сказали, что хинты не работают).
  (-- Информация по входимости.
    SELECT /*+no_merge*/
      lvl,
      root_part_aid,
5 дек 18, 22:14    [21755066]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
AlexFF__|
Member

Откуда:
Сообщений: 2814
кит северных морей
AlexFF__|,
я не думаю, что у админа, на группe которого могут висеть десятки или сотни БД, есть желание (и даже обязанность)
...
у нас инцидент от бизнеса сначала идет в application support, дальше - как правило, прикладной разработчик-владелец кода, еще дальше - DB dev team с расширенным read-only доступом в продуктив (я), и только потом DBA.

Инцидент уже прошел саппорт, анализ разработки и пришел к одному запросу (или сами админы нашли его).
Сбор данных для определения причины это именно обязанность админа (в твоем случае DB dev team с расширенным read-only доступом).
Как я уже говорил, этот сбор дело несколько минут и одного нажатия кнопки для запуска скриптов.
А далее уже дело разработчиков.
Так что это, как ты и написал, отсутствие желания. + недоработка начальства.
5 дек 18, 22:26    [21755079]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
MaximaXXL
Member

Откуда: Киев
Сообщений: 635
Ryuu,

Вам очень повезло с начальником, который может просто сказать: - Не работает? Это не твоя проблемма.
Был были бы Вы у меня: - Не работает? Разберись и почини. Не хочешь разбираться? Подними постановку, напиши новый и закрой кейс.

Мы к админам ходим просить данные на которых нет прав - те же планы на проде.
Есть тесты, бизнес тесты, стендбай на крайняк ... найди где он работает быстро и сравни планы ...

А постановка вопроса: - Я один раз написал и больше переписывать не буду (или как-то так), не относит Вас к разряду думающих программистов .
Если запрос нестабилен - его надо лечить и это не задача админа.

Я Вам предлагал подумать, что стоит его переписать. Да - это может Ваше детище и Вы за "это" даже может премию получили, но план показывает что там есть что править.
5 дек 18, 22:37    [21755093]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
кит северных морей
Member

Откуда: Красноярск
Сообщений: 482
AlexFF__|,

как обычно, расхождения в терминологии всё спутали. я под "админами" обычно подразумеваю т.н. prod DBA, и ковыряться в запросах конкретной системы - всё-таки не их задача.

а в такой формулировке (если "админ" - это специализированный разраб БД / dev DBA) - да, согласен, разве что мы не только информацию собираем, но и даем конкретные рекомендации, т.к. тоже знаем систему изнутри.
5 дек 18, 23:11    [21755112]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 46356

Ryuu
а я знаю, почему он так себя вести начал?

Должен бы знать. Ведь это твоя база, ты знаешь таблицы, ты знаешь какие на них есть
индексы и когда пересчитывалась их статистика, ты знаешь как работает твой запрос, какие
методы доступа он может использовать и какие будут оптимальны на данном объёме данных. Или
ты таки ничего из этого не знаешь?..

Posted via ActualForum NNTP Server 1.5

5 дек 18, 23:33    [21755127]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
feagor
Member

Откуда: Москва
Сообщений: 144
Dimitry Sibiryakov,

Понаписали говнокода, разбираться не хотят, какой смысл вообще с такими вести диалог?
6 дек 18, 00:47    [21755173]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
xtender
Member

Откуда: Мск
Сообщений: 4959
начал было писать детальный разбор, но потом мысль о бессмысленности оного победила и на 5-м пункте бросил. Не вижу смысла помогать, если человек в принципе думать не хочет.




кит северных морей
Ryuu
т.е. уже сталкивался с чем-то подобным или предполагает... что-то конкретное.

поставьте сюда no_merge. вдруг поможет (я не знаю, что вы имели в виду, когда сказали, что хинты не работают).
  (-- Информация по входимости.
    SELECT /*+no_merge*/
      lvl,
      root_part_aid,
не поможет, т.к. во-первых изначально по плану видно, что оно не мерджится, а во-вторых, это ожидаемо, т.к. там внутри мало того, что деревяшка, так еще и прибита сверху аналитикой
6 дек 18, 01:10    [21755180]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
xtender
Member

Откуда: Мск
Сообщений: 4959
с другой стороны, если кому-то такое покажется интересным, то можно на следующем митапе RuOUG рассмотреть как пример "как не надо делать"
6 дек 18, 01:13    [21755181]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
кит северных морей
Member

Откуда: Красноярск
Сообщений: 482
xtender
не поможет, т.к. во-первых изначально по плану видно, что оно не мерджится, а во-вторых, это ожидаемо, т.к. там внутри мало того, что деревяшка, так еще и прибита сверху аналитикой

и правда. я портянку внимательно не читал

ну, значит не судьба.
6 дек 18, 01:40    [21755183]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
Ryuu
Member [заблокирован]

Откуда:
Сообщений: 545
кит северных морей, как и сказали, не помогло. Что же до десятков и сотен БД, отнюдь. Даже, если считать тестовые и прочие вариации, их не наберётся и десяти, и ими занимается группа админов, а не один человек.

-2-, да, к БД я полноценного доступа не имею. Разбираться нужно было совместно, в итоге разбирался один, пока запрос не ушел далее. Так как другая сторона напрочь не хотела вникнуть в проблему.

MaximaXXL, да, с начальником мне повезло, здесь я спорить не буду. Однако вопроса о переписке запроса не стояло. Работа с SQL лишь часть моих обязанностей, сейчас я уже переключился на другую задачу. Да и на момент активного обсуждения темы, вопрос уже перестал быть актуален (проблема ушла в РДТЕХ).
И согласитесь, если бы у вас случилась подобная ситуация, вы бы захотели разобраться в причине, а не тупо обвинили бы разработчика и заставили бы его переписывать код. В противном случае, я сочувствую вашим подчиненным. Что же до моей ситуации, то разобраться без помощи админов я не мог. Помощи не было, лишь желание спихнуть задачу и откреститься от проблемы. Причем здесь моё нежелание?

Dimitry Sibiryakov, разумеется, я все вышеупомянутое знал. Однако, когда в один день "ломается" связка таблиц, которая исправно работала несколько лет, сказать в чем причина сложно. И бездумно кидаться переписывать запрос, последнее дело.

xtender, я бы помог, но нет, не помогу. Спасибо. Над такими комментариями действительно думать не хочется. Но всё же, интереса ради, что вы подразумеваете под деревяшкой?
6 дек 18, 08:34    [21755311]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
123йй
Member

Откуда:
Сообщений: 1446
Ryuu
Но всё же, интереса ради, что вы подразумеваете под деревяшкой?

так и вертится на языке не верный ответ
6 дек 18, 09:12    [21755325]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
-2-
Member

Откуда:
Сообщений: 14095
Ryuu
к БД я полноценного доступа не имею.
Опять ходишь вокруг да около. Излагай факты а не литературные домыслы. Неполноценным доступ к БД можно назвать, если он через приложение, где из функций доступно только нажать кнопку "получить отчет". Доступ можно ограничить и через sql, особые политики наворачивают на общедоступных сервисах типа sqlfiddle или livesql. Но даже на livesql можно посмотреть план и установить политику и размер области сортировки.
6 дек 18, 09:58    [21755381]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
DВА
Member

Откуда:
Сообщений: 5251
xtender
начал было писать детальный разбор, но потом мысль о бессмысленности оного победила и на 5-м пункте бросил. Не вижу смысла помогать, если человек в принципе думать не хочет.


из двух выцепленных из общего бреда автора фраз, что фильтрация идет по результатам иерархического запроса и

Ryuu
Хочу заметить, что если в связки я заменю my_pc.root_part_aid на my_pc.root_proj_aid, где уникальность значительно меньше, следовательно, как и самих данных, всё работает, как и раньше, то есть быстро


все-таки ставлю на хинт cardinality ))
6 дек 18, 10:54    [21755492]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
DВА
Member

Откуда:
Сообщений: 5251
xtender
с другой стороны, если кому-то такое покажется интересным, то можно на следующем митапе RuOUG рассмотреть как пример "как не надо делать"

ой я те материалу-то накидаю ))))
6 дек 18, 11:04    [21755511]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
env
Member

Откуда: Россия, Москва
Сообщений: 5916
Ryuu
И мне, конечно, хотелось бы разобраться в проблеме


Не увидел ни одной попытки, только попытка перевалить проблему говнокода на сторону админов. Вы же протестировали, как поменяются планы остальных запросов при смене параметра БД, правда же?
Ryuu
В любом случае, я разобрался

Соберись, что ли...

Ryuu
Да и воспитан я как-то иначе

Воспитание, если оно есть, предполагает, что человек не будет слать матом ни на форуме, ни в жизни. Иначе это всего лишь боязнь ответственности за свои слова в реале. Так что и тут ошибся.


Ryuu
Обычная связка. Абсолютно обычная.

Критерии обычности приведите. У аборигенов Новой Зеландии обычным до сих пор считается сожрать соседа, например. Для алкаша, обычным считается нагадить в подъезде и считать, что это проблема жильцов и уборщицы.
6 дек 18, 12:33    [21755651]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 46356

Ryuu
к БД я полноценного доступа не имею.

Насколько неполноценен твой доступ? Ты не в состоянии послать запрос к системным вьюхам
чтобы проверить наличие и статус нужных твоему запросу индексов?

Ryuu
разумеется, я все вышеупомянутое знал.

Так почему написал запрос, который совершенно не использует индексы? Вредитель? Мазохист?..

Ryuu
Однако, когда в один день "ломается" связка таблиц,
которая исправно работала несколько лет, сказать в чем причина сложно.

То есть для тебя знать задуманный собой способ выполнения запроса и найти отличие от
реального - сложно? В детском саду есть такое упражнение для развития мозга: "найди 10
отличий между картинками". Стоило больше тренироваться, наверное.

Posted via ActualForum NNTP Server 1.5

6 дек 18, 13:38    [21755751]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
xtender
Member

Откуда: Мск
Сообщений: 4959
DВА
все-таки ставлю на хинт cardinality ))
охъ, все таки вынуждаешь ответить полнее...
1. я оооочень сомневаюсь, что повлияло изменение кардинальности подзапроса с деревяшкой(MY_PC), если это эксплейн с продуктивной базы, то врядли изменение до 3364 могло оказать такое воздействие. Гораздо более вероятно, что повлияло изменение статистик по TP_ZAG/TP_ZAG_XXX, в больше степени влияющих на получение запредельных E-ROWS=205G
2. да, конечно, можно обойтись одним хинтом cardinality, но воткнуть таких хинтов придется много и текущей информации слишком мало, чтобы выставить правильные/подходящие значения везде
3. с точки зрения упрощения задачи, даже при отсутствии плана в AWR или отсутствии пака(судя по тому, что они используют partitioning views, врядли у них приобретены diagnostics+tuning), можно просто вернуть/посмотреть старую статистику и получить старый план
4. если уж не менять запрос, то я бы предпочел полноценно хинтовать(или закреплять профилем), то есть полным и однозначным набором хинтов: leading+use_xxx+index/full и тд
5. тексты вьюх, предикаты, алиасы и проекции не приведены, и без этой информации нормально проанализировать не получится, например
5.1 в части
        FROM
          (
            SELECT
              part_aid,
              proj_aid,
              count_pc,
              vargrp,
              varnum
            FROM
              sysdba.pc pc,
              zebra.zebra_all_sect zas,
              sysdba.articles art
            WHERE
              pc.part_aid       = zas.art_id
            AND zas.otr_konstr IS NOT NULL
            AND SN NOT         IN (1, 148)
            AND pc.proj_aid     =art.art_id
            AND pc.proj_ver_id  = art.art_ver_id
          )
          START WITH part_aid      IS NOT NULL
        AND vargrp                  = 0
        AND varnum                  = 0
          CONNECT BY PRIOR proj_aid = part_aid
      )

непонятно из какой таблицы берутся vargrp, varnum, SN
5.2 каковы предикаты внутри ZEBRA_ALL_SECT
5.3 откуда там outer джойны, группировки, сортировки - в предоставленном запросе их нет. Это особенно хорошо видно, если схлопнуть MY_PC и ZEBRA_ALL_SECT в плане
+
 | Id  | Operation                                                    | Name                   | E-Rows |E-Bytes|E-Temp | Cost (%CPU)| E-Time   |  OMem |  1Mem | Used-Mem | Used-Tmp|
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                                             |                        |        |       |       |    13G(100)|          |       |       |          |         |
|   1 |  SORT AGGREGATE                                              |                        |      1 |       |       |            |          |       |       |          |         |
|   2 |   CONNECT BY WITHOUT FILTERING                               |                        |        |       |       |            |          |  2048 |  2048 | 2048  (0)|         |
|   3 |    FAST DUAL                                                 |                        |      1 |       |       |     2   (0)| 00:00:01 |       |       |          |         |
|   4 |  SORT ORDER BY                                               |                        |    205G|   403T|   509T|    13G  (1)|142:25:29 |    30M|  1999K|   27M (0)|         |
|   5 |   HASH UNIQUE                                                |                        |    205G|   403T|   509T|  6563M  (1)| 71:13:15 |    41M|  3851K|          |         |
|*  6 |    HASH JOIN RIGHT OUTER                                     |                        |    205G|   403T|       |  1518K (66)| 00:01:00 |  6271K|  1761K| 3615K (0)|         |
|   7 |     VIEW                                                     |                        |  54924 |  1072K|       | 16926   (2)| 00:00:01 |       |       |          |         |
|   8 |      HASH UNIQUE                                             |                        |  54924 |  5310K|  6112K| 16926   (2)| 00:00:01 |  7690K|  3198K| 5554K (0)|         |
|*  9 |       HASH JOIN                                              |                        |  54924 |  5310K|  7280K| 15895   (2)| 00:00:01 |    16M|  3954K|   20M (0)|         |
|* 10 |        FILTER                                                |                        |        |       |       |            |          |       |       |          |         |
|* 11 |         HASH JOIN RIGHT OUTER                                |                        |  85683 |  6275K|       | 10877   (2)| 00:00:01 |  2091K|  1761K| 2346K (0)|         |
|* 12 |          TABLE ACCESS BY INDEX ROWID                         | TP_ZAG_D               |  17910 |   472K|       |  3250   (1)| 00:00:01 |       |       |          |         |
|* 13 |           INDEX RANGE SCAN                                   | TP_ZAG_D_F_ENTITY      |  18608 |       |       |    45   (0)| 00:00:01 |       |       |          |         |
|* 14 |          HASH JOIN                                           |                        |    128K|  6001K|  2280K|  7626   (2)| 00:00:01 |  6448K|  2024K| 8783K (0)|         |
|  15 |           VIEW                                               |                        |  52888 |  1652K|       |  5396   (2)| 00:00:01 |       |       |          |         |
|* 16 |            FILTER                                            |                        |        |       |       |            |          |       |       |          |         |
|* 17 |             FILTER                                           |                        |        |       |       |            |          |       |       |          |         |
|* 18 |              HASH JOIN OUTER                                 |                        |  52888 |  1910K|  3184K|  5396   (2)| 00:00:01 |  7894K|  2748K| 8797K (0)|         |
|* 19 |               TABLE ACCESS FULL                              | TP_ZAG                 |    148K|  1445K|       |   533   (2)| 00:00:01 |       |       |          |         |
|* 20 |               TABLE ACCESS FULL                              | TP_ZAG_D               |    109K|  2892K|       |  4769   (2)| 00:00:01 |       |       |          |         |
|* 21 |           TABLE ACCESS FULL                                  | TC_OBJ2LINK            |   1299K|    19M|       |  1750   (2)| 00:00:01 |       |       |          |         |
|* 22 |        TABLE ACCESS FULL                                     | TP_ZAG_D               |    344K|  8067K|       |  4775   (2)| 00:00:01 |       |       |          |         |
|  23 |     VIEW                                                     |                        |   3914M|  7812G|       |   527K  (4)| 00:00:21 |       |       |          |         |
|* 24 |      HASH JOIN OUTER                                         |                        |   3914M|    12T|   699M|   527K  (4)| 00:00:21 |    25M|  4046K|   27M (0)|         |
|  25 |       VIEW                                                   |                        |    527K|   693M|       | 47155   (1)| 00:00:02 |       |       |          |         |
|  26 |        HASH UNIQUE                                           |                        |    527K|   156M|   171M| 47155   (1)| 00:00:02 |    53M|  3790K|          |         |
|  27 |         NESTED LOOPS                                         |                        |    527K|   156M|       | 17822   (2)| 00:00:01 |       |       |          |         |
|  28 |          NESTED LOOPS                                        |                        |     42 | 11676 |       | 17780   (2)| 00:00:01 |       |       |          |         |
|  29 |           NESTED LOOPS                                       |                        |     42 | 11382 |       | 17696   (2)| 00:00:01 |       |       |          |         |
|  30 |            NESTED LOOPS                                      |                        |     34 |  8772 |       | 17594   (2)| 00:00:01 |       |       |          |         |
|  31 |             NESTED LOOPS                                     |                        |     28 |  6832 |       | 17510   (2)| 00:00:01 |       |       |          |         |
|  32 |              NESTED LOOPS OUTER                              |                        |     28 |  6160 |       | 17454   (2)| 00:00:01 |       |       |          |         |
|* 33 |               HASH JOIN                                      |                        |     26 |  5018 |       | 17376   (2)| 00:00:01 |  2047M|    95M|   79M (1)|      16M|
|  34 |                NESTED LOOPS                                  |                        |        |       |       |            |          |       |       |          |         |
|  35 |                 NESTED LOOPS                                 |                        |   1414 |   233K|       | 15940   (1)| 00:00:01 |       |       |          |         |
|* 36 |                  HASH JOIN                                   |                        |    921 |   130K|       | 13488   (1)| 00:00:01 |  2047M|    50M|   79M (1)|         |
|* 37 |                   HASH JOIN                                  |                        |   1174 |   139K|       | 11599   (1)| 00:00:01 |    11G|   297M|   49M (1)|      42M|
|  38 |                    JOIN FILTER CREATE                        | :BF0000                |   4829 |   476K|       |  7815   (2)| 00:00:01 |       |       |          |         |
|* 39 |                     HASH JOIN                                |                        |   4829 |   476K|       |  7815   (2)| 00:00:01 |   114M|  9197K|  137M (0)|         |
|* 40 |                      HASH JOIN                               |                        |    394 | 33490 |       |  6059   (1)| 00:00:01 |    55M|  6638K|   76M (0)|         |
|  41 |                       VIEW                                   | {MY_PC}                |   3364 |   157K|       |  4677   (2)| 00:00:01 |       |       |          |         |
|  94 |                       VIEW                                   | ZEBRA_ALL_SECT         |  26654 |   963K|       |  1382   (1)| 00:00:01 |       |       |          |         |
|*138 |                      TABLE ACCESS FULL                       | TC_OBJ2LINK            |   1299K|    19M|       |  1750   (2)| 00:00:01 |       |       |          |         |
| 139 |                    VIEW                                      |                        |    130K|  2676K|       |  3784   (1)| 00:00:01 |       |       |          |         |
|*140 |                     FILTER                                   |                        |        |       |       |            |          |       |       |          |         |
| 141 |                      JOIN FILTER USE                         | :BF0000                |    130K|  4716K|       |  3784   (1)| 00:00:01 |       |       |          |         |
|*142 |                       HASH JOIN RIGHT OUTER                  |                        |    130K|  4716K|       |  3784   (1)| 00:00:01 |  2091K|  1761K| 2290K (0)|         |
|*143 |                        TABLE ACCESS BY INDEX ROWID           | TP_ZAG_D               |  17910 |   472K|       |  3250   (1)| 00:00:01 |       |       |          |         |
|*144 |                         INDEX RANGE SCAN                     | TP_ZAG_D_F_ENTITY      |  18608 |       |       |    45   (0)| 00:00:01 |       |       |          |         |
|*145 |                        TABLE ACCESS FULL                     | TP_ZAG                 |    148K|  1445K|       |   533   (2)| 00:00:01 |       |       |          |         |
|*146 |                   TABLE ACCESS FULL                          | TP_ZAG_S               |    102K|  2299K|       |  1888   (1)| 00:00:01 |       |       |          |         |
|*147 |                  INDEX RANGE SCAN                            | TP_ZAG_D_F_PARENTKEY   |     18 |       |       |     2   (0)| 00:00:01 |       |       |          |         |
|*148 |                 TABLE ACCESS BY INDEX ROWID                  | TP_ZAG_D               |      2 |    48 |       |     3   (0)| 00:00:01 |       |       |          |         |
| 149 |                VIEW                                          | ZEBRA_ALL_SECT         |   8181 |   191K|       |  1437   (5)| 00:00:01 |       |       |          |         |
|*182 |               TABLE ACCESS BY INDEX ROWID                    | TP_ZAG_D               |      1 |    27 |       |     3   (0)| 00:00:01 |       |       |          |         |
|*183 |                INDEX RANGE SCAN                              | TP_ZAG_D_F_PARENTKEY   |     18 |       |       |     2   (0)| 00:00:01 |       |       |          |         |
| 184 |              TABLE ACCESS BY INDEX ROWID                     | ARTICLES               |      1 |    24 |       |     2   (0)| 00:00:01 |       |       |          |         |
|*185 |               INDEX UNIQUE SCAN                              | ARTICLES_PRIM_NDX      |      1 |       |       |     1   (0)| 00:00:01 |       |       |          |         |
|*186 |             TABLE ACCESS BY INDEX ROWID                      | TP_ZAG_S               |      1 |    14 |       |     3   (0)| 00:00:01 |       |       |          |         |
|*187 |              INDEX RANGE SCAN                                | TP_ZAG_S_F_PARENTKEY   |      3 |       |       |     2   (0)| 00:00:01 |       |       |          |         |
|*188 |            TABLE ACCESS BY INDEX ROWID                       | TP_ZAG_F               |      1 |    13 |       |     3   (0)| 00:00:01 |       |       |          |         |
|*189 |             INDEX RANGE SCAN                                 | TP_ZAG_F_F_PARENTKEY   |      2 |       |       |     2   (0)| 00:00:01 |       |       |          |         |
|*190 |           TABLE ACCESS BY INDEX ROWID                        | ARTICLES               |      1 |     7 |       |     2   (0)| 00:00:01 |       |       |          |         |
|*191 |            INDEX UNIQUE SCAN                                 | ARTICLES_PRIM_NDX      |      1 |       |       |     1   (0)| 00:00:01 |       |       |          |         |
| 192 |          VIEW                                                | ZEBRA_ALL_SECT         |  12647 |   419K|       |     1   (0)| 00:00:01 |       |       |          |         |
| 236 |       VIEW                                                   |                        |   7847K|    14G|       |   260K  (1)| 00:00:11 |       |       |          |         |
| 237 |        SORT GROUP BY                                         |                        |   7847K|  1167M|  1251M|   260K  (1)| 00:00:11 |  7636K|  1177K| 6787K (0)|         |
|*238 |         HASH JOIN RIGHT OUTER                                |                        |   7847K|  1167M|       | 35960   (2)| 00:00:02 |  6271K|  1761K| 6696K (0)|         |
| 239 |          VIEW                                                |                        |  54924 |  1072K|       | 16926   (2)| 00:00:01 |       |       |          |         |
| 240 |           HASH UNIQUE                                        |                        |  54924 |  5310K|  6112K| 16926   (2)| 00:00:01 |  7690K|  3198K| 5559K (0)|         |
|*241 |            HASH JOIN                                         |                        |  54924 |  5310K|  7280K| 15895   (2)| 00:00:01 |    16M|  3954K|   20M (0)|         |
|*242 |             FILTER                                           |                        |        |       |       |            |          |       |       |          |         |
|*243 |              HASH JOIN RIGHT OUTER                           |                        |  85683 |  6275K|       | 10877   (2)| 00:00:01 |  2091K|  1761K| 2319K (0)|         |
|*244 |               TABLE ACCESS BY INDEX ROWID                    | TP_ZAG_D               |  17910 |   472K|       |  3250   (1)| 00:00:01 |       |       |          |         |
|*245 |                INDEX RANGE SCAN                              | TP_ZAG_D_F_ENTITY      |  18608 |       |       |    45   (0)| 00:00:01 |       |       |          |         |
|*246 |               HASH JOIN                                      |                        |    128K|  6001K|  2280K|  7626   (2)| 00:00:01 |  6448K|  2024K| 8744K (0)|         |
| 247 |                VIEW                                          |                        |  52888 |  1652K|       |  5396   (2)| 00:00:01 |       |       |          |         |
|*248 |                 FILTER                                       |                        |        |       |       |            |          |       |       |          |         |
|*249 |                  FILTER                                      |                        |        |       |       |            |          |       |       |          |         |
|*250 |                   HASH JOIN OUTER                            |                        |  52888 |  1910K|  3184K|  5396   (2)| 00:00:01 |  7894K|  2748K| 8797K (0)|         |
|*251 |                    TABLE ACCESS FULL                         | TP_ZAG                 |    148K|  1445K|       |   533   (2)| 00:00:01 |       |       |          |         |
|*252 |                    TABLE ACCESS FULL                         | TP_ZAG_D               |    109K|  2892K|       |  4769   (2)| 00:00:01 |       |       |          |         |
|*253 |                TABLE ACCESS FULL                             | TC_OBJ2LINK            |   1299K|    19M|       |  1750   (2)| 00:00:01 |       |       |          |         |
|*254 |             TABLE ACCESS FULL                                | TP_ZAG_D               |    344K|  8067K|       |  4775   (2)| 00:00:01 |       |       |          |         |
| 255 |          VIEW                                                |                        |    149K|    19M|       | 18997   (2)| 00:00:01 |       |       |          |         |
| 256 |           HASH UNIQUE                                        |                        |    149K|    14M|    16M| 18997   (2)| 00:00:01 |  4775K|  1274K| 3024K (0)|         |
|*257 |            FILTER                                            |                        |        |       |       |            |          |       |       |          |         |
|*258 |             HASH JOIN RIGHT OUTER                            |                        |    149K|    14M|       | 16051   (2)| 00:00:01 |  2091K|  1761K| 2341K (0)|         |
|*259 |              TABLE ACCESS BY INDEX ROWID                     | TP_ZAG_D               |  17910 |   472K|       |  3250   (1)| 00:00:01 |       |       |          |         |
|*260 |               INDEX RANGE SCAN                               | TP_ZAG_D_F_ENTITY      |  18608 |       |       |    45   (0)| 00:00:01 |       |       |          |         |
|*261 |              HASH JOIN                                       |                        |    170K|    12M|    11M| 12801   (2)| 00:00:01 |    20M|  3646K|   22M (0)|         |
|*262 |               TABLE ACCESS FULL                              | TP_ZAG_D               |    344K|  8067K|       |  4775   (2)| 00:00:01 |       |       |          |         |
|*263 |               HASH JOIN                                      |                        |    265K|    13M|  5256K|  7663   (2)| 00:00:01 |  3562K|  2193K| 3050K (0)|         |
|*264 |                HASH JOIN                                     |                        |    109K|  3963K|  3184K|  5396   (2)| 00:00:01 |  7894K|  2748K| 8745K (0)|         |
|*265 |                 TABLE ACCESS FULL                            | TP_ZAG                 |    148K|  1445K|       |   533   (2)| 00:00:01 |       |       |          |         |
|*266 |                 TABLE ACCESS FULL                            | TP_ZAG_D               |    109K|  2892K|       |  4769   (2)| 00:00:01 |       |       |          |         |
|*267 |                TABLE ACCESS FULL                             | TC_OBJ2LINK            |   1299K|    19M|       |  1750   (2)| 00:00:01 |       |       |          |         |

5.4 без статистик и предикатов непонятны кардинальности и имеет ли смысл по многу раз начитывать одни и теже таблицы
5.5 без ddl таблиц с констрейнтами трудно понять, чего вообще автор хочет, например, если part_aid уникален, то "sysdba.articles art" джойнится зря(а если не уникален, то джойн бестолково размножает строки), т.к. исходя из текста запроса, это условие по нему можно было сразу указать в start with:
      (
        SELECT
          lvl,
          ISLEAF,
          root_part_aid,
          root_proj_aid,
          part_aid,
          proj_aid,
          count_pc ,
          ... AS paths
        FROM
          (
            SELECT
              level                    AS lvl,
              CONNECT_BY_ISLEAF        AS ISLEAF,
              CONNECT_BY_ROOT part_aid AS root_part_aid,
              CONNECT_BY_ROOT proj_aid AS root_proj_aid,
              part_aid,
              proj_aid,
              count_pc ,
              ltrim(SYS_CONNECT_BY_PATH(count_pc, '*'),'*') AS paths
            FROM
              (
                SELECT
                  part_aid,
                  ...
                FROM
                  sysdba.pc pc,
                  zebra.zebra_all_sect zas,
                  sysdba.articles art
                WHERE
                  pc.part_aid       = zas.art_id
                AND ...
                AND pc.proj_aid     = art.art_id
                AND ...
              )
              START WITH part_aid      IS NOT NULL
              ...
              CONNECT BY PRIOR proj_aid = part_aid
          )
      )
    WHERE
      ISLEAF = 1
  )
  my_pc
...
WHERE
  ...
AND art.art_id          = tobj.f_art_id
AND art.purchased      IS NULL
  ...
AND zas.art_id          = tobj.f_art_id
AND zas.kod_odi        IS NOT NULL
AND my_pc.root_part_aid = tobj.f_art_id
то есть транзитивно my_pc.root_part_aid = art.art_id, а root_ - это корни дерева, и кроме предиката "art.purchased IS NULL" больше причин джойнить art нет. А так как деревяшка идет по инлайн вью, которая тоже тупо джойн(причем мы еще не знаем деталей остальных предикатов в ней), то можно просто внутрь просунуть предикат "pc.purchased IS NULL"
5.6 такая же хрень и с
AND zas.art_id          = tobj.f_art_id
AND zas.kod_odi        IS NOT NULL
...
AND my_pc.root_part_aid = tobj.f_art_id

т.к. tobj.f_art_id - это тоже равно my_pc.root_part_aid

-----
устал пока писать, потом продолжу...
6 дек 18, 13:43    [21755760]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
Ryuu
Member [заблокирован]

Откуда:
Сообщений: 545
xtender, я вам благодарен, что вы пытаетесь разобраться. Правда. Но есть один нюанс, который я не сказал, вернее, который упоминался, но он не очевиден. План запроса... от другого запроса, более тяжелого. Выложил лишь "ядро", причем несколько видоизмененное (не все поля вытащил, там где стоит tobj.*, некоторые данные есть только в тех "бессмысленных", на первый взгляд, таблицах). Для теста он более чем подходил, так как уже там сыпался. А план... как я уже упоминал, я не планировал разбираться в запросе или ещё в чем. Выложил тот, что был, и смотрел я по таймингам. Там, к слову, всё связано по индексам и нужно. Лишнего нет. Думал, мне укажут на настройку или параметр базы. На худой конец, скажут, что дерьмо случается и нужно переписать запрос, баг. Сейчас я этим вопрос не занимаюсь от слова совсем, и не планирую. Просто поглядываю тему, отчего и неудобно немного. И да, поля из таблицы pc. ZAS - это вьюшка, через union all объединяет разные таблицы, решение такое себе, но интермех альтернативу не предоставляет. И да, part_aid уникальны. В общем, если вы решили "оценить" сам запрос, занятие весьма спорное. Впрочем, я вас не от чего не отговариваю.

-2- , я со второй страницы говорю, что тема уже неактуально и я в ней более не разбираюсь, лишь отвечаю на провокации. Ума, видимо, проигнорировать всё же не хватает.

env, как вы с Dimitry Sibiryakov общаетесь в своей высокомерной манере, так вам и отвечаю. Поверьте, если бы мне в реале открыто хамили, то я точно так же бы в реале послал наглеца погулять. На этом наше "общение" с вами закончено.
6 дек 18, 16:29    [21756069]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
Ryuu23
Member

Откуда:
Сообщений: 1
Ох, пришлось зарегестрироваться, чтобы внести небольшую правку. Всё моя невнимательность.
Немного соврал. Part_aid был уникален до того момента, как в интермехе появились версии в этой таблице, связка с articles нужна, чтобы подтянуть актуальную версию.
И да, раз уж меня забанили... хм. Ну и ладно. Пока. :)
6 дек 18, 16:43    [21756090]     Ответить | Цитировать Сообщить модератору
 Re: Проседание времени выполнения запроса  [new]
env
Member

Откуда: Россия, Москва
Сообщений: 5916
Ryuu
кажут, что дерьмо случается и нужно переписать запрос

Тебе это говорят чуть ли не с первой страницы. Но ты упорно игнорировал это и
Ryuu
Думал, мне укажут на настройку или параметр базы

Как настройка или параметр повлияет на другие твои запросы, думать за тебя, видимо, тоже должны другие.

Ryuu
План запроса... от другого запроса

Вот уж точно, "у меня в подвале странный стук".

Ryuu
env, как вы с Dimitry Sibiryakov общаетесь в своей высокомерной манере, так вам и отвечаю

Т.е. в реале тоже на "высокомерие" отвечаешь хамством и матом? Ну хоть сам признал. Ещё есть шанс обрести воспитание и исправить речь.
6 дек 18, 17:31    [21756158]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: 1 2 3 4 5      [все]
Все форумы / Oracle Ответить