Ошибка при расчете себестоимости : Супермаг Плюс (Супермаг 2000)

Тогда уж
WORKAREA_SIZE_POLICY = AUTO

http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96536/ch1222.htm

так.. провел серию тестов после рабочего дня..
переиндексация... затем увиличил оба параметра:

получил... понижение производительности... неожиданно...
оцениваю следующим образом - собственно чрезвычайно долгая выборка документов (приходные накладные выбираю)...
у меня получилось вместо полутора минут за выбранный мною период (5 дней по одному из магазинов) до смены параметров, две с копейками...
вернул все обратно... далее...
расчет статистики, полный, в административном модуле... та же выборка - не дождался результата (> 5-7 минут)...
удалил статистику по схеме... просто, чтобы посмотреть, что получится...
begin
dbms_stats.delete_schema_stats(
ownname => 'supermag'
);
end;
вдруг выясняется, что теперь документы выбираются за полторы минуты... медленно, но это не предыдущий вариант...
собираю статистику тем же заданием - больше 5 минут. просто уже не дождался...
все это время системным монитором наблюдаю постоянное обращение к диску, где у меня размещены файлы userXX.dbf. при этом обращения к индексам почти нет...
да, пробовал устанавливать cursor_sharing как в EXACT, так и возвращал обратно. никакой разницы не заметил. параметр динамический, для чистоты эксперимента перезапускал экземпляр...
собственно ни к чему не пришел:)

этого не надо вообще
это бы увеличить до 10М
?
а база часом не свопается?
это не надо
cursor_sharing лучше не трогать, оно неадекватно влияет... Почтовик летает, отчеты проседают до жути.
Индексы надо отребилдить вручную, статистику собрать через analyze. Встроенным заданиям верить не надо, кроме проведения актов и сбора мусора они ничего толком не умеют.
Прочитал ветку и не понял, что проседает-то? Проц? Винты? Планы бы посмотреть. То, что ты выбрал в начале - неудачный пример.

При выборке, например, приходных накладных за некоторый период, процесс oracle.exe - 87-100%, обращение к винту, на котором лежат userx.dbf, к индексам обращения практически нет (2-10%) и очень долго формируется результат: против обычных секунд - долгие минуты.
В настоящий момент занялся перестройкой индексов по таблицам с документами...
Перестроил вручную на smspec - больше не успел - запустил пользователей - вечером продолжу...
после перестройки (а еще пересоздал первичный ключ, внешние ключи...) собрал статистику вручную (все так же):
begin
dbms_stats.gather_schema_stats (
ownname => 'SUPERMAG',
cascade => TRUE,
estimate_percent => dbms_stats.auto_sample_size,
method_opt=>'for all columns size auto'
);
end;
пока все по-прежнему...
сейчас наблюдаю обращение к юзерс - 100%, индексы тоже задействованы... такое ощущение, что действительно по какой-то из таблиц, в которой информация с документами, проблема с индексами... остальные то разделы замечательно работают...

во время выполнения выборки из своей сессии посмотрел самый массивный запрос:
отсюда обращение к представлениям, за которыми стоят указанные таблицы...
SVSpecWI(SLSPECQMISMATCH, SMCARD, SMCOMMONBASES, SMSPECCOMPINF, SMSPECIO)
SVSpecVatWI(SMSPECTAX, SMTAXIDENTITY)
SVInsertedDocsWI (SMDOCBLOBFILES)
SVDocumentsWI (SMDOCTAX, SMDOCUMENTS, SMPARTNERUSERLOC, SMTAXIDENTITY, SMWAYBILLSIN)

наверное следует для них вручную пересоздать индексы и посмотреть, что из этого получится?
еще хотел отметить достаточно быструю выборку документов, ассоциированных с артикулом в карточке товара (раздел документы). а ведь там документы разных типов... возможно выборка в этих разделах ведется из разных таблиц

только сейчас заметил - пропустил.. попробую сделать так

Тогда еще заодно и
ANALYZE TABLE problem_table VALIDATE STRUCTURE CASCADE OFFLINE

а ктонить такое видел..
1.26.1. SP4

SQL*Loader: Release 9.2.0.8.0 - Production on Чтв Ноя 20 12:54:53 2008

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

Управляющий файл: C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\PathFinder_FFMapOutIn0.CTL
Файл данных: C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\PathFinder_FFMapOutIn0.DAT
Строка опций обработки файла: "fix 123"
Файл плохих записей: C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\PathFinder_FFMapOutIn0.bad
Файл удаленных записей: ничего не задано

(Разрешить удалять все записи)

Количество записей для загрузки: ALL
Количество записей для пропуска: 0
Допускается ошибок: 0
Продолжение: ничего не задано
Использован маршрут: Прямой
Бесшумные режимы: FEEDBACK, ERRORS и DISCARDS

Таблица SUPERMAG.FFMAPOUTIN, загружен из каждой логической записи.
Режим вставки действует для этой таблицы: INSERT

Имя столбца Позиция Дл. Огр. Вкл Тип данных
------------------------------ ---------- ----- ---- ---- ---------------------
INCOMEDOC FIRST 4 INTEGER
INCOMEITEM NEXT 4 INTEGER
SALEDOC NEXT 4 INTEGER
SALEITEM NEXT 4 INTEGER
QUANTITY NEXT 8 DOUBLE
ARTICLE NEXT 50 CHARACTER
SALEOP NEXT 2 SMALL INTEGER
INCOMEOP NEXT 2 SMALL INTEGER
SALEDATE NEXT 8 DATE YYYYMMDD
INCOMEDATE NEXT 8 DATE YYYYMMDD
FORCEDMAPPING NEXT 1 CHARACTER
INCOMEQ NEXT 8 DOUBLE
INCOMETOTALSUM NEXT 10 PACKED DECIMAL (19, 4)
INCOMETOTALNOVAT NEXT 10 PACKED DECIMAL (19, 4)

SQL*Loader-929: Ошибка при синтаксическом анализе команды вставки для таблицы SUPERMAG.FFMAPOUTIN.
ORA-01031: привилегий недостаточно

такое видели ещё 2 года назад вот тут

после этой проверки, которая продолжалась много часов, а также пересоздания индексов для таблиц, которые участвуют при выборке документов (выше) ничего разительно не изменилось.
статистка была собрана, также пробовал ее удалять.
взял два запроса:
1-й участвует при выборке накладных,
2-й - тот, что используется в карточке товара (из сессии)
таблицы те же самые. только второй отрабатывает за секунды даже при большом интервале.
в первом участвуют представления.
по дискам видно, что во втором задействуются индексы.
на настоящий момент идей нет никаких, кроме как удалить представления, создать их заново (просто еще не успел)
сейчас идет расчет себестоимости, который продолжается уже почти 11 часов (операция переноса остатков)