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

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

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

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

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

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

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

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

Posted via ActualForum NNTP Server 1.5

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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