[ОТВЕТИТЬ]
17.06.2008 03:22
isi
 
Sm 1.025.1 SP3 + Oracle 9.2.0.8 + w2k3

При расчете ТД стабильно в одном и том же месте прерывается с сообщением: "расчет прерван по команде пользователя".

Раньше на какой то версии была такая же проблема, но решалась запуском по времени и отключением от сессии RDP, пока расчет не закончиться.

Основной расчет ТД проходит, данные в аналитике есть, в момент после расчета 60-го производственного участка срабатывает отмена, не помогает ни какие манипуляции с терминальными сессиями, у нас есть консоль, пробовал даже через неё запускать, стабильно в одном месте, такое чувство, что завелась эта проблема после добавления производственных участков, раньше их было 59.

Вопрос к тому, кто ведет производство, есть ли у кого большее кол-во участков?

Странно, не первый год работаю с СМ, не думал что на ровном месте проблему поймаю.

Да при этом создается файл расчета FFprodRep, загружаю его в БД и ручками поставляю дату в окончание расчета. Работать то как то надо.

Уже 3 недели не могу решить данную проблему

Пожелание бы к С+ оформить о разделении расчета производства и основного расчета, производство нет необходимости (у нас) часто считать, а считается при мизерных объемах долго.
17.06.2008 11:19
OlegON
 
А в алерте базы ничего нет?
17.06.2008 11:55
isi
 
Ни в алерте (тупо переключения редо), ни в логах СМ, ни в логах системы. Сегодня "снес" не используемые производственные участки (уж очено я на них грешу, хотя по логике вещей не должно влиять), в выходные буду пробовать ещё раз считать...
17.06.2008 20:45
YuraZ
 
Так в какой то из версий был такой глюк. Только не помню в какой.
18.06.2008 02:34
isi
 
Был, только давно, в моей считался исправно уже год
14.07.2008 02:49
isi
 
Продолжение истории, поднял тестовый сервер, запустил там, результат
теперь не выскакивает сообщение об отмене пользователем но и не завершается процес расчета, "тупо" ничего не происходит, сегодня на серваке мне админский модуль написал out of memory сожрав при этом почти 2 гига оперативы (виртуал) (всего 4 физ). Где то утечка при чем в цикле, который возникает из за возможно кривости данных в БД, но посмотреть такие объемы визуально... различные мысли в запросах результата не принесли...

пока все...
10.09.2008 07:33
isi
 
Ситуация продолжается:
1. Перешел на Sm 1.026.1 SP2 + Oracle 10.2.0.3 x64 + w2k3 x64
ничего не изменилось
2. снес за год все документы производства, ошибка стала информативнее:
===========
Ошибка считывания данных из базы.
Ошибка при загрузке данных для производственного участка 1 - Шелехов
Out of memory.
===========

Кто нить ведет активно производство в Супермаге?, есть подозрения на ошибку в расчете ТД по производству, из за чего возникает ищу сейчас

Кто ведет производство скинте результаты следующего запроса:
Код:
SELECT   doctype, COUNT (doctype)
    FROM smspec
   WHERE doctype LIKE '%P%'
GROUP BY doctype
10.09.2008 09:46
OlegON
 
У меня аналогичное было с бекапом, система ругалась и клялась, что памяти не хватает, поймать это никак не мог. Выяснилась очень неожиданная вещь с делением файлов. Без ограничения - ругалась на память, но у меня по мониторам с ней было все ок. С ограничением размера выдаваемого файла в 1Гб все нормализовалось... Может /3Gb ей включить? И посчитать на клиенте?
10.09.2008 10:01
kadr
 
Версия СМ 1.026.1 СП2 Oracle 9.2.0.4 Бд на SLES9, расчёт производится на клиентской машине WinXP (512 Мб ОЗУ). Всё 32-х битное

Ошибок не выдавал, просто при расчёте ТД по одному из производственных участков занимался этим по неск. суток (ни разу не дождались окончания). Накинули памяти на Виндовой машине до 3Гб расчёт стал успешно завершаться.
10.09.2008 10:39
isi
 
Цитата:
kadr Версия СМ 1.026.1 СП2 Oracle 9.2.0.4 Бд на SLES9, расчёт производится на клиентской машине WinXP (512 Мб ОЗУ). Всё 32-х битное

Ошибок не выдавал, просто при расчёте ТД по одному из производственных участков занимался этим по неск. суток (ни разу не дождались окончания). Накинули памяти на Виндовой машине до 3Гб расчёт стал успешно завершаться.
У меня это на серваке с 4 гигами, все таки выполните мой запрос
Для уменьшения размера расчета снимаю сейчас документы за прошлые периоды
10.09.2008 10:42
isi
 
Цитата:
OlegON Выяснилась очень неожиданная вещь с делением файлов. Без ограничения - ругалась на память, но у меня по мониторам с ней было все ок. С ограничением размера выдаваемого файла в 1Гб все нормализовалось...
Брррр... чет я не понял, ты имеешь ввиду файлы данных oracle? у меня они по 10 G фиксированным размером, на 9 были по 2G так же фиксированным.
10.09.2008 11:23
OlegON
 
