ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Проседание времени выполнения запроса
105 сообщений из 105, показаны все 5 страниц
  все  
Проседание времени выполнения запроса
    #39741951
Фотография Ryuu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ryuu
Участник
Доброго времени суток.

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

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

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

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

автор
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
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%';



автор
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
-- Информация по входимости.
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;



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

автор
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
117.
118.
119.
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 соответственно.

Подскажите, пожалуйста, какие настройки БД отвечают за подобное, или другие альтернативные методы решения проблемы.
...
Рейтинг: 0 / 0
03.12.2018, 14:01
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39741954
Фотография Ryuu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ryuu
Участник
Прошу прощение за автор, перепутал со спойлером. Поторопился. :(
...
Рейтинг: 0 / 0
03.12.2018, 14:02
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39741955
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Ryuuдругие альтернативные методы решения проблемы.

Проанализировать план не предлагать?..
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
03.12.2018, 14:04
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39741961
Фотография Ryuu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ryuu
Участник
Dimitry Sibiryakov, а что толку? Есть таблица а, есть пвседотаблица б, при их соединении оптимизатор уходит в запой. Как план в этом деле может помочь? Или я чего-то не знаю / не понимаю? Если же речь идёт о трассировке и о том, откуда и куда именно валяться данные, то боюсь, что здесь я бессилен, у меня этого нет.
...
Рейтинг: 0 / 0
03.12.2018, 14:08
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39741964
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
RyuuКак план в этом деле может помочь?

Он покажет чем именно сервер занят два часа.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
03.12.2018, 14:11
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39741965
Фотография Ryuu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ryuu
Участник
Dimitry Sibiryakov, а, это. Есть такое у меня.
SORT ORDER BY | | 205G| 403T| 509T| 13G (1)|142:25:29 | 30M| 1999K| 27M (0)|
...
Рейтинг: 0 / 0
03.12.2018, 14:13
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39741966
Фотография Ryuu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ryuu
Участник
 
explain plan
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
117.
118.
119.
120.
121.
122.
123.
124.
125.
126.
127.
128.
129.
130.
131.
132.
133.
134.
135.
136.
137.
138.
139.
140.
141.
142.
143.
144.
145.
146.
147.
148.
149.
150.
151.
152.
153.
154.
155.
156.
157.
158.
159.
160.
161.
162.
163.
164.
165.
166.
167.
168.
169.
170.
171.
172.
173.
174.
175.
176.
177.
178.
179.
180.
181.
182.
183.
184.
185.
186.
187.
188.
189.
190.
191.
192.
193.
194.
195.
196.
197.
198.
199.
200.
201.
202.
203.
204.
205.
206.
207.
208.
209.
210.
211.
212.
213.
214.
215.
216.
217.
218.
219.
220.
221.
222.
223.
224.
225.
226.
227.
228.
229.
230.
231.
232.
233.
234.
235.
236.
237.
238.
239.
240.
241.
242.
243.
244.
245.
246.
247.
248.
249.
250.
251.
252.
253.
254.
255.
256.
257.
258.
259.
260.
261.
262.
263.
264.
265.
266.
267.
268.
269.
270.
| 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 |       |       |          |         |

...
Рейтинг: 0 / 0
03.12.2018, 14:15
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39742009
MaximaXXL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MaximaXXL
Участник
Ryuu,

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

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

Если есть пример, дайте его ... но я пока не понял в чем смысл, собрать через * что-бы потом парсить ...
...
Рейтинг: 0 / 0
03.12.2018, 15:20
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39742013
Фотография Ryuu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ryuu
Участник
MaximaXXL, вы невнимательны, и пишите не в тему. Вопрос был не об этом.
...
Рейтинг: 0 / 0
03.12.2018, 15:25
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39742033
Фотография DВА
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DВА
Участник
MaximaXXL,
RyuuMaximaXXL, вы невнимательны, и пишите не в тему. Вопрос был не об этом.

ему параметры нужны ))
Ведь не может же быть такое, чтоб работал две недели, а на третью сам по себе перестал
наверняка есть какие-то хитрые параметры, которые злобные админы постоянно дергают и не дают говнокоду прилично работать )
...
Рейтинг: 0 / 0
03.12.2018, 15:55
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39742044
Фотография Ryuu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ryuu
Участник
DВА, *пустил слезу умиления. Вы правы, я хочу, чтобы мой говнокод снова стал работать в пределах двух минут, а не часов. :)
...
Рейтинг: 0 / 0
03.12.2018, 16:15
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39742046
Фотография DВА
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DВА
Участник
RyuuDВА, *пустил слезу умиления. Вы правы, я хочу, чтобы мой говнокод снова стал работать в пределах двух минут, а не часов. :)

поищу тут что-нить полезное
http://ru.harrypotter.wikia.com/wiki/Бытовые_заклинания
...
Рейтинг: 0 / 0
03.12.2018, 16:26
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39742051
MaximaXXL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MaximaXXL
Участник
RyuuDВА, *пустил слезу умиления. Вы правы, я хочу, чтобы мой говнокод снова стал работать в пределах двух минут, а не часов. :)

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

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

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

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

П: Знаете, мне нужен новый блок питания.
С: Почему вы так решили?
П: Я позвонил в Микрософт, и они стали расспрашивать меня о том, кто
производитель моего блока питания.
С: И что?
П: Выяснилось, что мой блок питания не совместим с драйвером NOSMOKE.
...
Рейтинг: 0 / 0
03.12.2018, 16:31
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39742061
Фотография DВА
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DВА
Участник
Ну или как вариант - прогнуться перед админами, извиниться за высказанные подозрения в порче говнокода и просьба найти и закрепить план запроса, который был две недели назад.
...
Рейтинг: 0 / 0
03.12.2018, 16:42
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39742076
Фотография Ryuu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ryuu
Участник
DВА, они хотели закрепить план запроса, но не смогли. Причину не назвали. Или с планом всё хорошо, но почему-то проседать он от этого не перестал, либо... я не знаю. Но у меня от этого, если честно, подгорает. :-\

Ps. Спасибо за ссылку, посмотрю завтра. Не понял, как "чистка" вьюшки поможет.
...
Рейтинг: 0 / 0
03.12.2018, 16:51
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39742077
Фотография Ryuu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ryuu
Участник
А, ну да... заклинания. Хм. Такое, пожалуй, вечером почитаю. Да. Какой-нибудь фанфик. :)
...
Рейтинг: 0 / 0
03.12.2018, 16:52
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39742171
flexgen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
flexgen
Участник
авторЛично я грешу на наших админов, что ковырнули настройки БД, в чем они конечно же не признаются

