[ТЕМА ЗАКРЫТА]
31.01.2009 11:06
OlegON
 
1024.6, не знал, куда поместить, пишу здесь, ибо СМ
Итак, проблема - заказ поставщикам по одному контракту выполняется по одному из поставщиков около 15 минут по всем МХ (49). Не устроило.
Решение:
Код:
CREATE MATERIALIZED VIEW LOG ON
    "SUPERMAG"."SMSPEC"
 TABLESPACE INDX NOLOGGING
WITH ROWID,SEQUENCE("DOCTYPE","DOCID","ARTICLE")
    INCLUDING NEW VALUES;

CREATE MATERIALIZED VIEW LOG ON
    "SUPERMAG"."SMDOCUMENTS"
 TABLESPACE INDX NOLOGGING
WITH ROWID,SEQUENCE("DOCTYPE","ID","DOCSTATE","CLIENTINDEX")
    INCLUDING NEW VALUES;

CREATE MATERIALIZED VIEW LOG ON
    "SUPERMAG"."SMDATEDOCS"
TABLESPACE INDX NOLOGGING
WITH ROWID,SEQUENCE("ID","DOCTYPE","DATEDAT")
    INCLUDING NEW VALUES;

CREATE MATERIALIZED VIEW"SUPERMAG"."MV_FOR_ORDERS"
    TABLESPACE INDX NOLOGGING
REFRESH FORCE
START WITH to_date('01-31-2009 10:48:20','MM-dd-yyyy hh24:mi:ss') NEXT sysdate+30/1440
ENABLE QUERY REWRITE
    AS SELECT SUPERMAG.SMSPEC.ARTICLE C1,SUPERMAG.SMDOCUMENTS.CLIENTINDEX C2,SUPERMAG.SMDOCUMENTS.DOCSTATE 
       C3,SUPERMAG.SMDATEDOCS.DOCTYPE C4,MAX("SUPERMAG"."SMDATEDOCS"."DATEDAT") 
       M1,COUNT(*) M2 FROM SUPERMAG.SMSPEC,SUPERMAG.SMDOCUMENTS,SUPERMAG.SMDATEDOCS
       WHERE SUPERMAG.SMDATEDOCS.DOCTYPE=SUPERMAG.SMSPEC.DOCTYPE AND SUPERMAG.SMDATEDOCS.DOCTYPE
       =SUPERMAG.SMDOCUMENTS.DOCTYPE AND SUPERMAG.SMDATEDOCS.ID=SUPERMAG.SMSPEC.DOCID 
       AND SUPERMAG.SMDATEDOCS.ID=SUPERMAG.SMDOCUMENTS.ID AND (SUPERMAG.SMDOCUMENTS.DOCTYPE
       ='OR') GROUP BY SUPERMAG.SMSPEC.ARTICLE,SUPERMAG.SMDOCUMENTS.CLIENTINDEX,
       SUPERMAG.SMDOCUMENTS.DOCSTATE,SUPERMAG.SMDATEDOCS.DOCTYPE;

begin
  dbms_stats.gather_table_stats('"SUPERMAG"','"MV_FOR_ORDERS"',NULL,dbms_stats.auto_sample_size);
end;
/

CREATE BITMAP INDEX"SUPERMAG"."MV_FOR_ORDERS_INDX1"
    ON "SUPERMAG"."MV_FOR_ORDERS"
    ("C1") TABLESPACE INDX
    COMPUTE STATISTICS;

CREATE BITMAP INDEX"SUPERMAG"."MV_FOR_ORDERS_INDX2"
    ON "SUPERMAG"."MV_FOR_ORDERS"
    ("C2") TABLESPACE INDX
    COMPUTE STATISTICS;
