Тормоза с приходками : Супермаг Плюс (Супермаг 2000)

странно, я тебе предлагал оптимайзером воспользоваться, он это делает, почему не послушал...

такой я... *04

Думаю не стоит открывать новый топик...Та же проблема. Было все нормально и шустро, после обновления до версии 1024.5 sp5 через 2-3 дня начались жуткие тормоза с проведением приходных накладных.
Прочитал форум, ничего не помогает..
1) Оптимизатор Версия 2.6. отработал только с 2 предупреждениями
Версия 2.6.Строка запуска : "C:\My Downloads\optimizer\optimizer2.exe" /base:vlig01 /crk /stats /optimize

OLEGON-WARNING: compatible=8.1.0,рекомендуется равным 8.1.6
при выставлении параметра compatible=8.1.6 , база не перезапускается, говорит неверный параметр

OLEGON-WARNING: Рекомендуется не менее 10 redo-log групп
у меня сейчас 3 группы по 50М в файле, переключение оперативных журналов происходит раз в 1 час примерно, то есть на данную проблему тоже не влияет. С советом согласен, увеличу..

Лог оптимайзера здесь
Алерт лог здесь

Проверку на "новая цена ниже прихода" отключал - ускорение минимально, только в момент проверки цен, но тормоза большие еще и в момент создания актов переоценок..

Через SpotLight видел запрос, который висел долго, вытащил его в PL\SQL developer

SELECT
SP.PriceExists,SP.SpecItem,SP.DisplayItem,SP.Article,CRD.Name,
SP.ItemPrice,SP.ItemPriceNoTax,NULL,SP.TotalPrice,SP.OldPrice,
Supermag.DocExt.GetRemaindersAC ( SP.Article, SP.DocID, 0 ) ,
Supermag.DocExt.GetRemaindersAC ( SP.Article, SP.DocID, 1 ) ,
CRD.IDMeasurement,SP.Quantity
FROM SuperMag.SVSpecAC SP, SuperMag.SVCardName CRD
WHERE SP.DocType = 'AC' AND SP.DocID = 'АП130002' AND CRD.Article = SP.Article
ORDER BY DisplayItem

Достает 8 записей за 13 и более секунд!!!!! А у меня в приходниах по 190 записей!

Основное время этого запроса тратится на процедуры
Supermag.DocExt.GetRemaindersAC ( SP.Article, SP.DocID, 0 ) ,
Supermag.DocExt.GetRemaindersAC ( SP.Article, SP.DocID, 1 ) ,

Без них курсор возвращает данные через 1,5 секунды по 100 позациям.