Я на такое всегда отвечаю так - у меня под крышкой стола есть три кнопки, "Все не работает", "Все работает", "Все работает отлично". В зависимости от своего настроения я нажимаю соответствующую кнопку и все работает или не работает :-). Последний случай когда я это говорил был буквально вчера - пришли ко мне чудаки из BI с жалобой на то, что вдруг все перестало работать и с вопросом "А не подкрутил ли что-то в базе злобный DBA чтобы бедняжкам из BI нескучно было?". А то что четыре картезианских множества из двух таблиц объединенных при помощи UNION ALL, в сумме дающих 8 миллиардов записей, это не самый лучший вариант запроса им как-то в голову не пришло.
...
Рейтинг: 0 / 0
03.12.2018, 22:49
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39742229
Фотография Ryuu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ryuu
Участник
flexgen, вот только такой запрос изначально бы работал хреново. В любом случае, думаю, что я разобрался. У них маленькое значение для переменной сортировки под сессию.
...
Рейтинг: 0 / 0
04.12.2018, 08:05
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39742232
Фотография кит северных морей
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
кит северных морей
Участник
Ryuu,

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

в любом случае, попросите админов сделать отчет real time sql monitor. в нем будет четко видно, на что фактически уходит время при выполнении запроса. после этого можно будет о чем-то рассуждать, и делать какие-то выводы. без этой, или какой-то другой фактической информации, все, чего вы дождетесь в ответ - спекуляции и гадания на кофейной гуще. то, что вы уже показали здесь - это прогноз самой субд, который по ряду причин часто имеет мало общего с реальностью.
...
Рейтинг: 0 / 0
04.12.2018, 08:35
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39742266
Фотография env
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
env
Участник
Ryuu,

План, по которому выполняется запрос действительно такой? И всё ли хорошо со статистикой.
...
Рейтинг: 0 / 0
04.12.2018, 09:51
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39742270
Фотография env
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
env
Участник
Ryuu,

И есть большие сомнения, что это план приведённого запроса. Как раз из-за сортировки.
...
Рейтинг: 0 / 0
04.12.2018, 09:54
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39742274
Фотография env
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
env
Участник
RyuuЕсть некий запрос, который еще две недели назад работал хорошо. Потом что-то случилось. Лично я грешу на наших админов

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

Скорее всего план твоего запроса держался на границе merge/unnest за счёт статистки, и как только она перешла грань - произошло слияние подзапроса и "первого куска". Как вариант, прибей гвоздями материализацию подзапроса.
...
Рейтинг: 0 / 0
04.12.2018, 10:02
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39742402
Фотография DВА
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DВА
Участник
envRyuuЕсть некий запрос, который еще две недели назад работал хорошо. Потом что-то случилось. Лично я грешу на наших админов

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

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

курсоры из кэша не вытеснялись и адаптивные фичи оптимизатора не баламутили )
...
Рейтинг: 0 / 0
04.12.2018, 14:10
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39742465
MaximaXXL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MaximaXXL
Участник
Ryuu,

Я конечно не внимателен, да и пишу не в тему и наверно многово не успею понять но для конкретно ЭТОГО запроса который Вы хотите ускорить ...
Код: plsql
1.
2.
3.
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 подзапроса) смотря что надо найти.
...
Рейтинг: 0 / 0
04.12.2018, 15:55
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39742472
A K
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
A K
Участник
Смотрите. Тут ребята много разных дельных советов дали. Это все хорошо и правильно.

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

прежде чем что-то предпринимать, поинтересуйтесь у админов степенью нагрузки общего физического дискового массива другими приложениями и базами. Учитывая модные тенденции сейчас все ставить на виртуалки, даже бд (особенно когда общее железо разделяют несколько баз, приложений и прочее.), - всегда нужно интересоваться нагрузками на дисковую подсистему. Возможно на СХД на одном луне повесили кучу аплекух и баз, и тогда на ровном месте вы можете получить сегодня идеальную работу, а завтра при тех же самых условиях у вас мистическим образом все упадет !
...
Рейтинг: 0 / 0
04.12.2018, 16:02
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39742476
Фотография DВА
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DВА
Участник
A K прежде чем что-то предпринимать, поинтересуйтесь у админов степенью нагрузки общего физического дискового массива другими приложениями и базами. Учитывая модные тенденции сейчас все ставить на виртуалки, даже бд (особенно когда общее железо разделяют несколько баз, приложений и прочее.), - всегда нужно интересоваться нагрузками на дисковую подсистему. Возможно на СХД на одном луне повесили кучу аплекух и баз, и тогда на ровном месте вы можете получить сегодня идеальную работу, а завтра при тех же самых условиях у вас мистическим образом все упадет !

с трудом представляю себе, чтобы можно было "навешать", что бы время работы увеличилось с двух минут до двух часов и при этом оно все еще выглядело живым в целом )))
...
Рейтинг: 0 / 0
04.12.2018, 16:09
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39742495
A K
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
A K
Участник
Поверьте, и не такое бывает. Вот с чем соглашусь - живым и целым. :) Да в этом случае, действительно наблюдается сильная общая деградация работы всей бд, при полном отсутствии объективных причин вызванных прикладным уровнем самой БД - запросы, хранимки . В AWR начинают попадать елементы, которых там в принципе быть не должно ит.д.

Понимаю, что у топикпастера скорее-всего банальное разрастание таблиц + возможное отсутствие необходимых индексов (ну или фактор кластеризации нужных индексов резко увеличился и поэтому вместо индекса, запрос начал фулить) - изучать в общем нужно план хороший и плохой...
Но, он же утверждает, что количество данных не менялось. А если ничего вообще не менялось и резко пошла деградация - тогда это одна из основных причин, при условии, что все остальные причины исключены.
...
Рейтинг: 0 / 0
04.12.2018, 16:37
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39742517
Фотография DВА
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DВА
Участник
A K,
грошь цена его утверждениям, он не напрягся даже план проверить )
...
Рейтинг: 0 / 0
04.12.2018, 17:15
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39742522
Фотография Stax
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Stax
Участник
DВА,

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

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

.....
stax
...
Рейтинг: 0 / 0
04.12.2018, 17:32
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39742524
казинак
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
казинак
Участник
лично на меня не раз так наезжали:
"вчера работало а щас висит"

