Нестабильный запуск расчета себестоимости : Супермаг Плюс (Супермаг 2000)

На одной из баз, очень часто валится в ошибку расчет себестоимости, а точнее в запланированное для расчета время, без проблем осуществляется перенос, но дальнейшая попытка расчета сыпется. В админстративном модуле, в поле "результат последнего расчета" появляется сообщение "Расчёт 13.01.2016 0:00:10 завершён с ОШИБКОЙ". В alert.log, event logах, в логах супермага, по этому поводу абсолютная тишина. Что самое интересное, это если сразу после ошибки запустить вручную расчет себестоимости, он проходит без проблем. Как понять что не нравится расчету?

Перед расчетом стопорится почтовик, стопорится optimizer, кассового сервера тут нет, права убивать мешающие сессии есть, права в ос у сервера приложений максимальные.
При входе в админ. модуль, для ручного рассчета использую пользователя supermag. Куда копать совсем не понимаю

Версии ПО: win2008r2 x64, oracle 10.2.0.5, SM 1.031.2 SP4

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

Нечто похожее встречал в описаниях сервиспака 1 к версии 1.032.2
23.12.15 (№ 1890) SP № 1

Расчет товародвижения. Исправлено: ошибка "Расчет ПРЕРВАН на этапе: Обработка данных задачи расчета ТД" из-за удаления сессии расчета сервером приложений.
SMRepAdmin.dll, Sm.CtrlSvcPluginConst.dll, Sm.WatchDogSettings.dll, Sm.ControlService.exe, Sm.AppServer.exe

У нас такая проблема была на версии 1.032.1. может обновиться стоит ?

в 1.032.2 они эту багу и добавили, как я помню

В логах винды тоже увы ничего нет. Расчет проводится на той же машине, где крутится сама БД. Разрыв линка из-за нагрузки маловероятен, т.к. в этот момент как таковой нагрузки то и нет, а в моменты обмена с той же 1ской, возникает куда большая нагрузка и ничего не валится, да и при ручном запуске расчета проблема не проявляет себя. Ошибка возникает именно при старте расчета в авто режиме, т.е. даже не на этапе его проведения, а при самом запуске. Тоже была мысль что апдейт вылечит болезнь, просто неприятно что полнейшая тишина в логах и приходится гадать на кофейной гуще, как угодить расчету) Думал может есть тайный вариант дебага

То, что на той же машине все происходит, сеть не исключает, поскольку сливается и заливается по сети.
Насчет нагрузки - это несколько подключений и несколько потоков на этом же сервере, где крутится БД, в которой так же появляются несколько потоков.
Места на диске хватает? При ручном расчете %TEMP% другой, наверное... А дебаг пока в голову не приходит, процедура по уродски сделана.

Места на системном диске вагон(~90Гб), на остальных в разы больше. Сервер приложений даже специально запускал предварительно из под того же пользователя, из под которого делал ручной запуск расчета, что-бы переменные окружения были 100% одни и те же, соответственно %TEMP% тоже. Пробовал даже перезапускать сервер приложений за 10 минут до проведения расчета - эффекта не дает.

Несмотря на мое неприятие того, как это все сделано, я все же больше склонен отнести этот косяк к проблемам ОС.
Вариант - кривой %PATH%, где сначала идут клиентские либы? И все же попробуй уменьшить число потоков до 2, например?

В %path% все красиво, сначала серверные либы, потом клиентские, ; в конце нет.
Кол-во потоков уменьшал, все равно валится.
Сначала пишет "Обработка задачи расчета ТД", потом "расчет артикулов 0 из 96318" и тут же вываливается в ошибку.
Убивает то что в настройках журнала сервера приложений ставил даже уровень логирования "детальный", но все равно полная тишина в логах.

А никакого другого софта на серваке нет? Антивирус там, невзначай? Домен? Может, в базе в этот момент все же кто-то есть?
Попробуй на 1:13 раньше расчет поставить?