Аксапта рушится!

[laptev]

Axapta 3.0 без SP.

Доброго времени суток!
Нужна помощь.

Ошибка:
"Сессия работы на сервере Navision Axapta не может быть продолжена из-за возникновения критической ошибки. Непоправимая ошибка возникла в процессе обработки сервером приложения последнего запроса. Попытайтесь подключиться к системе снова и повторить операцию. Если ошибка повторяется, обратитесь к вашему администратору."

Появилась 01, 15 ноября, затем в декабре появляется каждый день. В списке ошибок Windows на сервере не отображается.

Предположительно, начинает появляться после:
1.Выборка по неиндексированному полю.
2.Сложный отчёт - оборотная ведомость и т.д.

Возникает при попытке формировния любого отчёта, у которого RunOn == Server, сразу после нажатия "ОК". После демонстрации текста ошибки Аксапта У пользователя вылетает.

Вообще, все отчёты заметно медленнее формируются (заметно стало 2 последних месяца).
В таблице InventTrans 2 млн. записей.


Вопросы.
1.Как устранить ошибку?
2.Таблица InventSumLogTTS - для чего она и можно ли её очистить (20 млн. записей)?

[mike1_imported]

Попробуй полностью персторить индексы всей базы.

Eсли MS SQL 2000 то в QA команда.
Use DbName
SET NOCOUNT ON
DECLARE @TableName char(32)
DECLARE SysCur CURSOR FOR SELECT name FROM sysobjects WHERE type='U'
OPEN SysCur
FETCH NEXT FROM SysCur INTO @TableName
WHILE @@FETCH_STATUS=0 BEGIN
DBCC DBREINDEX(@TableName)
FETCH NEXT FROM SysCur INTO @TableName
END
CLOSE SysCur
DEALLOCATE SysCur

[laptev]

Изменения за сутки:
1.Изменили настройки АОСа (закладка Database)
Timeout connection after being idle for = '600'
Literals from join queries from forms and reports = 'No'
Literals from complex joins from X++ = 'No'

Ошибка пока не проявляется.
Производительность немного увеличилась.

2.Про таблицу InventSumLogTTS почитал Axforum => Очистили её с помощью truncate на SQL сервере => На производиетльность никак не повлияло.

Вопрос:
Можно ли ускорить формирование таких отчётов, как "Оборотная ведомость по складу", "Физ.наличие по складам" или лучше написать свои отчёты?

[mazzy]

Цитата:

Сообщение от laptev

Вопрос:
Можно ли ускорить формирование таких отчётов, как "Оборотная ведомость по складу", "Физ.наличие по складам" или лучше написать свои отчёты?

Оборотную ведомость по складу лучше не использовать.

Насчет писать свои - не уверен, может быть.
См. http://axapta.mazzy.ru/lib/inventsumdate/

[laptev]

mazzy, Спасибо!

"Оборотную ведомость по складу" начали переделывать по Вашей рекомендации http://axapta.mazzy.ru/lib/inventsumdate/.

Ошибка, заявленная в заголовке темы, больше не появляется. Хотя это очень странно.

[laptev]

По поводу ускорения отчётов.
Модифицировал стандартный фyнкционал в части расчёта физ. наличия на дату.
На таблице InventTrans создал метод аналогично методу class InventSumDatePhysicalDim:nHandQty(), но с одним Select'ом.
Работает быстро. Например, создание журнала инвентаризации ускорилось ~ в 100 раз. Расхождения в данных пока не замечено.

[mazzy]

Цитата:

Сообщение от laptev

По поводу ускорения отчётов.
Работает быстро. Например, создание журнала инвентаризации ускорилось ~ в 100 раз. Расхождения в данных пока не замечено.

Охо-хонюшки...
Проверяли монопольно?
Сколько пользователей работало одновременно с вашей проверкой?
Что сказали пользователи пока работал ваш отчет?
На каком объеме данных вы делали проверку?


Типичная ошибка многих - повышать производительность отдельно взятого запроса на небольшом объеме данных.
Задача программиста - повысить ОБЩУЮ производительность работы. Чтобы все пользователи системы работали относительно быстро. Чтобы не было такого, что один работает, а остальные курят бамбук. Особенно на многогигабайтных данных.

[laptev]

To mazzy
Модифицировалось автоматическое создание журнала инвентаризации, как самая тяжёлая задача.

Цитата:

Сообщение от mazzy

Проверяли монопольно?

Проверяли в рабочей базе ~ 50 пользователей.

Цитата:

Сообщение от mazzy

Сколько пользователей работало одновременно с вашей проверкой?

Одновременно (теоретически) могут запустить инвентаризацию не более 3-х пользователей.

Цитата:

Сообщение от mazzy

Что сказали пользователи пока работал ваш отчет?

Пользователи не ругались. Наоборот.

Цитата:

Сообщение от mazzy

На каком объеме данных вы делали проверку?

InventTrans ~ 3 млн. записей.

Цитата:

Сообщение от mazzy

Типичная ошибка многих - повышать производительность отдельно взятого запроса на небольшом объеме данных.

Согласен.

Цитата:

Сообщение от mazzy