и в общем случае, в таких ситуациях, я даже причину не ищу
эта оракл, детка!!!
проще устранить трабл,
но это не всегда возможно,
к примеру, недавно базисникам я сказал:
"раз в вашем гребаном сапе низя в обход сапа в базе лазить
то сами и разбирайтесь
либо читайте сапноты либо в саппорт пишите
нехер на базу стрелки переводить"
...
Рейтинг: 0 / 0
04.12.2018, 17:35
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39742528
A K
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
A K
Участник
DBA, В общем согласен. :)

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

Раньше, я бы сказал, что Stax, например абсолютно прав! И начал бы серьезно копать где накосячил CBO со своей аналитикой и копипастер со своими индексами и вставками. Но сейчас, все чаще становиться прав условный "казинак".
Потому, что от патча к патчу и от версии к версии - CBO становиться не таким тупым как было раньше. И, если копипастер явно с индексами не накосячил, то как правило CBO просто так не фулит, без серьезной на то причины, как было это раньше.
Но! вот эта любовь к виртуалкам везде - где надо и где не надо, невозможность установить БД на нормальном железе - приколов от этого сейчас просто немеренно.
...
Рейтинг: 0 / 0
04.12.2018, 17:47
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39742704
Фотография Ryuu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ryuu
Участник
Кхм, простите, что отсутствовал. Но проблема выявлена, только админы, вместо того, чтобы увеличить объем переменной, обратились, так сказать, к техподдержке выше. Теперь вот жду. И, видимо, это затянется.

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

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

Ps. Админы вообще такие перлы выдавали, хоть стой, хоть падай. Например, указывали в "самый тяжелый HASH JOIN", который обрабатывает 8-10 секунд, и предложили его мне запихнуть в матвью. А то, что запрос работает 2 часа, а сам джоин двух таблиц происходит по ключу, т.е. по индексу, и быстрее быть в принципе не может... ну кого это волнует, право слово? Когда я им предложил это сделать самим, чтобы не тратить своё время, раз уж они считают, что это поможет, админы почему-то обиделись и нажаловались своему начальству, что их заставляют оптимизировать чужой запрос. Это дико смешно, но мне порой с них плакать хочется. Честно. Благо это не тот вопрос, который они могут "скинуть" с себя. :)
...
Рейтинг: 0 / 0
05.12.2018, 10:19
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39742710
Фотография -2-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
-2-
Участник
Ryuuувеличить объем переменнойТы своим админам дай ссылку на эту тему. Может они тоже какие перлы про тебя опубликуют.
...
Рейтинг: 0 / 0
05.12.2018, 10:24
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39742711
Фотография Ryuu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ryuu
Участник
И да, план давали админы, т.е. могу надеяться, что он достаточно объективен. По нему, кстати, хорошо видно, что запрос составлен грамотно. Проблема в сортировке, которая провисает.
...
Рейтинг: 0 / 0
05.12.2018, 10:24
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39742712
Фотография Ryuu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ryuu
Участник
-2-, смею надеяться, что я достаточно самоироничен, чтобы не обижаться на правду. Но нет, они слишком обидчивые, а мне с ними ещё работать. Найдут, ну и ладно. У меня от них неслабо так подгорело, пока разбирался в проблеме. В их проблеме. С их упорным отрицанием существования проблемы. Но вот намеренно провоцировать не стану.

А ты чего так подключился к флейму, сам админом подрабатываешь, задело? :)
...
Рейтинг: 0 / 0
05.12.2018, 10:28
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39742719
Фотография -2-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
-2-
Участник
Ryuuадмином подрабатываешьАрбитром.
В игре в одни ворота нече на ворота пенять... Это воспринимается исключительно как продолжение небезызвестной присказки.
...
Рейтинг: 0 / 0
05.12.2018, 10:54
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39742738
Фотография Ryuu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ryuu
Участник
-2-, возможно, я несколько неправ, но, как я уже сказал ранее, у меня подгорело после общения с ними, а именно их желания сбросить эту проблему с себя, даже не пытаясь в нее вникнуть. А потому некоторый негатив все же проскальзывает. Всё-таки на работе себе я такого позволить не могу: резких и провокационных высказываний. Вернее могу, но зачем? В общем, ладно. Пустое.
...
Рейтинг: 0 / 0
05.12.2018, 11:30
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39742815
Фотография AlexFF__|
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AlexFF__|
Участник
Ryuu,

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

В твое случае админы либо лентяи либо дураки.
Если им жалко минутки своего времени на запуск скрипта, получающего планы и статистику запроса за различные периоды времени, то лентяи.
Если у них нет такого скрипта - дураки.
Не знаю, что хуже.
...
Рейтинг: 0 / 0
05.12.2018, 13:49
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39742890
Фотография env
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
env
Участник
Ryuuпока разбирался в проблеме. В их проблеме.
Поддержу. Любой говнокод становится проблемой админа. Например, использование connect by в подзапросе (список багов смотри в металинке) с потенциальным or expansion в конкатенацию - это явно админы написали. Ух, нехорошие какие!
...
Рейтинг: 0 / 0
05.12.2018, 15:17
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39742915
Фотография Ryuu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ryuu
Участник
env, действительно, зачем разработчику использовать вложенные функции оракла, зачем эти мезкие програмеры вообще нагружают ИХ любимую базу данных этими бессмысленными запросами. Да?
...
Рейтинг: 0 / 0
05.12.2018, 15:43
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39742918
Фотография env
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
env
Участник
Ryuuчто на обработку просто перестало хватать памяти и её надо увеличить.
Распечатал и повесил.
...
Рейтинг: 0 / 0
05.12.2018, 15:45
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39742920
Фотография env
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
env
Участник
Ryuuзачем разработчику использовать вложенные функции оракла, не понимая, какой эффект могут получить. Забыли кусок фразы.

Зачем вообще разработчику думать, можно же просто брать функции и применять!
...
Рейтинг: 0 / 0
05.12.2018, 15:47
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39742935
Фотография DВА
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DВА
Участник
Расскажите плз чем эта эпопея закончится )
Кто кого - лентяи админы, не желающие вникать в ваш бредогенератор и решать чужие проблемы, или безгамотные разрабы, списывающие все проблемы говнокода на неправильные параметры )))

Извечная борьба )))
...
Рейтинг: 0 / 0
05.12.2018, 16:06
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39742945
Фотография Ryuu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ryuu
Участник
DВА, хорошо. :)

