21.07.2008, 13:37 | #1 |
Участник
|
Добрый день!
Не производится закрытие склада за месяц. Используемый метод расчета себестоимости - средняя. Нет отрицательного физического склада, но есть отрицательный финансовый склад для складской модели, используемой по умолчанию. Есть товарные операции закупки, возврата покупки, продажи, возврата продажи, производственные заказы, списание, оприходование. При запуске периодического задания "Закрытие склада" после определенного момента идет зависание системы. Пока не выполнить принудительное закрытие Аксапты, система так и будет висеть. Перед зависанием выдается последний видимый номер товара в информационном окне "Закрытие склада" RP0012, по справочнику Номенклатуры последний номер товара RP0106. Я просмотрела операции по товарам с RP0012 по RP0106, явных проблем не вижу.... При открытии еще одной Аксапты в браузере просматривала ход выполнения закрытия склада по таблицам InventCostListTrans, InventCostList. Почему-то после обработки RP0012 система переходит к обработке товара RP0084 (хотя в списке CostList есть товары RP0013, RP0014... RP0084) и после этого висит насмерть. Открытых производственных заказов, покупок или продаж за закрываемый период нет... Что делать? Где искать причину зависания? Может надо по товарам какие-то специальные действия выполнить (например, принудительную маркировку)? Заранее спасибо за любую помощь. |
|
21.07.2008, 14:13 | #2 |
Участник
|
Цитата:
Сообщение от SBOL
Добрый день!
Не производится закрытие склада за месяц. Используемый метод расчета себестоимости - средняя. Нет отрицательного физического склада, но есть отрицательный финансовый склад для складской модели, используемой по умолчанию. Есть товарные операции закупки, возврата покупки, продажи, возврата продажи, производственные заказы, списание, оприходование. При запуске периодического задания "Закрытие склада" после определенного момента идет зависание системы. Пока не выполнить принудительное закрытие Аксапты, система так и будет висеть. Перед зависанием выдается последний видимый номер товара в информационном окне "Закрытие склада" RP0012, по справочнику Номенклатуры последний номер товара RP0106. Я просмотрела операции по товарам с RP0012 по RP0106, явных проблем не вижу.... При открытии еще одной Аксапты в браузере просматривала ход выполнения закрытия склада по таблицам InventCostListTrans, InventCostList. Почему-то после обработки RP0012 система переходит к обработке товара RP0084 (хотя в списке CostList есть товары RP0013, RP0014... RP0084) и после этого висит насмерть. Открытых производственных заказов, покупок или продаж за закрываемый период нет... Что делать? Где искать причину зависания? Может надо по товарам какие-то специальные действия выполнить (например, принудительную маркировку)? Заранее спасибо за любую помощь. Вы имеете в виду, что во время состояния "висит": 1. не изменяется текст в прогресс-баре 2. не бегает зеленая стрелочка в правом нижнем углу (если у вас ax3.0 двухзвенная) 3. если поверх аксапты открыть другую программу и минимизировать другую программу, то окно Аксапты не перерисовывается 4. вы посмотрели в профейлер SQL-запросов и ни один новый запрос не появляется, но SQL сервер активно работает над чем-то старым 5. вы посмотрели в профейлер SQL-запросов и ни один новый запрос не появляется и SQL сервер простаивает, AOS (для двухвенки клиент) чем-то постоянно занят 5. вы посмотрели в профейлер SQL-запросов и ни один новый запрос не появляется и SQL сервер простаивает и AOS (для двухвенки клиент) простаивает. Дело в том, что закрытие может выполняться очень долго, если у вас давно не было закрытия. Вкратце алгоритм: 1. цикл для каждой номенклатуры, которую нужно закрыть. 2. цикл для каждого расхода, который нужно закрыть 3. цикл по всем приходам, от которых зависит текущий расход, чтобы найти сумму коррекции с\с расхода 4. изменить с/с расхода 5. цикл по всем открытым приходам, которые зависят от текущего расхода, чтобы раскидать коррекцию по ним. Шаги 3,5 могут выполняться очень долго. Вам кажется, что Аксапта висит, но на самом деле она активно работает. Чтобы "исправить" либо добавьте еще парочку прогресс-баров внутрь закрытия. Либо следите за профайлером. А лучше всего закрывайте почаще. Тогда стандартное закрытие должно отрабатывать за час-два при активно работающих пользователях. Еще хинт: вы можете распараллелить закрытие на несколько клиентов. Для этого на втором-третьем-четвертом компьютере откройте окно "Зактиые и коррекция", щелкните пункт меню "Расчет \ Помощь в закрытии" |
|
21.07.2008, 15:29 | #3 |
Участник
|
Сначала про закрытие. Оно выполняется ежемесячно уже 2 года без проблем.
Я пробовала закрыть месяц частями (брала 10 дней вместо 30) - результат тот же - висим. Распараллелить закрытие на разных компьютерах не пробовала.. Попробую. Когда еще компы дадут. Сейчас работаю локально. Теперь про состояние зависания. У меня открыто 2 окна приложения - 1 с информационным окном процедурыЗ акрытие склада, и в информационном окне все белое - не виден код товара, время завершения... Во 2 окне открыты таблицы InventCostListTrans, InventCostList, я смотрю - по какому товару прошла транзакция, какой последний номер счетчика операций. И вот когда "висим ", то не добавляется новых операций в таблице nventCostListTrans. Профайлер сейчас буду смотреть. Время работы закрытия склада - от 1 часа до 14 часов... Хотя обычно склад закрывается за час-полтора. |
|
21.07.2008, 16:34 | #4 |
Участник
|
Цитата:
Цитата:
В общем, проверяйте нагрузку на SQL, клиента и AOS, чтобы убедится что вы висите. Проверьте нет ли на SQL'е deadlock'ов или lock'ов, которые мешают закрытию. Может быть, у вас не "висит", а "ждет" |
|
22.07.2008, 13:02 | #5 |
Участник
|
Добрый день!
Я запустила закрытие периода в Аксапте и профайлер. И вот уже 7 часов они работают... я работаю локально, загрузку AOS и SQL проверить не могу - не знаю как. Бегает зеленая стрелочка в правом нижнем углу (изредка), окно Аксапты с периодическим заданием не прорисовывается при открытии поверх него другой программы, но окно, где я проматриваю операции InventCostListTrans, InventCostList - прорисовывается. В окне профайлера в режиме трассировки хоть и медленно, но периодически появляются новые записи. Уже стоим на строке 2725371... Частенько появляется сообщение IF @@TRANCOUNT > 0 COMMIT TRAN, SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED, set implicit_transactions off . После чего опять идут транзакции... Интересно, и скольно это еще будет продолжаться? Во вложении - скрин шот экрана, где открыта и Аксапта и профайлер. Вопрос: имеет ли смысл провести пересчет по номенкларным группам по отдельности? Перед закрытием. Это может привести к тому, что можно будет выловить сначала группу, а затем и товар, по которому циклится закрытие? |
|
22.07.2008, 13:32 | #6 |
Участник
|
Спасибо.
На скриншоте видно, что у вас идет первая итерация. Это значит, что скорее всего основное время уходит на выполнение метода InventCostItemDim.updateReceiptAdjustmentTrans. Попробуйте туда встравить SysOperationProgress. На его обсчет и отрисовку уйдет дополнительное время, но вам будет более понятно "висит" аксапта или что-то делает. далее, на скриншоте видно, что у вас трехуровневая конфигурация, тонкий клиент. у вас не должна "бегать" зеленая стрелочка. у вас должен работать АОС (он отображается черными дугами). Если у вас таки зеленая стрелочка бегает, значит у вас серьезные проблемы с передачей параметров на АОС. Меряйте трафик между вашим клиентом и АОСом. далее, на скриншоте видно, что максимально запланированная итерация на момент скриншота - 758. в таблице InventCostList смотрите какая итерация выполняется сейчас. Так вы сможете примерно оценить сколько еще осталось. Кстати, эту таблицу можно посмотреть и из интерфейса Главное меню \ Закрытие и коррекция \ Расчет \ Список расчета Цитата:
Во время закрытия делается два типа тормозных "операций": 1. выборка и расчет себестоимости (select) 2. коррекция себестоимости (запись в базу) Если вы проведете пересчет, то выполните выборку + запись большинства коррекций Однако во время закрытия Аксапта все равно будет делать выборку и расчет, чтобы убедится, что себестоимость не изменилась с последнего пересчета. Поэтому делая предварительный пересчет вы дважды затратите время на выборку и расчет себестоимости. А от затрат времени на запись коррекций не избавитесь. Нет, ищите длинные запросы, оптимизируйте индексы, индекс-хинты и т.п. http://axapta.mazzy.ru/lib/querytuning/ Вставляйте прогресс-бары. Хоть на его прорисовку и уйдет дополнительное время, но у вас появится уверенность в том, что не висит. |
|
22.07.2008, 13:35 | #7 |
Участник
|
и еще. на скриншоте видно, что у вас оставлено выравнивание вправо.
почитайте здесь http://axapta.mazzy.ru/lib/adjustment/ и примите решение о необходимости выравнивания влево (тем более, что префиксы у вас уже есть). операция выравнивания влево будет выполняться долго. Но эту операцию нужно выполнить один раз. Потом вам будет значительно легче. |
|
22.07.2008, 14:35 | #8 |
Участник
|
Большое спасибо за помощь. Передам всю переписку разработчику. А то одна все мучаюсь...
Про выравнивание влево. Я правильно понимаю, что требуется произвести переименование товаров с вынесением префикса в начало кода? А затем произвести реиндексацию базы данных и т.д по рекомендациям из статьи на форуме. Или выравнивание влево - это переключение определенных параметров в настройках БД? И еще вопрос: почему раньше у клиента подобной проблемы не возникало? А тут "вдруг" началось... Объем операций обычный, нестандарных проводок не вводили... Что могло послужить основной причиной такого "слома"? Набралась определенная критическая масса ошибок? |
|
22.07.2008, 15:08 | #9 |
Участник
|
Цитата:
Сообщение от SBOL
Про выравнивание влево. Я правильно понимаю, что требуется произвести переименование товаров с вынесением префикса в начало кода? А затем произвести реиндексацию базы данных и т.д по рекомендациям из статьи на форуме. Или выравнивание влево - это переключение определенных параметров в настройках БД?
выполняется изменением одного свойства в АОТ. Но это изменение приводит в Alter Table во многих таблицах. Поэтому изменение выравнивания потенциально очень тяжелая, длительная и блокирующая всех пользователей операция. Но после нее почти всем становится лучше. Цитата:
Если же в обслуживанием SQL все в порядке, то "вдруг" не может быть. Это значит у вас меняли код, который затрагивает работу с SQL. Барабашки нет. |
|
24.07.2008, 11:35 | #10 |
Участник
|
Добрый день!
Инересно получилось - я отдала копию базы данных другому консультанту. Он провел проверку на синхронизацию, потом реиндексацию и в 2 приема склад закрыл!! Я сделала то же самое на своей базе- склад как висел, так и висит. Так мало того - поехали к клиенту, провели синхронизацию и реиндексацию, стали закрывать склад - висим как прежде... Что это может быть, если не барабашка? |
|
24.07.2008, 20:58 | #11 |
Участник
|
|
|
25.07.2008, 08:47 | #12 |
Участник
|
В этой связке не указано, приложение при закрытии склада использовалось одно или разные? Может быть дело в какой-ибудь модификации?
|
|
31.07.2008, 12:50 | #13 |
Участник
|
Добрый день!
Хочу порадовать участников обсуждения - клиент признался, что "Склад мы закрыли. По поводу "Почему вдруг склад не закрывался" мы нашли в списке причин: Это была установка дополнительный компонентов и перенастройка SQL на другой физический сервер". Раньше это никак сказать не могли... Так что Барабашки нет на самом деле... Рекомендации я все передала клиенту. Сказали, что если и будем делать, то потом.... Спасибо за помощь. |
|