Немного не правильно описал :) Ну, как человеку грамотному переводить не буду, пока maxpiecesize в RMAN не выставил в гиг, на самбу оно бекап не делало. Впрочем, и на другие FS тоже. Работало, хрясь, перестало...
10.09.2008 12:54
isi
 
У меня проблема то в том, что в этот момент он формирует файл для загрузки в таблицу расчета товародвижения производства и ничего не пишет в базу, проблема в самом модуле расчета товародвижения, в базе все гуд в этот момент, это точно
10.09.2008 13:13
kadr
 
это там где были проблемы с расчётом ТД по произ. цехам
Цитата:
1 PD 338445
2 PE 35908
3 PN 166
4 PO 248515
5 RP 2066
а это с другой базы, побольше общим размером
Цитата:
1 PD 139520
2 PE 186781
3 PN 53
4 PO 136768
5 RP 265
10.09.2008 13:18
isi
 
забыл сказать, я считаю только в центральной, у кого больше чем мои значения и нормально считается сообщите, отмету тогда предположение свое:
Код:
PD 	1067369                               
PE 	187919                                
PN 	10371                                 
PO 	1059477                               
RP 	1248
10.09.2008 15:44
Mtirt
 
Цитата:
isi У меня проблема то в том, что в этот момент он формирует файл для загрузки в таблицу расчета товародвижения производства и ничего не пишет в базу, проблема в самом модуле расчета товародвижения, в базе все гуд в этот момент, это точно
У нас не вылетал... Просто повисал надолго. Очень.
В момент расчета данных, да...
11.09.2008 05:50
isi
 
да в момент расчета, у меня на сутки может задуматься и по тихоньку ест память пока к 2 гигам не подбереться ну а потом out of memory...
11.09.2008 09:30
kadr
 
Мне кажется что это глюк СМ, но всё же постараться произвести расчёт ТД на машине отличной от Сервера БД и с большим объёмом памяти
11.09.2008 09:33
isi
 
Цитата:
kadr Мне кажется что это глюк СМ, но всё же постараться произвести расчёт ТД на машине отличной от Сервера БД и с большим объёмом памяти
Сменил версию СМ, с x86 переехал на x64, переехал на 10 oracle, поставил сервак с 8 гигами с 4 процами, создал на нем тестовую базу и в ней мучаю
11.09.2008 11:06
kadr
 
Цитата:
isi да в момент расчета, у меня на сутки может задуматься и по тихоньку ест память пока к 2 гигам не подбереться ну а потом out of memory...
а ключить /3G в винде используется?
11.09.2008 13:20
isi
 
на сколько я понимаю ключика 3G в x64 Win 2003 нет, а на 32-bit x86 Win2003 стоял
11.09.2008 16:00
isi
 
готов сделать вывод, расчет товародвижения по производству делается в памяти и есть проблемы с ограничением по кол-ву документов. основание для утверждения: перестало считаться с выше указанной ошибкой, думал кривой документ, ан нет, снимаю все документы производства за один год. считается, восстанавливаю, снимаю за другой, считается, восстанавливаю, снимаю за третий, считается, восстанавливаю все, out of memory, при этом не помогает /3G в винде, "кривость" в прошлые годы закрасться не могла, заперещен для редактирования период, завтра буду беспокоить С+, интересно что скажут.... и как выкручиваться будут... деньги то заплачены...
17.09.2008 11:41
isi
 
ответ С+

"наши разработчики нашли причину возникновения ошибочной ситуации. Сейчас ведутся работы по ее исправлению. Сроков пока озвучить не могу. Т.к. решение приведет к изменению алгоритма расчета товародвижения, а такие изменения за 5 минут не сделать."
17.09.2008 12:59
OlegON
 
Короче, пересчитывать нам товародвижение и искать баги после исправления этой ошибки... Спасибо, что предупредил..
02.10.2008 09:04
isi
 
СМ 1.026.2 sp1 появился на сайте FTP, что то тишина от С+ про ошибку, зато реализовали то что просили попутно: "Добавлена возможность производить расчет товародвижения без расчета себестоимости в производстве."
02.10.2008 17:00
Mtirt
 
А менеджера спросить, что там с исправлением ошибки № ...?
Там люди сейчас меняются, могли и потерять. Лучше лишний раз уточнить.
02.10.2008 19:24
victor
 
Там люди не меняются, а исчезают. Инфраструктура СМ-2000 порезана пока слабо, а вот другие направления - WMS, Axapta, автоматизация общепита, Oracle BI - умерщвлены полностью.
03.10.2008 01:52
isi
 
про WMS не говорите.... Вся команда.... ушла.... похоже дохлый проект, у нас поддержки теперь нет
Опции темы


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

 

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