Переход с Бух.Проф на Бух.КОРП (долгие запросы)

1. alexx2510 39 05.04.22 11:26 Сейчас в теме
Коллеги, привет.
Нужен совет. Есть база БУХ 3.0 ПРОФ, решили перевести на КОРП.

При выполнении операций обновления в режиме предприятия в том числе выполняется операция по отключению учета по подразделениям на счетах (на которых не было учета по подразделениям в ПРОФ). Это типовой кусок процедуры обновления.

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

В базе порядка 7 млн. записей в регистре бухгалтерии, в итоге на обновление одного счета уходит по 40-50 минут, а счетов на которых должен отключиться учет очень много.

1. Кто-нибудь знает что именно запускает процедуру обновления регистра бухгалтерии после изменения признака учета по подразделениям ( в коде конфигурации это явным образом нигде не вызывается)
2. У кого есть опыт перевода на КОРП с базами аналогичного или большего объема. Были ли подобные проблемы и если были, то как решали
Ответы
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
2. Verdad 84 05.04.22 11:31 Сейчас в теме
(1)Добрый день! Я бы на вашем месте рассмотрела вариант свертки перед переходом, потому что на счета добавится ещё один реквизит - подразделение, так проще будет корректировать остатки в случае необходимости.
4. ZergKRSK 130 05.04.22 11:56 Сейчас в теме
(1) изменение в плане счетов такое как признак по подразделению, изменение субконто и пр. приводит к реструктуризации таблиц, это зашито на уровне платформы.
5. alexx2510 39 05.04.22 12:00 Сейчас в теме
(4)ну тут проблема получается в том, что эта процедура запускается по каждому счету в цикле
6. ZergKRSK 130 05.04.22 12:16 Сейчас в теме
(5) нет там цикла, сколько счетов изменено столько раз и реструктуризация
7. alexx2510 39 05.04.22 12:25 Сейчас в теме
(6) запись счетов идет в цикле
	Для Каждого Счет Из СчетаСРазличиямиПризнакаУчетПоПодразделениям Цикл
		
		СчетОбъект = Счет.ПолучитьОбъект();
			
		Если СчетОбъект.УчетПоПодразделениям = ВестиУчетПоПодразделениям Тогда
			Продолжить;
		КонецЕсли;
			
		СчетОбъект.УчетПоПодразделениям = ВестиУчетПоПодразделениям;
		ЗаписатьСчет(СчетОбъект, ШаблоныСообщений, СобытиеЖурналаРегистрации);
		
	КонецЦикла;

Показать
8. ZergKRSK 130 05.04.22 12:32 Сейчас в теме
(7) а как по другому записать изменения в куче счетов?
9. alexx2510 39 05.04.22 12:34 Сейчас в теме
(8) ну так после каждой записи счета, запускается обновление регистра. я про это выше написал.
в итоге обновление базы растягивается на несколько суток
10. ZergKRSK 130 05.04.22 12:35 Сейчас в теме
(9) ну а я выше написал что это зашито в платформе и повлиять на это нельзя.
11. alexx2510 39 05.04.22 12:36 Сейчас в теме
(10) про цикл было уточнение на вашу фразу "нет там цикла"
но речь сейчас не об этом...а о том, как за разумный срок завершить переход на версию корп
12. ZergKRSK 130 05.04.22 12:38 Сейчас в теме
(11) про цикл я имел ввиду что при каждом изменении счета запускается процесс. А уж как изменяется сам счет не важно, в цикле или без.
Попробуйте более мощное железо =)
13. alexx2510 39 05.04.22 12:40 Сейчас в теме
(12) ну сейчас пока идея попробовать tempdb на ram диск перенести: потому что упирается именно в работу с tempdb этот огромный update