Сейчас попробую еще экспортнуть все данные и потом импортнуть, может дефрагментация уменьшится(видать coalesce не помогает совсем), а так трындец :(( Больше даже не знаю что и придумать...

План запроса...

SELECT STATEMENT, GOAL = CHOOSE Стоимость=5 Мощность=1 Байты=107
NESTED LOOPS OUTER Стоимость=5 Мощность=1 Байты=107
NESTED LOOPS Стоимость=4 Мощность=3 Байты=273
NESTED LOOPS Стоимость=3 Мощность=3 Байты=267
TABLE ACCESS BY INDEX ROWID Владелец объекта=SUPERMAG Имя объекта=SMSPEC Стоимость=2 Мощность=3 Байты=117
INDEX RANGE SCAN Владелец объекта=SUPERMAG Имя объекта=SMCSPEC_DISPLAYPOS Стоимость=3 Мощность=3
TABLE ACCESS BY INDEX ROWID Владелец объекта=SUPERMAG Имя объекта=SMCARD Стоимость=1 Мощность=30855 Байты=1542750
INDEX RANGE SCAN Владелец объекта=SUPERMAG Имя объекта=SMCARD_PK Мощность=30855
INDEX RANGE SCAN Владелец объекта=SUPERMAG Имя объекта=SACMEASUREMENT_PK Мощность=4 Байты=8
TABLE ACCESS BY INDEX ROWID Владелец объекта=SUPERMAG Имя объекта=SMSPECACTS Стоимость=1 Мощность=1747161 Байты=27954576
INDEX RANGE SCAN Владелец объекта=SUPERMAG Имя объекта=SMCSPECACTS_PK Мощность=1747161

Да, забыл сказать все индексы у меня в одном таблспейсе, оперативные данные в другом, а аналитика в третьем..Разнес все..Эффективность нулевая..

ORA-12012: error on auto execute of job 55
ORA-01502: index 'SUPERMAG.SMCSPEC_DISPLAYPOS' or partition of such index is in unusable state
ORA-06512: at "SUPERMAG.SCHEDULE", line 293
ORA-06512: at line 1
неудивительно, что все тормозит. А про оптимизатора читай ридми и все таки запусти его, как надо.

>ORA-01502: index 'SUPERMAG.SMCSPEC_DISPLAYPOS' or partition of such index is in unusable state

Спасибо...Хм..я думал что оптимайзер при делает полную переиндексацию и это просто сообщение о том что была проблема..

сейчас запустил
SQL>alter index SUPERMAG.SMCSPEC_DISPLAYPOS rebuild;
Index altered
SQL>begin DocGoods.AutoUnreserveBI; end; --это 55 джоб
SQL>/
PL/SQL procedure successfully completed
Смотрю алертлог - ошибок нет..

Пересобрал статистику по таблице и индексу..
analyze table SUPERMAG.SMSPEC compute statistics;
analyze index SUPERMAG.SMCSPEC_DISPLAYPOS validate structure;
analyze index SUPERMAG.SMCSPEC_DISPLAYPOS compute statistics;

Стало чуть..быстрее (198 позиций в ПН).
"Наценить и принять" - "Проверка закончена" 40 секунд.
"Сохранить и зарегистрировать" - "Предупреждение" - 1 мин 20 секунд
"Зарегистрирвоать Акты" - "Акты зарегистрирвоаны" - 2 минуты 50 секунд.

Всего на ПН получается 5 минут (это при отключенной проверке ) + время на то чтобы оператор прочитал предупреждения + 2 минуты итого 7 минут..было 10.

До возникновения тормозов все это делалось секунд за 30-40..



> А про оптимизатора читай ридми и все таки запусти его, как надо.
Я весь history перечитал, так и не понял в чем я заблуждаюсь..Вроде все параметры правильные?

Параметры неправильные. Просто с ключом /optimize прогони и шифрованный лог выложи.

https://olegon.ru/index.php?name=For...iewtopic&t=827
Этот читал

>Просто с ключом /optimize прогони и шифрованный лог выложи.

Сделал как ты сказал(сначала 8 оперативных групп добавил, уже 11 по одному файлу по 50М), только проверку орключил на софт, так как гоняю базу на своем компе в офисе, котрый по характеристикам такой - же как и сервер, а боевая стоит в магазине и меры надо принимать "уже вчера"..

>Этот читал
Да, галочка на ассортиментах с "Автоматически" убрана везде..

После прогона оптимайзера 198 позиций в ПН
"Наценить и принять" - "Проверка закончена" 40 секунд.
"Сохранить и зарегистрировать" - "Предупреждение" - 1 мин 25 секунд
"Зарегистрировать Акты" - "Акты зарегистрирвоаны" - 2 минуты 40 секунд.

Акты регистрирвоались на 10 секунд быстрее :((

На самом деле работать надо с боевой машиной, оптимизируешь свою рабочую, а сервак не сможешь, вот это будет смешно. На самом деле обрати внимание на проверку цен предыдущего прихода. Не очень понятно, как ты ее отключил. И скажи, 1) какие именно ожидания на этом запросе? План, вроде, неплохой... 2) Чем в этот момент сервак занимается? Проц грузит или винт? Точно этот запрос стопится? Убей индекс DISPLAYPOS и создай его заново, статистику посчитай.