[ОТВЕТИТЬ]
21.10.2010 09:28
AlexeyF
 
Супермаг 1.026.4 SP3

Не считается себестоимость
сделана полная очистка базы, данные перенеслись. При самом расчёте товародвижения простые артикулы рассчитываются, но когда идёт расчёт производства движение останавливается на 1437 артикуле. При этом оракл грузит одно ядро процессора на 100 процентов. Дисковый ввод-вывод на минимуме. 25кб/сек запись, 5кб/сек чтение

Так же не закрывается период в производстве - просто зависание, когда период в производстве закрыть пытаюсь. Просто период закрывать получается нормально.

Люди добрые, подскажите плз что и где посмотреть что бы определить с чем проблема в производстве моём ? Может артикул какой то косячит (1437-й), но как посмотреть какой конкретно ?
21.10.2010 09:33
Mtirt
 
Предложение обновить Супермаг вас не устроит?
В версиях 1.027-1.027.3 С+ работал над повышением быстродействия расчета себестоимости как раз в производстве.
21.10.2010 10:03
AlexeyF
 
в том и дело что не тормозит, а стоит на месте. Сильно подозреваю что дело в конкретном артикуле. А как посмотреть/вычислить этот артикул - не знаю. Подскажите, есть какая то возможность определить на каком конкретном артикуле останавливается расчёт ?
Про прелести улучшения себестоимости в производстве в последних версиях я знаю. Хочу обновиться, но пока не могу. Ещё не потянут мои сотрудники 27 магазинов за раз обновить.
21.10.2010 10:27
John Doe
 
Думается, что если заглянешь в лог оптимизатора запущенного в момент простоя, то увидишь insert, который ищешь. А потом сможешь построить план этого запроса и сделать определенные далекоидущие выводы :) А то и победить заразу. Но я бы обновился, потому, что бороться там по большому счету долго, а в свете новой версии - бессмысленно.
21.10.2010 12:11
AlexeyF
 
а если без оптимизатора ?
21.10.2010 12:14
Mtirt
 
Парсинг сессии?
Спотлайтом посмотреть что делает в этот момент эта сессия?
Данные выбирает, ждет чего-нибудь и т.д.?
22.10.2010 08:52
AlexeyF
 
посмотрел. Висит там insert, диск не задействован, оракл на 100%
забыл сказать оракл 10.2.0.4.0

смотрю логи, там единственное похожее на ошибку:
Thread 1 cannot allocate new log, sequence 4328
22.10.2010 09:48
AlexeyF
 
Mtirt, не ругайте - это не вопрос, это просто выговориться надо :)
К тому что уже написал про ситуацию добавить пока нечего.
Про версию оракла забыл в самом начале указать.
Трэйс сессии надо было до её начала запускать.
Посмотреть что делает - посмотрел jSessionWork (много нового :) ) оттуда и почерпнул что insert висит.
На самом деле буду базу оптимизировать и перенастраивать. Это чепяльно, т.к. приходится слишком много нового и быстро пытаться впитывать.
На "Thread 1 cannot allocate new log, sequence" - нашёл рекомендации, буду базу в соответствие приводить. Единственное - это время, которого не достаточно. Т.е. достижение изначальной цели, для которой эта база заводилась, откладывается.
24.03.2011 10:45
AlexeyF
 
версия оракла 10.2.0.4.0 64-bit
Ну вот и свершилось - перешёл на БД 1.027.5 SP4 и снова старая ошибка...

Выполнена полная очистка базы, выполнен перенос данных для аналитики, жму рассчитать, включая производство. Расчёт основной нормально, расчёт в производстве встаёт уже второй раз на одном и том же документе (примерно 1/3 бара). Полная остановка расчёта, оракл работает в обычном режиме. Смотрю сессию в оракле там вроде простые запросы висят. Но какой именно товар производства обрабатывается в моменте понять не могу - не вижу в повисшем сеансе оракла.

Опять вопрос что и как мониторить, что бы вылавливать всётаки причины такой ошибки ? Или что посмотреть в момент остановки расчёта ? В логах супермага и оракла ошибок нет - всё в штатном режиме.
24.03.2011 10:58
Mtirt
 
