Переход с Бух.Проф на Бух.КОРП (долгие запросы)
Коллеги, привет.
Нужен совет. Есть база БУХ 3.0 ПРОФ, решили перевести на КОРП.
При выполнении операций обновления в режиме предприятия в том числе выполняется операция по отключению учета по подразделениям на счетах (на которых не было учета по подразделениям в ПРОФ). Это типовой кусок процедуры обновления.
Так вот, как выяснилось, при записи счета (после отключения флага учета по подразделениям) каким-то неявным образом запускается процедура обновления всех записей регистра бухгалтерии.
В базе порядка 7 млн. записей в регистре бухгалтерии, в итоге на обновление одного счета уходит по 40-50 минут, а счетов на которых должен отключиться учет очень много.
1. Кто-нибудь знает что именно запускает процедуру обновления регистра бухгалтерии после изменения признака учета по подразделениям ( в коде конфигурации это явным образом нигде не вызывается)
2. У кого есть опыт перевода на КОРП с базами аналогичного или большего объема. Были ли подобные проблемы и если были, то как решали
Нужен совет. Есть база БУХ 3.0 ПРОФ, решили перевести на КОРП.
При выполнении операций обновления в режиме предприятия в том числе выполняется операция по отключению учета по подразделениям на счетах (на которых не было учета по подразделениям в ПРОФ). Это типовой кусок процедуры обновления.
Так вот, как выяснилось, при записи счета (после отключения флага учета по подразделениям) каким-то неявным образом запускается процедура обновления всех записей регистра бухгалтерии.
В базе порядка 7 млн. записей в регистре бухгалтерии, в итоге на обновление одного счета уходит по 40-50 минут, а счетов на которых должен отключиться учет очень много.
1. Кто-нибудь знает что именно запускает процедуру обновления регистра бухгалтерии после изменения признака учета по подразделениям ( в коде конфигурации это явным образом нигде не вызывается)
2. У кого есть опыт перевода на КОРП с базами аналогичного или большего объема. Были ли подобные проблемы и если были, то как решали
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(6) запись счетов идет в цикле
Для Каждого Счет Из СчетаСРазличиямиПризнакаУчетПоПодразделениям Цикл
СчетОбъект = Счет.ПолучитьОбъект();
Если СчетОбъект.УчетПоПодразделениям = ВестиУчетПоПодразделениям Тогда
Продолжить;
КонецЕсли;
СчетОбъект.УчетПоПодразделениям = ВестиУчетПоПодразделениям;
ЗаписатьСчет(СчетОбъект, ШаблоныСообщений, СобытиеЖурналаРегистрации);
КонецЦикла;
Показать
(22) При переходе с ПРОФ на КОРП, не включаете учет по подразделениям на отличающихся между ними счетах (блокируете тот кусок кода что у вас написан в 7 сообщении). После обновления включаете там где нужно. Например были клиенты, которым нужен был КОРП только для подразделений на 50 и 44. Были которым только для продажи лома - им вообще новые счета не включали. В 21 хотел написать не снимать, а устанавливать, поторопился.
(25) смотрите. сейчас именно это и происходит...при выполнении процедуры обновления в режиме предприятия запускается процедура, которая отключает эту галку на всех счетах на которых учета по подразделениям не было в ПРОФ.
и каждая запись счета по которому в базе есть какие-то движения приводит к выполнению процедуры обновления таблицы проводок, которая в нашем случае длится 40-60 минут...и так по каждому счету.
на уровне конфигуратора учет по подразделениям включен на всех(условно) счетах в КОРП.
и каждая запись счета по которому в базе есть какие-то движения приводит к выполнению процедуры обновления таблицы проводок, которая в нашем случае длится 40-60 минут...и так по каждому счету.
на уровне конфигуратора учет по подразделениям включен на всех(условно) счетах в КОРП.
(26) Вот сами и отключите процедуру, которая отключает эти галки. Пусть будет учет по подразделениям на всех счетах. Потом потихоньку отключите лишнее - каждую ночь по 4-5 счетов. Был случай 14 дней тестовый первый запуск шел. Переделали что до обновления выполнили, что-то на после отложили.
кому интересно - дальнейшее движение:
при анализе плана запроса выяснилось, что ожидаемое количество строк в десятки раз превышает реальное(т.е. ожидаемое количество в плане запроса - сотни миллионов строк), оказывается есть такая проблема при миграции с 2012 на 2014 SQL (как раз наш случай). пробуем в эту сторону двигаться.
при анализе плана запроса выяснилось, что ожидаемое количество строк в десятки раз превышает реальное(т.е. ожидаемое количество в плане запроса - сотни миллионов строк), оказывается есть такая проблема при миграции с 2012 на 2014 SQL (как раз наш случай). пробуем в эту сторону двигаться.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот