Форум OlegON > Программы и оборудование для автоматизации торговли > Системы автоматизации торговли > Супермаг Плюс (Супермаг 2000)

Скорость формироания отчёта "Товар без движения" : Супермаг Плюс (Супермаг 2000)

28.03.2024 19:30


12.03.2008 16:40
creosote
 
СМ 1.024.6 SP3
Oracle 9.2.0.1.0
У меня этот отчёт делается очень долго (больше 3-х часов).
В 12 запустил этот отчёт по 2 группам, содержащим в сумме 3495 артикулов, 48 мест хранения, с параметрами Показать сумму в ценах последних приходов и Показать поставщиков последних приходов, Вид движения - продажа, период - 1 месяц.
Отчёт формируется до сих пор (16:30) в стадии "Фоновый процессор отчётов". На базе без пользователей, после оптимизации этот же отчёт, но по всем товарам (более 40000 артикулов), за 2 месяца делается 2 часа 30 минут. Нормально ли это и если нет, то куда копать? Подскажите, у кого и на каких данных с какой скоростью формируется этот отчёт?
12.03.2008 16:48
Mihon
 
А RollBack Segment не переполнены? Посмотри RBS-ы.
И вообще табличные пространства.
12.03.2008 17:00
creosote
 
Цитата:
Mihon А RollBack Segment не переполнены? Посмотри RBS-ы.
И вообще табличные пространства.
INDX 70 Гб использовано 73%
SYSTEM 1 Гб использовано 25%
UNDOTBS 6 Гб использовано 76% (это и есть мои RBS-ы)
USERS 80 Гб использовано 50%
TEMP 12 Гб использовано 76%

UNDOTBS не переполняется, ошибки не выдаёт.
12.03.2008 17:22
Mtirt
 
Если честно, надо внимательно смотреть ВСЕ настройки работы базы.
Потому что:
-может быть дело в неправильных настройках памяти, и поэтому постоянно что-то пишется на диск.
-может быть дело в неправильно собранной статистике.
-может проблемы кроются в дисковых массивах.

Для выявления этого надо неплохо знать Оракл.
И оптимайзер здесь может уже и не помочь... База не такая уж и маленькая. Нужна тонкая индивидуальная настройка.

Самый простой вариант - заплатить денег Олегу и попросить его помониторить поведение базы.
Когда-то его вмешательство ускорило у меня работу раз в 10...

Другие варианты - изучить оракл самостоятельно, хорошо покопаться в интернете и т.п.
12.03.2008 17:39
creosote
 
Цитата:
Mtirt И оптимайзер здесь может уже и не помочь... База не такая уж и маленькая. Нужна тонкая индивидуальная настройка.

Самый простой вариант - заплатить денег Олегу и попросить его помониторить поведение базы.
Когда-то его вмешательство ускорило у меня работу раз в 10...
С удовольствием заплатил бы денег Олегу для мониторинга базы, отчасти для этого мне и необходим ваш опыт формирования данного отчёта, для предоставления начальству сравнительных данных. Если не затруднит - опишите параметры отчёта и приблизительное время работы на вашей базе, с указанием общего размера базы.
12.03.2008 17:51
OlegON
 
Думаю, сравнение здесь бессмысленно. Ибо зависит не от размера базы, а от количества документов, пропорции заполненности у каждого разные. Отчет тяжелый однозначно, не знаю, что насчет трех часов, но выполняться будет долго однозначно. Начать с больной темы - поиск последнего прихода, была тогда тема, что неоптимальный запрос клал все подобные отчеты и процедуры на раз. Версию, где поправили, не помню. Оценивать надо не по времени выполнения, а по плану самого длинного запроса.
12.03.2008 18:02
creosote
 
Дольше всего висит этот insert, собственно где-то с 13:00 и висит

INSERT INTO ttremains
(storeloc, article, quantity)
(SELECT location, article, -sum(quantity) quantity
FROM (SELECT l.id location, s.article, sum(s.quantity * decode(l.id,
d.locationto, 1, d.locationfrom, -1, 0)) quantity
FROM smdocuments d, smstorelocations l, smspec s
WHERE d.doctype = s.doctype
AND d.id = s.docid
AND l.id IN (d.locationto, d.locationfrom)
AND l.id IN (1, 2, 4, 5, 6, 10, 11, 12, 13, 15, 16, 17, 19,
20, 21, 24, 25, 27, 29, 30, 31, 33, 34, 38, 40, 41,
47, 48, 55, 57, 58, 60, 61, 62, 63, 64, 65, 66, 67,
68, 69, 70, 72, 73, 74, 75, 76, 77)
AND d.docstate >= 2
AND d.createdat > to_date('28.01.2008', 'DD.MM.YYYY')
AND s.article IN (SELECT fdata
FROM ttfilterstr
WHERE ftype = 1)
GROUP BY l.id, s.article
HAVING sum(s.quantity * decode(l.id, d.locationto, 1,
d.locationfrom, -1, 0)) <> 0
UNION ALL
SELECT storeloc, article, -quantity
FROM smgoods
WHERE quantity <> 0
AND storeloc IN (1, 2, 4, 5, 6, 10, 11, 12, 13, 15, 16, 17,
19, 20, 21, 24, 25, 27, 29, 30, 31, 33, 34, 38, 40,
41, 47, 48, 55, 57, 58, 60, 61, 62, 63, 64, 65, 66,
67, 68, 69, 70, 72, 73, 74, 75, 76, 77)
AND article IN (SELECT fdata
FROM ttfilterstr
WHERE ftype = 1))
GROUP BY location, article
HAVING sum(quantity) <> 0)
13.03.2008 02:34
avl2007
 