может кто-то уже что-то подобное проходил и есть какие-то готовые рецепты работающие
14. ZergKRSK 130 05.04.22 12:48 Сейчас в теме
(13) сама база то "тяжелая"?
15. alexx2510 39 05.04.22 12:52 Сейчас в теме
16. tolyan_ekb 80 05.04.22 14:36 Сейчас в теме
(1) новый механизм https:// /news/2022-03-24-how-to-speed-up-restructuring/ не подойдет?
17. alexx2510 39 05.04.22 17:17 Сейчас в теме
(16) тут вроде речь про реструктуризацию при обновлении БД, непонятно повлияет ли это на запись счета в режиме предприятия...как вариант на попробовать
29. alexx2510 39 11.04.22 15:52 Сейчас в теме
(16) проверили. эта штука реально ускоряет обновление БД в конфигураторе (этого тяжелого UPDATE который в цикле запускается при записи счета вообще нет в этом режиме), но к сожалению при записи счета в режиме предприятия этот новый режим не работает.
18. RustamZz 05.04.22 18:09 Сейчас в теме
(1) Не включайте учет по подразделениям на тех счетах где он вам не нужен.
19. alexx2510 39 06.04.22 09:52 Сейчас в теме
(18) не вариант. это ж придется план счетов с замка снимать что потом сильно осложнит обновления
21. RustamZz 06.04.22 14:44 Сейчас в теме
(19) Этот признак нужно в режиме предприятия снимать, а не в конфигураторе.
22. alexx2510 39 06.04.22 15:39 Сейчас в теме
(21) вы не поверите, но именно это и происходит при обновлении (снятие признака в режиме предприятия) =)
23. RustamZz 06.04.22 18:24 Сейчас в теме
(22) При переходе с ПРОФ на КОРП, не включаете учет по подразделениям на отличающихся между ними счетах (блокируете тот кусок кода что у вас написан в 7 сообщении). После обновления включаете там где нужно. Например были клиенты, которым нужен был КОРП только для подразделений на 50 и 44. Были которым только для продажи лома - им вообще новые счета не включали. В 21 хотел написать не снимать, а устанавливать, поторопился.
24. alexx2510 39 07.04.22 09:58 Сейчас в теме
(23) ну я про это выше написал, это придется в конфигураторе с замка снимать план счетов (потому что в плане счетов в корпе учет по подразделениям включен почти везде). снятие плана счетов с замка приведет к усложнению регулярных обновлений новых релизов.
25. RustamZz 07.04.22 12:02 Сейчас в теме
(24) ????
Прикрепленные файлы:
26. alexx2510 39 07.04.22 13:01 Сейчас в теме
(25) смотрите. сейчас именно это и происходит...при выполнении процедуры обновления в режиме предприятия запускается процедура, которая отключает эту галку на всех счетах на которых учета по подразделениям не было в ПРОФ.
и каждая запись счета по которому в базе есть какие-то движения приводит к выполнению процедуры обновления таблицы проводок, которая в нашем случае длится 40-60 минут...и так по каждому счету.

на уровне конфигуратора учет по подразделениям включен на всех(условно) счетах в КОРП.
27. RustamZz 07.04.22 13:11 Сейчас в теме
(26) Вот сами и отключите процедуру, которая отключает эти галки. Пусть будет учет по подразделениям на всех счетах. Потом потихоньку отключите лишнее - каждую ночь по 4-5 счетов. Был случай 14 дней тестовый первый запуск шел. Переделали что до обновления выполнили, что-то на после отложили.
28. alexx2510 39 07.04.22 13:33 Сейчас в теме
(27)да, запасной вариант с отложенным переходом есть (не отключать при запуске учет по подразделениям)
пока еще не теряем надежды разобраться и обновиться за один раз.
3. alexx2510 39 05.04.22 11:35 Сейчас в теме
свертку пару лет назад делали, сейчас это не выход...

ну и мне кажется, это не какой-то слишком большой объем данных, чтобы говорить о технической невозоможности перехода
20. alexx2510 39 06.04.22 09:55 Сейчас в теме
кому интересно - дальнейшее движение:
при анализе плана запроса выяснилось, что ожидаемое количество строк в десятки раз превышает реальное(т.е. ожидаемое количество в плане запроса - сотни миллионов строк), оказывается есть такая проблема при миграции с 2012 на 2014 SQL (как раз наш случай). пробуем в эту сторону двигаться.
Оставьте свое сообщение

Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот