09.10.2006 11:25
reddevil
 
set timing on
alter table ffmaprep parallel 4;
alter table ffmaprep_ parallel 4;
SELECT /*+ full(f)*/ count(*) from FfMAPREP f;
SELECT /*+ full(f)*/ count(*) from FfMAPREP_ f;

покажи
09.10.2006 12:42
isi
 
Table altered.
Elapsed: 00:00:01:14
Table altered.
Elapsed: 00:00:00:00

COUNT(*)
----------
20130032

1 row selected.
Elapsed: 00:01:27:46

COUNT(*)
----------
0

1 row selected.
Elapsed: 00:00:00:04
09.10.2006 13:02
isi
 
время обработки при parallel 4 увеличивается в 3-4 раза
09.10.2006 13:09
OlegON
 
Цитата:
isi время обработки при parallel 4 увеличивается в 3-4 раза
это при убитой статистике?... Я бы все таки статистику не убивал. Сколько раз напарывался, что убивание ее приводило к лишнему кругу оптимизации.
09.10.2006 13:14
isi
 
сейчас попробую восстановить и повторить запросы, если я по большим таблицам сделаю parallel, мне что-то ещё надо оптимизировать кроме этого? (например статистику хотя бы пересобрать?)
09.10.2006 13:23
reddevil
 
Цитата:
isi время обработки при parallel 4 увеличивается в 3-4 раза
тогда можешь попробовать - степень 2(но допускаю что и она проиграет последовательному выполнения - т.к. дисков и процов мало), однако 20130032 - за 30 секунд в принципе неплохо. например у меня
Код:
&usernm>> select /*+ full(f) parallel(f 5)*/ count(*) from ffmaprep f;

  COUNT(*)
----------
  41991988

Executed in 37,562 seconds
(10 винтов райд 5+0) то есть у тебя производительность дисков вполне на уровне

чтобы оптимизировать отчеты можешь секционировать табло и закрыть период.
09.10.2006 14:03
isi
 
спасибо большое, после сбора статистики получилось

COUNT(*)
----------
20130032

1 row selected.
Elapsed: 00:00:21:31

вечером сегодня распарарелю основные таблицы, проверю реальный результат работы
12.10.2006 04:53
isi
 
По аналитическим таблицам вопрос снялся, все стало работать нормально после ваших рекоминдаций, сделал тоже самое для остальных больших таблиц (smspec и т.д.) , результат нулевой.

Есть такой отчет: Журнал покупок/продаж.
До перехода на 9i период в 1 день крутился меньше минуты, теперь я его дождаться не могу. Выполняется пара запросов:

один на вставку в таблицу ttcrdtax - работает быстро, отбирает примерно 50 тыс строк

и второй на котором все умирает:

Код:
SELECT nvl(c.name, :sys_b_00) AS clientname, c.inn, decode(o.incometype, 
       :sys_b_01, :sys_b_02, :sys_b_03) doc_in, d.id, d.createdat, nvl(
       d.locationto, d.locationfrom) locid, sum(s.totalprice) totalsum, 
       :sys_b_04, :sys_b_05 gr3, to_char(d.createdat, :sys_b_06) gr2, sum(
       decode(nvl(t.taxrate, :sys_b_07), :sys_b_08, nvl(t.taxsum, :sys_b_09), 
       :sys_b_10)) vat10, sum(decode(nvl(t.taxrate, :sys_b_11), :p_vatrate, 
       nvl(t.taxsum, :sys_b_12), :sys_b_13)) vat20, sum(decode(nvl(t.taxrate, 
       :sys_b_14), :sys_b_15, decode(tc.vatrate, :sys_b_16, :sys_b_17, 
       s.totalprice - nvl(tt.taxsum, :sys_b_18)), :sys_b_19)) freevat, 
       sum(decode(nvl(t.taxrate, :sys_b_20), :sys_b_21, decode(tc.vatrate, 
       :sys_b_22, s.totalprice - nvl(tt.taxsum, :sys_b_23), :sys_b_24), 
       :sys_b_25)) sum0, sum(decode(nvl(t.taxrate, :sys_b_26), :sys_b_27, 
       s.totalprice - nvl(t.taxsum, :sys_b_28) - nvl(tt.taxsum, :sys_b_29), 
       :sys_b_30)) sum10, sum(decode(nvl(t.taxrate, :sys_b_31), :p_vatrate, 
       s.totalprice - nvl(t.taxsum, :sys_b_32) - nvl(tt.taxsum, :sys_b_33), 
       :sys_b_34)) sum20, sum(s.totalprice - nvl(tt.taxsum, :sys_b_35))
       sum_nonsp
    FROM supermag.saoperation o, supermag.smdocuments d, 
         supermag.smclientinfo c, supermag.smspec s, supermag.smspectax t, 
         supermag.smspectax tt, supermag.ttcrdtax tc
    WHERE o.accountflag = :sys_b_36
      AND (o.incometype = :sys_b_37
      AND o.expensetype = :sys_b_38
      OR  o.incometype = :sys_b_39
      AND o.expensetype = :sys_b_40)
      AND o.id = d.opcode
      AND d.doctype IN (:sys_b_41, :sys_b_42, :sys_b_43, :sys_b_44, :sys_b_45, 
           :sys_b_46)
      AND d.createdat BETWEEN to_date(:sys_b_47, :sys_b_48) AND to_date(
          :sys_b_49, :sys_b_50)
      AND d.docstate >= :sys_b_51
      AND nvl(d.locationto, d.locationfrom) = :sys_b_52
      AND d.clientindex = c.id (+)
      AND s.docid = d.id
      AND s.doctype = d.doctype
      AND tc.article = s.article
      AND s.docid = t.docid (+)
      AND s.doctype = t.doctype (+)
      AND s.specitem = t.specitem (+)
      AND :p_vat_id = t.taxid (+)
      AND s.docid = tt.docid (+)
      AND s.doctype = tt.doctype (+)
      AND s.specitem = tt.specitem (+)
      AND :p_nsp_id = tt.taxid (+)
    GROUP BY c.name, c.inn, d.id, d.createdat, nvl(d.locationto, d.locationfrom
             ), :sys_b_53, :sys_b_54, decode(o.incometype, :sys_b_55, :sys_b_56, 
             :sys_b_57)
    ORDER BY :sys_b_58 ASC, :sys_b_59 ASC, :sys_b_60 ASC, :sys_b_61 ASC, 
             :sys_b_62 ASC, :sys_b_63 ASC, :sys_b_64 ASC, :sys_b_65 ASC
Вот такой план запроса светится в Enterprise Console:


Код:
23  SELECT STATEMENT 
22  SORT [ORDER BY] 
21  SORT [GROUP BY] 
20  FILTER 
19  NESTED LOOPS [OUTER] 
16  NESTED LOOPS 
13  NESTED LOOPS [OUTER] 
10  NESTED LOOPS [OUTER] 
7  NESTED LOOPS 
4  NESTED LOOPS 
1  SUPERMAG.TTCRDTAX TABLE ACCESS [FULL] 
3  SUPERMAG.SMSPEC TABLE ACCESS [BY INDEX ROWID] 
2  SUPERMAG.SMSPEC_ART INDEX [RANGE SCAN] 
6  SUPERMAG.SMDOCUMENTS TABLE ACCESS [BY INDEX ROWID] 
5  SUPERMAG.SMCDOCUMENTS_PK INDEX [UNIQUE SCAN] 
9  SUPERMAG.SMSPECTAX TABLE ACCESS [BY INDEX ROWID] 
8  SUPERMAG.SMCSPECTAX_PK INDEX [UNIQUE SCAN] 
12  SUPERMAG.SMSPECTAX TABLE ACCESS [BY INDEX ROWID] 
11  SUPERMAG.SMCSPECTAX_PK INDEX [UNIQUE SCAN] 
15  SUPERMAG.SAOPERATION TABLE ACCESS [BY INDEX ROWID] 
14  SUPERMAG.SACOPERATION_PK INDEX [UNIQUE SCAN] 
18  SUPERMAG.SMCLIENTINFO TABLE ACCESS [BY INDEX ROWID] 
17  SUPERMAG.SMCCLIENTINFO_PK INDEX [UNIQUE SCAN]
12.10.2006 08:36
OlegON
 
Что могу порекомендовать, либо ловить, какие конкретно ожидания идут на этом запросе, либо просто ткнуть его в Quest Central есть SQL Optimization wizard. По его советам либо поймешь, что делать, либо узкие места всплывут.
18.10.2006 12:36
isi
 
Привел запрос к "рабочему" виду с реальными параметрами, план запроса нормальный, убираю из запроса временную таблицу ttcrdtax, все быстро, как только цепляю её, то все наглухо, часа на 2 при нулевой активности юзеров. Если учесть сколько в ней записей, то очень долго... Как проверить ожидания , когда идет запрос...
Часовой пояс GMT +3, время: 10:12.

Форум на базе vBulletin®
Copyright © Jelsoft Enterprises Ltd.
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.