Коллеги, добрый вечер!
Недавно произошла неприятная ситуация - в разгар рабочего дня в рабочую базу УПП загружался небольшой объем данных (несколько элементов справочника). Стандартная обработка выгрузка/загрузка XML 8.2 отключила итоги, забыли установить флажок "отключить использование итогов" (хотя при неустановленном флажке отключаться итоги не должны).
Проблема в том, что включение итогов по всем регистрам накопления заняло около 2 часов. На тестовой базе, в которой нет активных пользователей, а также отключены регламенты, операции включения/отключения итогов длится секунды.
Кто-то сталкивался с подобной ситуацией? С чем может быть связано столь долгое включение итогов? С обработкой выгрузки/загрузки XML все понятно, нужно быть внимательнее.
База клиент-серверная, MS SQL, размер 400+ ГБ, с огромными доработками.
Заранее спасибо за ответы.

(0) в скуле прибей таблички итогов и сделай пересчет.. будет быстро

(1) После пересчета итогов, который выполнялся в 2019 году, размер базы вырос в 3 раза - со 100 с небольшим ГБ до 300+ ГБ.

(2) И ? Лог поди вырос , да ? :)

>База клиент-серверная, MS SQL, размер 400+ ГБ, с огромными доработками.
>После пересчета итогов, который выполнялся в 2019 году, размер базы вырос в 3 раза - со 100 с небольшим ГБ до 300+ ГБ.

Так уменьшилось же на 100Гб

* Ну и через ИР, или любую другую поделку посмотри размер табличек в скуле, тогда поймешь, откуда ноги растут, если это таблички итогов регистра - то тупо регистры не закрываются

(4) 300 - это 2019 год. с течением времени база выросла до 400+

(5) Да, таблицы итогов много весят. Да, не закрываются регистры, и это мягко сказано.
Однако, при использовании обработки выгрузки/загрузки XML флажок "отключить использование итогов" ранее не устанавливался, а это означает, что итоги всегда отключались и включались обратно, но происходило это за секунды. Вот этот вопрос меня мучает(((

(7) если он не устанавливался, то никакие итоги никуда не отключались

(8) У обработки обратная логика, к сожалениюю. Это уже исправили, чтобы подобных инцидентов больше не повторялось.
Но после этого случая стали долго выполняться запросы к таблицам остатков и оборотов... Сильно замедлилась работа.
Сама процедура включения/отключения итогов могла повлиять на что-то?

(9) посмотри границы расчета итогов.
И да, обработка не отключает итоги, если спецом флаги не ставить, ты чего-то путаешь

"На тестовой базе, в которой нет активных пользователей, а также отключены регламенты, операции включения/отключения итогов длится секунды."
Может быть дело в том, что на тестовой базе не производится во время отключенных итогов никаких движений в основных таблицах? Поэтому движок видит, что нет смысла итоги пересчитывать и просто включает признак наличия итогов. А когда были движения - то итоги приходится пересчитать полностью, по крайней мере для тех регистров, которые двигались.

Пробуй "Управление итогами регистров (ИР)"
http://devtool1c.ucoz.ru/index/upravlenie_itogami_registrov/0-51
Там увидишь больше информации об итогах

(9) >Сама процедура включения/отключения итогов могла повлиять на что-то?
Переиндексируйте

(13) Запустить реиндексацию через конфигуратор?

(10) Граница как была 31.07.2019, так осталась.
Обработка "выгрузка загрузка xml 8.2" лежала в общей папке отдела, дата создания 2011 год.
К сожалению, как выяснилось, логика обратная, нужно устанавливать галку отключения итогов, чтобы отключения не произошло.

(14) нет, на стороне SQL

(1) Можно ли просто пересчитать итоги по одному проблемному РН? Доступа в скуль нет.
Боюсь даже это запускать, черт его знает, сколько продлится эта операция, вдруг ночи не хватит, да и часовые пояса играют роль.
Запросы к проблемному регистру (остатки, обороты, остаткиИобороты) отрабатываются неприлично долго после того прецедента.

(15)>>>31.07.2019

Это п...ц

(17) ясне пень, считать остаток от 19 года..как думаешь, быстро ?

(18) Пересчитывать итоги перестали после увеличения размера базы в 2019 году. В заключении Гилева рекомендуется выполнять каждый месяц пересчет итогов. Регистр отвратительный, не закрывающийся. В планах закрыть этот регистр принудительно и сделать пересчет итогов.
Но сейчас возникла такая ситуация, что после отключения/включения итогов запросы стали отрабатывать в 20-30 раз дольше.
Обработкой XML пользовались и раньше, но видимо это "русская рулетка", до этого "проносило" и вся операция занимала секунды.
Что произошло сейчас, не совсем понятно((

(20) Берешь ИР, смотришь размерчики, им же грохаешь таблички итогов нужного регистра, им же пересчитываешь итог

И помимо прочего, смотришь, чего еще распухло в базе.
ХЗ, мот там версионирование старое, которое через РС слеплено распухло до небес