env, идите нах... :)
...
Рейтинг: 0 / 0
05.12.2018, 16:21
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39742991
Фотография -2-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
-2-
Участник
Ryuuзачем разработчику использовать вложенные функции ораклаВложенные функции это объявленные внутри другой и, соответственно, их область видимости ограничена охватывающей функцией. Функции оракла это sysdate, to_char и т.п.
В связи с этим, вопрос "зачем" можно задавать только после ответа на "как".
...
Рейтинг: 0 / 0
05.12.2018, 16:57
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39743038
Фотография Ryuu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ryuu
Участник
-2-, знаешь, я немного тебе завидую, ты тратишь своё время на пустой трёп, ведь за всё время, ты не сказал ничего по существу, а возможно и не планировал. Наверное, у тебя этого времени много. И да, хоть ты и расшифровал понятие "вложенности", но при этом как-то забыл, что у слов существуют синонимы и они, слова, вполне может иметь разные значения в зависимости от контекста. Но мы же хотим выебнуться, верно?
...
Рейтинг: 0 / 0
05.12.2018, 18:15
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39743039
Фотография Ryuu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ryuu
Участник
*могут.
Мда. Не люблю я этот форум из-за невозможности правки сообщений. Но кого это волнует, да? :)
...
Рейтинг: 0 / 0
05.12.2018, 18:17
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39743043
Фотография DВА
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DВА
Участник
Dimitry SibiryakovRyuuдругие альтернативные методы решения проблемы.

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


RyuuDimitry Sibiryakov, а что толку?

После этого вряд ли кто-то тебе что-то скажет "по существу"
так, потролить разве что...
...
Рейтинг: 0 / 0
05.12.2018, 18:30
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39743049
Фотография mefman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mefman
Участник
-2-Ryuuувеличить объем переменнойТы своим админам дай ссылку на эту тему. Может они тоже какие перлы про тебя опубликуют.
да, думаю уже тут )
...
Рейтинг: 0 / 0
05.12.2018, 18:40
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39743061
Фотография кит северных морей
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
кит северных морей
Участник
Ryuuты не сказал ничего по существу, а возможно и не планировал
я еще на первой странице дал вам предельно конкретный ответ по существу - чтобы предметно разговаривать, нужно выполнить запрос, собрать статистики выполнения, например через RTSM, и проанализировать их. если вы готовы выложить RTSM - можно прямо здесь. не знаю, что за десятисекундный hash join вы там обсуждали с админами, но то, что вы выложили сюда ранее - это НЕ фактическая статистика выполнения запроса, и практической пользы от этого мало.

вы вместо этого продложаете абсолютно бессмысленные препирательства с админами на тему sort_area_size, или что вы там имеете в виду, и со всеми подряд здесь. у кого времени-то много?
...
Рейтинг: 0 / 0
05.12.2018, 18:52
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39743067
Фотография Ryuu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ryuu
Участник
кит северных морей, да, я имею ввиду sort_area_size. И мне, конечно, хотелось бы разобраться в проблеме и предоставить вам те или иные данные, которые помогли бы в её решении, но увы, я предоставил вам всё, что было в моих силах. Повторюсь, админы разбираться в проблеме НЕ хотят. Даже вышеуказанный параметр изменить, хотя бы на время теста, и теперь ждут ответ из службы поддержки выше. Поэтому всё и скатилось во флейм. В любом случае, мне это надоело. Что же до форума, я искренне надеялся, что у кого-то была схожая ситуация и мне дадут совет без какой-либо дополнительной информации от меня, сверх того, что я уже предоставил.
...
Рейтинг: 0 / 0
05.12.2018, 19:15
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39743072
Фотография DВА
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DВА
Участник
Ryuu мне дадут совет без какой-либо дополнительной информации от меня, сверх того, что я уже предоставил.

бросай это дело сынок )
займись чем-нить менее напряжным для ума, ну там искусством, политикой ))
...
Рейтинг: 0 / 0
05.12.2018, 19:28
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39743073
Фотография кит северных морей
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
кит северных морей
Участник
Ryuu,

просевшая производительность запроса - это проблема разработчика, пока не доказано обратное (это я как разработчик говорю, а не как админ, если что). начинать разбираться, соответственно, должен разработчик, и не с подкрутки sort_area_size (параметры системы - это вообще самая распоследняя вещь, которую в этом случае нужно трогать). получить отчет RTSM можно элементарно одним запросом, либо через OEM.
...
Рейтинг: 0 / 0
05.12.2018, 19:29
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39743074
Фотография Ryuu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ryuu
Участник
mefman, возможно, но после переписки в жире, мне как-то всё равно.

DВА, план запроса я выложил, помогло? Нет. А других более существенных данных, которые помогли бы в решении задачи, у меня просто нет. И да, я уже пожалел о создании темы, только время потратил. Тем более, что всё скатилось до "мы написали в техподдержку, ждём". В любом случае, я разобрался, как мне кажется (перекрестился), в ситуации, а дальше... пусть делают, что хотят. Всех пользователей буду отправлять к ним.
...
Рейтинг: 0 / 0
05.12.2018, 19:29
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39743075
Фотография DВА
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DВА
Участник
Ryuu Даже вышеуказанный параметр изменить, хотя бы на время теста, и теперь ждут ответ из службы поддержки выше.
теперь хренеет техподдержка, зачем какому-то птеродактилю понадобилось в 12 версии устанавливать sort_area_size вручную )))
...
Рейтинг: 0 / 0
05.12.2018, 19:31
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39743076
Фотография Ryuu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ryuu
Участник
кит северных морей, серьёзно? То есть, по вашему, если запрос исправно работал несколько лет, а потом бац, и стал выполняться вместо пары минут пару часов, это проблема разработчика? При этом последний никаких изменений не вносил.

DВА, спасибо, я уж как-нибудь сам решу чем заниматься.
...
Рейтинг: 0 / 0
05.12.2018, 19:33
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39743078
Фотография Ryuu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ryuu
Участник
DВА, о, тогда может большая жирная жаба в этом болоте жизни скажет в чем причина? Конечно же, я искренне надеюсь, что админы написали суть проблемы дальше, вместе со всеми имеющимися данными, нежели завели разговор о данном параметре, всё же я могу и ошибаться. И нет, новых данных я вам не предоставлю, только хардкор, только последний уровень сложности.
...
Рейтинг: 0 / 0
05.12.2018, 19:36
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39743080
Фотография кит северных морей
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
кит северных морей
Участник
Ryuu,