Сюдя по моему плану выполнения твоего запроса, висеть долго он не должен. Вот план:

Цитата:
SELECT STATEMENT, GOAL = CHOOSE Cost=295 Cardinality=140 Bytes=7420
FILTER
SORT GROUP BY Cost=295 Cardinality=140 Bytes=7420
VIEW Object owner=SUPERMAG Cost=291 Cardinality=140 Bytes=7420
UNION-ALL
FILTER
SORT GROUP BY Cost=251 Cardinality=1 Bytes=87
NESTED LOOPS Cost=248 Cardinality=2 Bytes=174
HASH JOIN SEMI Cost=245 Cardinality=3 Bytes=249
TABLE ACCESS BY INDEX ROWID Object owner=SUPERMAG Object name=SMSPEC Cost=3 Cardinality=44 Bytes=1188
NESTED LOOPS Cost=241 Cardinality=3388 Bytes=189728
TABLE ACCESS BY INDEX ROWID Object owner=SUPERMAG Object name=SMDOCUMENTS Cost=10 Cardinality=77 Bytes=2233
INDEX RANGE SCAN Object owner=SUPERMAG Object name=SMDOCUMENTS_CREATEDAT Cost=2 Cardinality=131
INDEX RANGE SCAN Object owner=SUPERMAG Object name=SMCSPEC_DISPLAYPOS Cost=2 Cardinality=3
VIEW Object owner=SYS Object name=VW_NSO_2 Cost=2 Cardinality=82 Bytes=2214
INDEX RANGE SCAN Object owner=SUPERMAG Object name=TTFILTERSTR_PK Cost=2 Cardinality=82 Bytes=3280
INLIST ITERATOR
INDEX RANGE SCAN Object owner=SUPERMAG Object name=SMCSTORELOCATIONS_PK Cost=1 Cardinality=1 Bytes=4
HASH JOIN SEMI Cost=40 Cardinality=139 Bytes=5560
TABLE ACCESS FULL Object owner=SUPERMAG Object name=SMGOODS Cost=19 Cardinality=47038 Bytes=611494
VIEW Object owner=SYS Object name=VW_NSO_1 Cost=2 Cardinality=82 Bytes=2214
INDEX RANGE SCAN Object owner=SUPERMAG Object name=TTFILTERSTR_PK Cost=2 Cardinality=82 Bytes=3280
Скажи какое у тебя железо под сервером, как датафайлы лежат по дискам, какой рейд, какая ОС и файл параметров оракла.
13.03.2008 08:16
kadr
 
Цитата:
creosote Oracle 9.2.0.1.0
Патчиться и желательно как можно скорее до 9.2.0.8

Цитата:
creosote С удовольствием заплатил бы денег Олегу для мониторинга базы, отчасти для этого мне и необходим ваш опыт формирования данного отчёта, для предоставления начальству сравнительных данных. Если не затруднит - опишите параметры отчёта и приблизительное время работы на вашей базе, с указанием общего размера базы.
Никогда не считал показателем для оценки базы, ты бы лучше привёл описание железа, расположение ТС по дискам.
посмотрел бы события ожидания, что именно ожидает запрос.
13.03.2008 12:02
creosote
 
Цитата:
avl2007 Скажи какое у тебя железо под сервером, как датафайлы лежат по дискам, какой рейд, какая ОС и файл параметров оракла.
тут лежит отчёт о системе моей.

Файлы:
INDX - 34 по 2Гб на отдельном винте, диск H
SYSTEM - 1 по 1Гб на диске D
TEMP - 6 по 2Гб на диске D
UNDOTBS - 3 по 2Гб на диске D
USERS - 24 по 2Гб на отдельном винте, диск E
USERF - 14 по 2Гб на отдельном винте, диск F

USERS и USERF это всё под юзеров
SYSTEM, TEMP и UNDOTBS на одном винте
Система на отдельном винте, диск С.
Часовой пояс GMT +3, время: 19:30.

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