Пересчет данных по периодам

[tolstjak]

Здравствуйте уважаемые.
Ax30 SP1 (клиент и сервер SP3)

С недавних пор перестала работать процедура - Пересчет данных по периодам.
При этом после часа работы система закрывается и пишет, что сервер закрыл соединение с вашим компьютером. При этом процедура не отрабатывается.

Может быть кто-нибудь сталкивался с данной проблемой?
Что посоветуете?

Заранее благодарен.

[Roman777]

Записей в LedgerTrans много?
Работают ли при этом пользователи с системой (пока идет пересчет)?
Мониторили ли память ОЗУ на AOS?

[tolstjak]

Цитата:

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

Записей в LedgerTrans много?
Работают ли при этом пользователи с системой (пока идет пересчет)?
Мониторили ли память ОЗУ на AOS?

Всего -около 7 млн.
из них по переносу начальных сальдо - больше 3 млн.
Люди при пересчете не работают. В двухзвенке вылетает из-за плохой памяти.
По трехзвенке работает.
Память жрет, но ее на серевере много.
До предела не доходила.
И что делать?

[tourist]

Как вариант, с помощью незначительных доработок добавить в пересчет условия по дате и/или бух. счету

[tolstjak]

Цитата:

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

Как вариант, с помощью незначительных доработок добавить в пересчет условия по дате и/или бух. счету

Хотелось бы понять почему это происходит и как с этим бороться.
Думаю, что "условия по дате и/или бух. счету" не тот вариант, который бы хотелось получить.

[tourist]

Дело возможно в большом объеме LedgerBalancesDimTrans. При персчете содержимое этой таблицы формируется целиком в памяти в одной транзакции

[tolstjak]

Цитата:

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

Дело возможно в большом объеме LedgerBalancesDimTrans. При персчете содержимое этой таблицы формируется целиком в памяти в одной транзакции

Я тоже склоняюсь к этой мысли. Теперь вопрос как это победить???
Подскажите пожалуйста.
Не думаю, что только у нас так много записей.

[tourist]

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

[tolstjak]

Цитата:

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

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

Понятно. Спасибо.

[Didukh84]

Посмотрите лог АОСа, если трехзвенка (иначе просто, лог клиента ). Возможно там есть запись о MaxOpenCursors или что-то типа этого. Если есть то, как минимум два варианта: модификация кода или увеличение данного значение в утилите приложения (по умолчанию там 90)

[Ned]

Цитата:

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

Уменьшить объём данных для пересчёта с помощью, например, задания диапазона дат - самый простой вариант. Просто делаете свой наследник класса LedgerRecalcPeriod и в нём правите одну строчку в методе run(). Так же отличная идея с открытыми периодами.

Мне ещё кажется неоптимальным механизм пересчёта, т.е. само вычисление значений внутри транзакции. Я бы предложил его переписать целиком - сначала подсчитывать суммарные значения, потом их класть в RecordInsertList и только потом уже открывать транзакцию, внутри которой чистить таблицы сумм и вставлять в них значения из RecordInsertList'ов.

[mazzy]

Цитата:

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

Мне ещё кажется неоптимальным механизм пересчёта, т.е. само вычисление значений внутри транзакции. Я бы предложил его переписать целиком - сначала подсчитывать суммарные значения, потом их класть в RecordInsertList и только потом уже открывать транзакцию, внутри которой чистить таблицы сумм и вставлять в них значения из RecordInsertList'ов.

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

[Ned]

Логично, согласен. Просто скорость работы стандартного механизма убивает.

[mazzy]

Цитата:

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

Логично, согласен. Просто скорость работы стандартного механизма убивает.

это не ежедневно использующийся механизм.
это механизм "лечения" остатков.