серьезно. например, подключили новый модуль в систему, прирост данных в какую-нибудь таблицу единовременно увеличился вдвоое-втрое, и с новой структурой данных в каком-нибудь старом отчете по этой таблице существующий план перестал быть оптимален. а новый оптимизатор построить не может, так как старый прибит хинтами.
...
Рейтинг: 0 / 0
05.12.2018, 19:39
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39743082
Фотография -2-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
-2-
Участник
RyuuДаже вышеуказанный параметр изменитьА анекдот-то 21752218 в тему. Похоже так достал админов, что они, вместо сказать "меняй сам", сослались на техподдержку.
...
Рейтинг: 0 / 0
05.12.2018, 19:41
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39743083
Фотография Ryuu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ryuu
Участник
кит северных морей, пример неудачный, старый прибит хинтами не был, кол-во данных сильно не менялось, хоть и немного увеличилось.

В любом случае, я вас понял. Я этим не занимался, мониторинг у нас документально закреплен за админами, как и его разбор. У нас вообще никто этим не занимался, из разработчиков. Во всяком случае, мне об этом неизвестно. Да и нужды не было. И да, я бы последовал вашему совету, но мне большое начальство уже сказало забить и ждать, чего они там придумают, а у меня и другие задачи есть. Это я уже после работы на форум зашел.
...
Рейтинг: 0 / 0
05.12.2018, 19:42
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39743087
Фотография DВА
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DВА
Участник
RyuuDВА, о, тогда может большая жирная жаба в этом болоте жизни скажет в чем причина?
за ваши деньги любой каприз )
...
Рейтинг: 0 / 0
05.12.2018, 19:47
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39743088
Фотография кит северных морей
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
кит северных морей
Участник
Ryuu,

я нигде не сказал, что это именно ваш случай. я привел абстрактный пример ситуации, в которой запрос начинает работать резко медленнее без изменения самого запроса и без видимых причин. таких ситуаций может быть масса. начинать разбираться с ними должен разработчик, а не админ. к админу я хожу, когда у меня dbms_stats.gather_table_stats падает со snapshot too old, или что-то подобное.
...
Рейтинг: 0 / 0
05.12.2018, 19:47
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39743093
Фотография Ryuu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ryuu
Участник
-2-, веришь нет, вообще наплевать. Если они откажутся от решения проблемы, то это их проблемы, не мои. Уж прости за тавтологию. И нет, никого я не доставал, как вам могло бы показаться, ведь в отличие от форума, послать кого-то на работе накуй или сказать, что он дебил, я к сожалению или счастью не могу, ибо не поймут. Да и воспитан я как-то иначе. Это здесь можно выплеснуть излишек эмоций, хотя я уже и успел пожалеть, что вообще создал данную тему. И да, я также понимаю, что я могу ошибаться и приводить неверные доводы, однако это не отменяет некоторых, скажем так, аспектов общения и того бреда, который мне пришлось прочесть, прежде, чем тема ушла дальше, в техподдержку.
...
Рейтинг: 0 / 0
05.12.2018, 19:49
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39743096
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Ryuuплан запроса я выложил, помогло? Нет.
А должно было? Все увидели самый дерьмовый план, который только можно представить. Все
поразились "а как ОНО вообще могло выполняться быстро". Все сказали "переписывай свой
запрос". Ты отказался. Конец истории.

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

Да. Ты в курсе "проблемы N+1"?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
05.12.2018, 19:52
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39743098
Фотография Ryuu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ryuu
Участник
кит северных морей, как я уже сказал, я понимаю, что могу ошибаться. Однако, когда у меня запрос валиться на стадии связки двух таблиц, это явно не нормально. Пусть даже первая "таблица" это группа таблиц, а вторая это небольшой иерархический подзапрос. Причем связываю грамотно. Да, таблицы получились тяжелые. Но раньше такого дерьма не было. Уж простите за выражение. И со своей стороны я тупо бессилен что-либо изменить, ибо в том виде, как лежат данные в базе, я по другому их извлечь тупо не могу. Нет, конечно, можно потанцевать с бубном... но зачем? Когда я уже привел пример, что используя все те же данные, но связку делать по другому полю, которое имеет, скажем так, меньшую уникальность, все происходит замечательно? Логичный вывод, на мой скромный взгляд, что проблема в обработки большего кол-ва данных? В чем я не прав?

DВА, я в вас не сомневался. :)
...
Рейтинг: 0 / 0
05.12.2018, 19:57
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39743099
Фотография Ryuu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ryuu
Участник
Dimitry Sibiryakov, Вася, своё несомненно авторитетное мнение можешь засунуть себе в задницу.
...
Рейтинг: 0 / 0
05.12.2018, 20:00
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39743100
Фотография DВА
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DВА
Участник
Ryuuк
DВА, я в вас не сомневался. :)
спасибо )
в отдельности спасибо за то, что не собираешься завязывать с программирование )
ибо только благодаря существованию таких разработчиков как ты, у меня всегда будет кусок хлеба ;) c маслом )
...
Рейтинг: 0 / 0
05.12.2018, 20:01
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39743101
Фотография Ryuu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ryuu
Участник
Dimitry Sibiryakov, и чтобы ты не обижался на несправедливость, мол как же так, я ему помочь хочу, а он меня ещё и посылает. Я же ничего такого не сказал. Так вот. Если у тебя есть несколько таблиц и ты их можешь связать по индексу, ты их связываешь. Если есть какие-то ещё условия, ты их выставляешь. Ничего сверхъестественного или сложного в запросе нет. Обычная связка. Абсолютно обычная. И если тебе в связке нескольких таблиц план видится дерьмовым, извини, но напиши лучше, я посмотрю. Мне вот даже интересно, как диванный эксперт свяжет две таблицы. Скажем, в одной миллион строк и есть поле ключ, в другой тоже миллион строк и тоже поле ключ. Скажи, если не по ключу, то как? Несомненно твоя гениальная идея будет лучше этого дерьмового плана.
...
Рейтинг: 0 / 0
05.12.2018, 20:04
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39743103
Фотография Ryuu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ryuu
Участник
DВА, рад за тебя, наверняка, ты не только гений программирования, но и вообще гений, раз смог так легко составить мнение о человеке и его навыках. Только не лопни от чувства собственной важности, я о тебе переживаю.
...
Рейтинг: 0 / 0
05.12.2018, 20:07
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39743105
Фотография DВА
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DВА
Участник
RyuuDimitry Sibiryakov, и чтобы ты не обижался на несправедливость, мол как же так, я ему помочь хочу, а он меня ещё и посылает. Я же ничего такого не сказал. Так вот. Если у тебя есть несколько таблиц и ты их можешь связать по индексу, ты их связываешь. Если есть какие-то ещё условия, ты их выставляешь. Ничего сверхъестественного или сложного в запросе нет. Обычная связка. Абсолютно обычная. И если тебе в связке нескольких таблиц план видится дерьмовым, извини, но напиши лучше, я посмотрю. Мне вот даже интересно, как диванный эксперт свяжет две таблицы. Скажем, в одной миллион строк и есть поле ключ, в другой тоже миллион строк и тоже поле ключ. Скажи, если не по ключу, то как? Несомненно твоя гениальная идея будет лучше этого дерьмового плана.