Задача программиста - повысить ОБЩУЮ производительность работы. Чтобы все пользователи системы работали относительно быстро. Чтобы не было такого, что один работает, а остальные курят бамбук. Особенно на многогигабайтных данных.

Стандартный алгоритм создания журнала инвентаризации работал 2..22 часа.
Остальные пользователи в это время с трудом проводили любые складские операции.

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

[mazzy]

Цитата:

Сообщение от laptev

To mazzy
Модифицировалось автоматическое создание журнала инвентаризации, как самая тяжёлая задача.

Создание журнала инвентаризации - самая простая задача
http://axapta.mazzy.ru/lib/journaltrans_insert/

Цитата:

Сообщение от laptev

Цитата:

Сообщение от mazzy

Сколько пользователей работало одновременно с вашей проверкой?

Одновременно (теоретически) могут запустить инвентаризацию не более 3-х пользователей.

Это почему же?

А сколько человек одновременно с вами создавало складские проводки?

Цитата:

Сообщение от laptev

Цитата:

Сообщение от mazzy

Что сказали пользователи пока работал ваш отчет?

Пользователи не ругались. Наоборот.

Ну, хоть так.

Цитата:

Сообщение от laptev

Цитата:

Сообщение от mazzy

Задача программиста - повысить ОБЩУЮ производительность работы. Чтобы все пользователи системы работали относительно быстро. Чтобы не было такого, что один работает, а остальные курят бамбук. Особенно на многогигабайтных данных.

Стандартный алгоритм создания журнала инвентаризации работал 2..22 часа.
Остальные пользователи в это время с трудом проводили любые складские операции.

"Работал" или давал оценку?
Оценку алгоритм дает исходя из максимального количества строк, которое вы задали в диалоге.
А не на основании фактического количества.

Странно. А длинные запросы у себя отслеживали?
http://axapta.mazzy.ru/lib/querytuning/

Цитата:

Сообщение от laptev

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

У других завершается.

Это не повод делать заплатку, которая через некоторое время превратиться в узкое место.
Это повод проанализировать проблемы быстродействия вашей системы в целом.

[laptev]

Цитата:

Сообщение от mazzy

"Работал" или давал оценку?
Оценку алгоритм дает исходя из максимального количества строк, которое вы задали в диалоге.
А не на основании фактического количества.

Странно. А длинные запросы у себя отслеживали?

Да, время выполнения запросов (а также всех строк кода) отслеживали с помощью Profiler'a.
Запросы выполняются достаточно быстро (в среднем ~ 20 мс).
НО!
В стандартном механизме создания строк журнала инвентаризации для расчёта количества inventJournalTrans.inventOnHand используется класс InventSumDate (а это уже не один запрос, а 10-20).
Плюс на подготовку и запись строки 150мс.
Итого в среднем на строку 500мс.
Если 30 000 строк: 30 000 * 0,5 (с) / 3600 (с/час) = 2,8 часа. Это долго.
Что тут можно оптимизировать? Наверное, только модифицировать алгоритм... В том числе и алгоритм записи строк.

[mazzy]

Цитата:

Сообщение от laptev

НО!
В стандартном механизме создания строк журнала инвентаризации для расчёта количества inventJournalTrans.inventOnHand используется класс InventSumDate (а это уже не один запрос, а 10-20).

Что-то вы путаете...
Пока читайте здесь http://axapta.mazzy.ru/lib/inventsumdate/

Пошел считать количество запросов.

[mazzy]

Цитата:

Сообщение от laptev

В стандартном механизме создания строк журнала инвентаризации для расчёта количества inventJournalTrans.inventOnHand используется класс InventSumDate (а это уже не один запрос, а 10-20).

Во-первых, инициализация происходит в методе класса
InventCountCreate_Base.createInventJournalTrans

Во-вторых, вызывается InventSumDatePhysicalDim:nHandQty(...)

В-третьих, вызывается не 10-20 запросов, а 5
1. inventsum
2. для разнесенных финансово (для вычитания из inventSum)
3. для разнесенных физически (для вычитания из inventSum)
4. для скомплектованных (для вычитания из inventSum)
5. для зарегистрированных (для вычитания из inventSum)

Если вы сумели получить эти данные ОДНИМ(!) запросом, снимаю шляпу.
Но, скорее всего, вы написали ваш единственный исходя из сильно упрощенных предположений.

Кстати, если у вас не используется комплектация/регистрация/физические разноски, то запросы по ним должны выполняться очень быстро, поскольку должны возвращать пустой recordset. Если же вы используете, то 2,3,4,5 запросы при правильной работе должны возвращать очень небольшую выборку...

Скорее всего, тормоза в стандартном запросе связаны не с количеством запросов,
а с наличием index hint'ов. Но index hint и вообще index'ы надо настраивать для всей системы.

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

[laptev]

Цитата:

Сообщение от mazzy

Скорее всего, тормоза в стандартном запросе связаны не с количеством запросов,
а с наличием index hint'ов. Но index hint и вообще index'ы надо настраивать для всей системы.

Очень может быть. До index hint'ов руки ещё не дошли. Будем работать!
Спасибо за подробные ответы.