Цитата:
query_rewrite_integrity=stale_tolerated;
INDX у меня на страйпе, NOLOGGING. Результат: предыдущая генерация - секунд за 15, по всем контрактам и поставщикам за 10 минут, сгенерировано около 3000 заказов. Жду критики.
PS при переносе пробелы пропали. прошу внимательнее :(
03.02.2009 21:18
OlegON
 
Переправил обновление вьюшки на 5 мин, операторы жаловались... Любят откатывать заказы и накатывать заново...
Еще одна фича обнаружилась, странный индекс...
Цитата:
CREATE INDEX "SUPERMAG"."SMDATEDOCS_ORDER" ON "SUPERMAG"."SMDATEDOCS"("ID","DOCTYPE","DATEDAT" DESC) TABLESPACE "INDX" PCTFREE 10 INITRANS 2 MAXTRANS 255 STORAGE (INITIAL 6144K BUFFER_POOL DEFAULT) NOLOGGING
pазбил на по ID обычным и остальные битмапчатыми индексами... Сокращение генерации заказа по конкретному поставщику - в разы.
04.02.2009 06:04
Sullen
 
Олег, а можно вот это "MAX("SUPERMAG"."SMDATEDOCS"."DATEDAT")" попробовать убрать, и посмотреть время генерации? Чисто ради интереса... Я спец "никакой" в Oracle, просто у меня в одной вьюшке, после того как убрал поле даты (в условиях отбора оставил естестно)данные стали отбираться милисекунды вместо минут...
Сам посмотреть не могу в данный момент к сожалению....
04.02.2009 10:47
OlegON
 
Не очень понял, что ты хочешь. Вот это разбиение индекса и ускоряет MAX(DATEDAT)... Откуда что убрать - не понял :(
05.02.2009 10:08
Sullen
 
MAX("SUPERMAG"."SMDATEDOCS"."DATEDAT") M1 - это поле в представлении, если я правильно понял? Вот его и предлагал убрать попробовать....
Прошу отнестись с пониманием, я не такой спец, как ты, и здоровье, чтоб разобраться со всем, уже не-то.
05.02.2009 10:18
OlegON
 
А, нет, смысла убирать его нет. Иначе работать не будет.
12.04.2009 01:21
OlegON
 
Если кто период будет открывать с этой фичей или еще какие-то еще процедуры с SMSPEC масштабные - не забудьте убрать на время, а то жесть с запросами...
13.04.2009 11:59
reddevil
 
Цитата:
OlegON 1024.6, не знал, куда поместить, пишу здесь, ибо СМ
Итак, проблема - заказ поставщикам по одному контракту выполняется по одному из поставщиков около 15 минут по всем МХ (49). Не устроило.
Решение:
Супер!!!

А можно увидеть проблемный запрос с параметрами? Посмотрю какое время бдет может так же сделать на досуге:)
13.04.2009 12:37
OlegON
 
Теперь, боюсь, не получится. Быстро пролетает. Зато у тебя видно должно быть, если заказы делают :) Главное - приучить операторов, что заказы не так быстро откатываются. Т.е. генерилку заказов сразу после операций над заказами прогонять нельзя.
01.03.2010 12:44
Pyatak
 
Цитата:
OlegON 1024.6, не знал, куда поместить, пишу здесь, ибо СМ
Итак, проблема - заказ поставщикам по одному контракту выполняется по одному из поставщиков около 15 минут по всем МХ (49). Не устроило.
Решение:...
В версии 1.027.2sp2 ничего принципиально не изменилось? Тоже поможет?
01.03.2010 15:38
OlegON
 
Не могу сказать, нет под рукой этой версии. Теоретически, поставить попробовать никто не мешает. Не поможешь - снесешь. Оно минут за 15 все ставится.
16.05.2012 21:37
OlegON
 
С+, как обычно, молчит... Маленькие пояснения. В 28.2 сделано нечто вроде кеша заказов. Только чтобы его наполнить, требуется потупить малость или запустить этот скрипт (на свой страх и риск).
Цитата:
В версии 1.028.2 для ускорения поиска даты последнего заказа была создана статистическая таблица FSLastOR, в которой в денормализованном виде содержится информация о заказах поставщикам в статусах "Размещен" и "Закрыт" за последние несколько месяцев.

Процедура автоматической генерации заказа будет искать для артикула дату последнего заказа по этой таблице. Если информация найдена не будет, то будет осуществлен поиск даты последнего заказа прежним образом, по оперативным таблицам Супермага.

Изначально таблица пуста. По мере появления заказов в указанных статусах они будут заноситься в эту таблицу.

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



--
С уважением,
Петров Владимир
Вложения
Тип файла: 7z FSLastORLoad.7z (587 байт, 110 просмотров)
Опции темы


Часовой пояс GMT +3, время: 18:58.

 

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