а тебе точно нужно получить в исходном запросе весь миллион строк ?
...
Рейтинг: 0 / 0
05.12.2018, 20:09
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39743107
Фотография Ryuu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ryuu
Участник
DВА, прикинь да. Они ограничиваются данными, что в подзапросе (та иерархическая лабуда), вот только при связке с ним в настоящий момент всё отваливается. Под отваливается я подразумеваю, что запрос начинает работать слишком долго, когда раньше было ок.
...
Рейтинг: 0 / 0
05.12.2018, 20:11
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39743109
Фотография Ryuu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ryuu
Участник
RyuuDВА, прикинь да. Они ограничиваются данными, что в подзапросе (та иерархическая лабуда), вот только при связке с ним в настоящий момент всё отваливается. Под отваливается я подразумеваю, что запрос начинает работать слишком долго, когда раньше было ок.
Ну и лайк тоже ограничения накладывает. И нет, заменить лайк на что-то другое нельзя.
...
Рейтинг: 0 / 0
05.12.2018, 20:12
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39743110
Фотография кит северных морей
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
кит северных морей
Участник
Ryuu,

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

вот вы утверждаете, что вы связали две таблицы. это не так. вы связали две inline view. при построении плана оптимизатор делает view merging - то есть, грубо говоря, выдергивает содержимое из ваших псевдотаблиц, и перемешивает в том порядке, который ему покажется оптимальным, не нарушая логики запроса. и если в тексте запроса ваша my_pc присоединяется последней, и как отдельная сущность - совершенно не обязательно, что при выполнении запроса оракл именно так и сделает.
...
Рейтинг: 0 / 0
05.12.2018, 20:13
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39743111
Фотография DВА
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DВА
Участник
RyuuDВА, рад за тебя, наверняка, ты не только гений программирования, но и вообще гений, раз смог так легко составить мнение о человеке и его навыках. Только не лопни от чувства собственной важности, я о тебе переживаю.
я очень, очень сомневающийся человек ))
поэтому до последнего надеялась, что в твою светлую голову прискачет мысль - "а может я не с того конца пытаюсь проблему решить"
но нет, не этот раз ))
возможно навыки "в области балета" у тебя и запредельные, но в оптимизации запросов ты даже не ноль, ты минус адын )
...
Рейтинг: 0 / 0
05.12.2018, 20:13
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39743113
Фотография DВА
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DВА
Участник
RyuuDВА, прикинь да. Они ограничиваются данными, что в подзапросе (та иерархическая лабуда), вот только при связке с ним в настоящий момент всё отваливается. Под отваливается я подразумеваю, что запрос начинает работать слишком долго, когда раньше было ок.

ну тогда от нашего стола вашему )
погугли хинт cardinality и пририсуй кардинальность своей лабуде, чтобы основной запрос считал, что оттуда прилетит не так уж и много
...
Рейтинг: 0 / 0
05.12.2018, 20:16
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39743117
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
RyuuМне вот даже интересно, как диванный эксперт свяжет две таблицы. Скажем, в одной миллион
строк и есть поле ключ, в другой тоже миллион строк и тоже поле ключ. Скажи, если не по
ключу, то как?

В твоём плане "FULL TABLE SCAN" и большая куча вложенных "NESTED LOOP" совсем-совсем не
выглядят на "связывание по ключу".
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
05.12.2018, 20:21
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39743120
Фотография Ryuu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ryuu
Участник
Dimitry Sibiryakov, а я знаю, почему он так себя вести начал? У меня нет таблиц, которые НЕ связаны по ключу.

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

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

И да, хинты у нас не работают. Прелесть, да? Всё, я ушел.
...
Рейтинг: 0 / 0
05.12.2018, 20:24
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39743123
Фотография кит северных морей
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
кит северных морей
Участник
RyuuЭта обязанность висит не на мне. Да, вас это может возмущать, но у нас это так.мне абсолютно всё равно, на ком в вашей организации висит эта обязанность, поверьте. я просто пытался вас натолкнуть на чуть более правильный ход мыслей при решении данных проблем, чтобы в следующий раз, случись он, вы лучше представляли, что нужно делать. судя по всему, получилось плохо :)
...
Рейтинг: 0 / 0
05.12.2018, 20:28
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39743131
Фотография mefman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mefman
Участник
кит северных морей,
Вообще не получилось.))
...
Рейтинг: 0 / 0
05.12.2018, 20:50
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39743133
Фотография Ryuu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ryuu
Участник
кит северных морей, вы простите меня, пожалуйста. Я понимаю, что веду себя... несдержанно. У меня от данной проблемы изжога, метафорически говоря. Началось всё с общения с админами, вернее с одним конкретным индивидуумом. А потому и на колкие замечания реагирую, как оказалось, остро. Я сейчас даже не вас имею ввиду. Фактический план запроса я просил в своё время (пока проблема не ушла дальше), мне его не предоставили. С сегодняшнего дня, или лучше сказать, вчерашнего вечера, эта проблема уже не моя. И всё это скатилось... впрочем, вы прекрасно видите, во что это скатилось.
...
Рейтинг: 0 / 0
05.12.2018, 20:53
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39743140
Фотография AlexFF__|
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AlexFF__|
Участник
кит северных морейRyuu,
просевшая производительность запроса - это проблема разработчика, пока не доказано обратное...
Нет, просевший запрос - это проблема бизнеса.
И тут либо у dba есть адекватный мониторинг и они его сами отловят, либо бизнес поднимет инцидент.
И тут нет виноватых по умолчанию, может и железо виновато и кривой запрос и хайсизон в конце концов.

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

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

А то, что происходит у ТС, это простое отфутболивание проблемы, начатое админами.
Серьезно, я даже не могу представить, чтобы в серьезной организации, админы могли просто отписаться "ваш запрос стал медленно работать".
Это как профессиональный тестировщик описывал проблему "ваша программа не работает".
...
Рейтинг: 0 / 0
05.12.2018, 21:17
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39743141
Фотография -2-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
-2-
Участник
План получить сам ты не в состоянии, пеняешь на параметр сессии, который тоже изменить не умеешь. При таких компетенциях предъявляешь публике претензии к своим админам.
Пришел попалкаться на форум, может кто посочувствует. А тут такое...
...
Рейтинг: 0 / 0
05.12.2018, 21:17
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39743152
Фотография Ryuu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ryuu
Участник
-2-, увы и ах, я надеялся исключительно на то, что с минимальной информацией с моей стороны мне кто-нибудь подскажет что-то дельное, т.е. уже сталкивался с чем-то подобным или предполагает... что-то конкретное. Но, повторюсь, я уже сто раз пожалел, что создал здесь тему, тем более, что она с сегодняшнего дня и вовсе перестала быть актуальной. Сам не знаю, почему до сих пор здесь. И ваше "не умею" отнюдь не равно моему "не имею возможности".
...
Рейтинг: 0 / 0
05.12.2018, 21:37
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39743160
Фотография -2-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
-2-
Участник
RyuuИ ваше "не умею" отнюдь не равно моему "не имею возможности".Поручили решать вопрос с производительностью, а доступа к БД не дали?
...
Рейтинг: 0 / 0
05.12.2018, 21:57
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39743164
Фотография кит северных морей
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
кит северных морей
Участник
AlexFF__|,

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

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

плюс, запросы ломаются не только на проде. есть, например, несколько препродуктивных сред, на которых в условиях нагрузки, приближенной к боевой, обкатываются доработки после первоначального тестирования. там может твориться что угодно, и на каждый чих админа не выдернешь - надо разбираться самим.
...
Рейтинг: 0 / 0
05.12.2018, 22:05
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39743166
Фотография кит северных морей
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
кит северных морей
Участник
Ryuuт.е. уже сталкивался с чем-то подобным или предполагает... что-то конкретное.
поставьте сюда no_merge. вдруг поможет (я не знаю, что вы имели в виду, когда сказали, что хинты не работают).
Код: plsql
1.
2.
3.
4.
  (-- Информация по входимости.
    SELECT /*+no_merge*/
      lvl,
      root_part_aid,
...
Рейтинг: 0 / 0
05.12.2018, 22:14
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39743169
Фотография AlexFF__|
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AlexFF__|
Участник
кит северных морейAlexFF__|,
я не думаю, что у админа, на группe которого могут висеть десятки или сотни БД, есть желание (и даже обязанность)
...
у нас инцидент от бизнеса сначала идет в application support, дальше - как правило, прикладной разработчик-владелец кода, еще дальше - DB dev team с расширенным read-only доступом в продуктив (я), и только потом DBA.

Инцидент уже прошел саппорт, анализ разработки и пришел к одному запросу (или сами админы нашли его).
Сбор данных для определения причины это именно обязанность админа (в твоем случае DB dev team с расширенным read-only доступом).
Как я уже говорил, этот сбор дело несколько минут и одного нажатия кнопки для запуска скриптов.
А далее уже дело разработчиков.
Так что это, как ты и написал, отсутствие желания. + недоработка начальства.
...
Рейтинг: 0 / 0
05.12.2018, 22:26
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39743172
MaximaXXL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MaximaXXL
Участник
Ryuu,

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

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

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

Я Вам предлагал подумать, что стоит его переписать. Да - это может Ваше детище и Вы за "это" даже может премию получили, но план показывает что там есть что править.
...
Рейтинг: 0 / 0
05.12.2018, 22:37
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39743179
Фотография кит северных морей
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
кит северных морей
Участник
AlexFF__|,

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

а в такой формулировке (если "админ" - это специализированный разраб БД / dev DBA) - да, согласен, разве что мы не только информацию собираем, но и даем конкретные рекомендации, т.к. тоже знаем систему изнутри.
...
Рейтинг: 0 / 0
05.12.2018, 23:11
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39743184
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Ryuuа я знаю, почему он так себя вести начал?

Должен бы знать. Ведь это твоя база, ты знаешь таблицы, ты знаешь какие на них есть
индексы и когда пересчитывалась их статистика, ты знаешь как работает твой запрос, какие
методы доступа он может использовать и какие будут оптимальны на данном объёме данных. Или
ты таки ничего из этого не знаешь?..
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
05.12.2018, 23:33
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39743192
feagor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
feagor
Гость
Dimitry Sibiryakov,

Понаписали говнокода, разбираться не хотят, какой смысл вообще с такими вести диалог?
...
Рейтинг: 0 / 0
06.12.2018, 00:47
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39743197
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sayan Malakshinov
Модератор форума
начал было писать детальный разбор, но потом мысль о бессмысленности оного победила и на 5-м пункте бросил. Не вижу смысла помогать, если человек в принципе думать не хочет.




кит северных морейRyuuт.е. уже сталкивался с чем-то подобным или предполагает... что-то конкретное.
поставьте сюда no_merge. вдруг поможет (я не знаю, что вы имели в виду, когда сказали, что хинты не работают).
Код: plsql
1.
2.
3.
4.
  (-- Информация по входимости.
    SELECT /*+no_merge*/
      lvl,
      root_part_aid,

не поможет, т.к. во-первых изначально по плану видно, что оно не мерджится, а во-вторых, это ожидаемо, т.к. там внутри мало того, что деревяшка, так еще и прибита сверху аналитикой
...
Рейтинг: 0 / 0
06.12.2018, 01:10
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39743198
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sayan Malakshinov
Модератор форума
с другой стороны, если кому-то такое покажется интересным, то можно на следующем митапе RuOUG рассмотреть как пример "как не надо делать"
...
Рейтинг: 0 / 0
06.12.2018, 01:13
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39743199
Фотография кит северных морей
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
кит северных морей
Участник
xtenderне поможет, т.к. во-первых изначально по плану видно, что оно не мерджится, а во-вторых, это ожидаемо, т.к. там внутри мало того, что деревяшка, так еще и прибита сверху аналитикой
и правда. я портянку внимательно не читал

ну, значит не судьба.
...
Рейтинг: 0 / 0
06.12.2018, 01:40
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39743241
Фотография Ryuu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ryuu
Участник
кит северных морей, как и сказали, не помогло. Что же до десятков и сотен БД, отнюдь. Даже, если считать тестовые и прочие вариации, их не наберётся и десяти, и ими занимается группа админов, а не один человек.

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

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

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

xtender, я бы помог, но нет, не помогу. Спасибо. Над такими комментариями действительно думать не хочется. Но всё же, интереса ради, что вы подразумеваете под деревяшкой?
...
Рейтинг: 0 / 0
06.12.2018, 08:34
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39743247
123йй
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
123йй
Участник
RyuuНо всё же, интереса ради, что вы подразумеваете под деревяшкой?
так и вертится на языке не верный ответ
...
Рейтинг: 0 / 0
06.12.2018, 09:12
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39743273
Фотография -2-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
-2-
Участник
Ryuuк БД я полноценного доступа не имею.Опять ходишь вокруг да около. Излагай факты а не литературные домыслы. Неполноценным доступ к БД можно назвать, если он через приложение, где из функций доступно только нажать кнопку "получить отчет". Доступ можно ограничить и через sql, особые политики наворачивают на общедоступных сервисах типа sqlfiddle или livesql. Но даже на livesql можно посмотреть план и установить политику и размер области сортировки.
...
Рейтинг: 0 / 0
06.12.2018, 09:58
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39743323
Фотография DВА
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DВА
Участник
xtenderначал было писать детальный разбор, но потом мысль о бессмысленности оного победила и на 5-м пункте бросил. Не вижу смысла помогать, если человек в принципе думать не хочет.


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

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

все-таки ставлю на хинт cardinality ))
...
Рейтинг: 0 / 0
06.12.2018, 10:54
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39743330
Фотография DВА
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DВА
Участник
xtenderс другой стороны, если кому-то такое покажется интересным, то можно на следующем митапе RuOUG рассмотреть как пример "как не надо делать"
ой я те материалу-то накидаю ))))
...
Рейтинг: 0 / 0
06.12.2018, 11:04
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39743395
Фотография env
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
env
Участник
RyuuИ мне, конечно, хотелось бы разобраться в проблеме

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

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


RyuuОбычная связка. Абсолютно обычная.
Критерии обычности приведите. У аборигенов Новой Зеландии обычным до сих пор считается сожрать соседа, например. Для алкаша, обычным считается нагадить в подъезде и считать, что это проблема жильцов и уборщицы.
...
Рейтинг: 0 / 0
06.12.2018, 12:33
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39743458
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Ryuuк БД я полноценного доступа не имею.

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

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

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

RyuuОднако, когда в один день "ломается" связка таблиц,
которая исправно работала несколько лет, сказать в чем причина сложно.
То есть для тебя знать задуманный собой способ выполнения запроса и найти отличие от
реального - сложно? В детском саду есть такое упражнение для развития мозга: "найди 10
отличий между картинками". Стоило больше тренироваться, наверное.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
06.12.2018, 13:38
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39743466
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sayan Malakshinov
Модератор форума
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 в части
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
        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 в плане
 
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
 | 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:
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
      (
        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 такая же хрень и с
Код: plsql
1.
2.
3.
4.
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

-----
устал пока писать, потом продолжу...
...
Рейтинг: 0 / 0
06.12.2018, 13:43
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39743672
Фотография Ryuu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ryuu
Участник
xtender, я вам благодарен, что вы пытаетесь разобраться. Правда. Но есть один нюанс, который я не сказал, вернее, который упоминался, но он не очевиден. План запроса... от другого запроса, более тяжелого. Выложил лишь "ядро", причем несколько видоизмененное (не все поля вытащил, там где стоит tobj.*, некоторые данные есть только в тех "бессмысленных", на первый взгляд, таблицах). Для теста он более чем подходил, так как уже там сыпался. А план... как я уже упоминал, я не планировал разбираться в запросе или ещё в чем. Выложил тот, что был, и смотрел я по таймингам. Там, к слову, всё связано по индексам и нужно. Лишнего нет. Думал, мне укажут на настройку или параметр базы. На худой конец, скажут, что дерьмо случается и нужно переписать запрос, баг. Сейчас я этим вопрос не занимаюсь от слова совсем, и не планирую. Просто поглядываю тему, отчего и неудобно немного. И да, поля из таблицы pc. ZAS - это вьюшка, через union all объединяет разные таблицы, решение такое себе, но интермех альтернативу не предоставляет. И да, part_aid уникальны. В общем, если вы решили "оценить" сам запрос, занятие весьма спорное. Впрочем, я вас не от чего не отговариваю.

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

env, как вы с Dimitry Sibiryakov общаетесь в своей высокомерной манере, так вам и отвечаю. Поверьте, если бы мне в реале открыто хамили, то я точно так же бы в реале послал наглеца погулять. На этом наше "общение" с вами закончено.
...
Рейтинг: 0 / 0
06.12.2018, 16:29
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39743687
Ryuu23
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ryuu23
Гость
Ох, пришлось зарегестрироваться, чтобы внести небольшую правку. Всё моя невнимательность.
Код: plaintext
Немного соврал. Part_aid был уникален до того момента, как в интермехе появились версии в этой таблице, связка с articles нужна, чтобы подтянуть актуальную версию.
И да, раз уж меня забанили... хм. Ну и ладно. Пока. :)
...
Рейтинг: 0 / 0
06.12.2018, 16:43
| Ответить | Цитировать | Написать  
Проседание времени выполнения запроса
    #39743728
Фотография env
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
env
Участник
Ryuuкажут, что дерьмо случается и нужно переписать запрос
Тебе это говорят чуть ли не с первой страницы. Но ты упорно игнорировал это и
RyuuДумал, мне укажут на настройку или параметр базы
Как настройка или параметр повлияет на другие твои запросы, думать за тебя, видимо, тоже должны другие.

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

Ryuuenv, как вы с Dimitry Sibiryakov общаетесь в своей высокомерной манере, так вам и отвечаю
Т.е. в реале тоже на "высокомерие" отвечаешь хамством и матом? Ну хоть сам признал. Ещё есть шанс обрести воспитание и исправить речь.
...
Рейтинг: 0 / 0
06.12.2018, 17:31
| Ответить | Цитировать | Написать  
105 сообщений из 105, показаны все 5 страниц
  все  
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Проседание времени выполнения запроса
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?all=1&fid=52&tid=1883074]:
 0ms
get settings:
 6ms
get forum list:
 13ms
check forum access:
 2ms
check topic access:
 2ms
track hit:
 145ms
get topic data:
 7ms
get forum data:
 2ms
get page messages:
 92ms
get tp. blocked users:
 1ms
others: 204ms
total:  474ms
созд. / загр.: 474ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]