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

СМ 1.024.6 SP3
Oracle 9.2.0.1.0
У меня этот отчёт делается очень долго (больше 3-х часов).
В 12 запустил этот отчёт по 2 группам, содержащим в сумме 3495 артикулов, 48 мест хранения, с параметрами Показать сумму в ценах последних приходов и Показать поставщиков последних приходов, Вид движения - продажа, период - 1 месяц.
Отчёт формируется до сих пор (16:30) в стадии "Фоновый процессор отчётов". На базе без пользователей, после оптимизации этот же отчёт, но по всем товарам (более 40000 артикулов), за 2 месяца делается 2 часа 30 минут. Нормально ли это и если нет, то куда копать? Подскажите, у кого и на каких данных с какой скоростью формируется этот отчёт?

А RollBack Segment не переполнены? Посмотри RBS-ы.
И вообще табличные пространства.

INDX 70 Гб использовано 73%
SYSTEM 1 Гб использовано 25%
UNDOTBS 6 Гб использовано 76% (это и есть мои RBS-ы)
USERS 80 Гб использовано 50%
TEMP 12 Гб использовано 76%

UNDOTBS не переполняется, ошибки не выдаёт.

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

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

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

Другие варианты - изучить оракл самостоятельно, хорошо покопаться в интернете и т.п.

С удовольствием заплатил бы денег Олегу для мониторинга базы, отчасти для этого мне и необходим ваш опыт формирования данного отчёта, для предоставления начальству сравнительных данных. Если не затруднит - опишите параметры отчёта и приблизительное время работы на вашей базе, с указанием общего размера базы.

Думаю, сравнение здесь бессмысленно. Ибо зависит не от размера базы, а от количества документов, пропорции заполненности у каждого разные. Отчет тяжелый однозначно, не знаю, что насчет трех часов, но выполняться будет долго однозначно. Начать с больной темы - поиск последнего прихода, была тогда тема, что неоптимальный запрос клал все подобные отчеты и процедуры на раз. Версию, где поправили, не помню. Оценивать надо не по времени выполнения, а по плану самого длинного запроса.

Дольше всего висит этот 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)

Сюдя по моему плану выполнения твоего запроса, висеть долго он не должен. Вот план:

Скажи какое у тебя железо под сервером, как датафайлы лежат по дискам, какой рейд, какая ОС и файл параметров оракла.

Патчиться и желательно как можно скорее до 9.2.0.8

Никогда не считал показателем для оценки базы, ты бы лучше привёл описание железа, расположение ТС по дискам.
посмотрел бы события ожидания, что именно ожидает запрос.

тут лежит отчёт о системе моей.

Файлы:
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 на одном винте
Система на отдельном винте, диск С.