Судя по вчерашнему списку изменений 1.028.1 , это происходит на этапе предварительного рассчета:
Цитата:
Расчет товародвижения в производстве. Нотификация хода расчета.

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

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

В текущей версии нотификация хода расчета дополнена сообщением о расчете себестоимости приходов для группы артикулов. Внесены также изменения в процедуру расчета себестоимости для сокращения времени расчета на больших объемах данных.
Так что ждать и надеяться...
24.03.2011 10:58
John Doe
 
LongOps есть какие-нибудь?
24.03.2011 13:10
AirAir
 
Цитата:
John Doe LongOps есть какие-нибудь?
Что такое LongOps? есть представление v$session_longops - там можно увидеть долговыполняющиеся запросы, а LongOps - это что жаргон или что, я думаю не всем понятно!!!
24.03.2011 13:12
serj_
 
Цитата:
Mtirt Судя по вчерашнему списку изменений 1.028.1 , это происходит на этапе предварительного рассчета:


Так что ждать и надеяться...
Провисело всю ночь на одном и том же месте. документы в базе с 2008 года. Как диагностировать проблему.
24.03.2011 14:13
John Doe
 
Цитата:
AirAir Что такое LongOps? есть представление v$session_longops - там можно увидеть долговыполняющиеся запросы, а LongOps - это что жаргон или что, я думаю не всем понятно!!!
Главное - без паники. Да, это действительно долго выполняющиеся операции. В журнале оптимизатора они помечены LongOps, я их и привык так звать.
24.03.2011 14:19
AirAir
 
Никакой паники нет! Но не все пользуются оптимизаторами и поэтому ни сразу понятно что Вы подразумевали.
24.03.2011 17:02
serj_
 
Вот что висит в базе:
Код:
Index Fast Full Scan:  SUPERMAG.FFSPEC: 162940 out of 162940 Blocks done
Table Scan:  SUPERMAG.FFPRODOUTSPEC: 75383 out of 75383 Blocks done
Table Scan:  SUPERMAG.FFPRODOUTSPEC: 75383 out of 75383 Blocks done
Table Scan:  SUPERMAG.SMSTOCKLEVELS: 10103 out of 10103 Blocks done
Table Scan:  SUPERMAG.SMSTOCKLEVELS: 10103 out of 10103 Blocks done
и в нескольких сессиях запрос:
Код:
SELECT s.docid, s.doctype, 0 isincome, s.createdat, s.specitem, s.article, 
       s.quantity * 1000, s.totalsum
    FROM supermag.ffprodoutspec s
    WHERE s.createdat BETWEEN to_date('20081014', 'YYYYMMDD') AND to_date(
          '20110322', 'YYYYMMDD')
      AND s.storeloc = :v00001
      AND s.zoneid = :v00002
      AND s.article = :v00003
    ORDER BY s.createdat, decode(s.doctype, 'PD', 0, 'PO', 2, 3), s.docid, 
             s.specitem
24.03.2011 17:26
AlexeyF
 
Я понимаю когда что то происходит - тогда можно и подождать. Но процессор не занят, дисковых операций у оракла практически нет (пара килобайт запись), операций ввода-вывода у процесса SMAdmin.exe нет совсем ни байта. Т.е. сервер баз данных стоит совсем. Как тут можно ждать ? На что надеяться ?
24.03.2011 21:04
OlegON
 
Если принципиальное неприятие оптимайзера, то хоть будьте последовательны в показаниях (запрос у serj_ содержит два разных среза). Если нет лога оптимизатора, то те несколько килобайт описания ситуации, которые выдает он, вам предстоит сделать вручную. Расчет на одном сервере? Полная неподвижность? Ищите залочки... Но не верится... Можно попробовать в один поток считать.
25.03.2011 04:52
serj_
 
Ответ нашел тут: https://olegon.ru/showthread.php?t=3...outspec&page=3

перевел аналитические таблицы FF... в NOLOGGING посчиталось за 8 часов
Опции темы


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

 

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