TRUNCATE TABLE _AccumRgT7178

1. TokarevV 31 24.03.23 08:48 Сейчас в теме
Добрый день!
У клиента имеется сильно изменённая база УТ 10.3.8.9. Платформа 8.3.16.1063. MS SQL. База на диске занимает 383 Гб! База перестаёт вмещаться на диск компьютера.
Посмотрел в отчете SQL Server Managment Studio, что таблица "_AccumRgT7178" занимает 57 Гб! Это таблица итогов регистра накопления "ЗаказыПокупателей". Запрос к остаткам этой таблицы показал что имеется около 1 миллиона записей об остатках. Обработкой по созданию документов "Корректировка записей регистров" создал документы корректировки и записи в данном регистре, которые закрывают остатки. В обработке, после создания записей прописал :
РегистрыНакопления.ЗаказыПокупателей.ПересчитатьИтоги();
РегистрыНакопления.ЗаказыПокупателей.ПересчитатьТекущиеИтоги();
Затем провел тестирование и исправление базы в конфигураторе, отметка стояла одна "Пересчет итогов".
Сделал Shrink database, shrink files. Таблица итогов регистра накопления "ЗаказыПокупателей" сократилась на 1 Гб. Что неприемлемо.

Вопрос: какие наступят негативные последствия, если сделать "TRUNCATE TABLE _AccumRgT7178",
а затем в конфигураторе сделать "Пересчет итогов"?
Не хочется пока ничего другого трогать, там всё на ладан дышит.
Что вообще можете сказать по этому поводу, можно так делать, нельзя почему?
Вознаграждение за ответ
Показать полностью
Найденные решения
11. user-z99999 70 24.03.23 09:55 Сейчас в теме +0.1 $m
(10)
Вопрос: какие наступят негативные последствия, если сделать "TRUNCATE TABLE _AccumRgT7178"
Это таблица итогов регистра накопления "ЗаказыПокупателей".

Так сделай на тестовой базе TRUNCATE TABLE и пересчитай итоги, и посмотри запросом 1с какие значения на разные даты получаются,
и сравни с рабочей (запрос выполни там).
Если одинаковые, значит всё ок.
Остальные ответы
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
7. user-z99999 70 24.03.23 09:45 Сейчас в теме
(1) Все эксперименты нужно делать на ТЕСТОВОЙ БАЗЕ !
10. TokarevV 31 24.03.23 09:51 Сейчас в теме
(7) Мудрое утверждение.
Тестовая база не позволяет мне увидеть долгосрочные последствия для работы всех пользователей.
11. user-z99999 70 24.03.23 09:55 Сейчас в теме +0.1 $m
(10)
Вопрос: какие наступят негативные последствия, если сделать "TRUNCATE TABLE _AccumRgT7178"
Это таблица итогов регистра накопления "ЗаказыПокупателей".

Так сделай на тестовой базе TRUNCATE TABLE и пересчитай итоги, и посмотри запросом 1с какие значения на разные даты получаются,
и сравни с рабочей (запрос выполни там).
Если одинаковые, значит всё ок.
12. TokarevV 31 24.03.23 09:58 Сейчас в теме
(11) А не плохо придумал, спасибо.
2. TokarevV 31 24.03.23 09:17 Сейчас в теме
Вот тут есть информация, но вопрос актуален.
https://infostart.ru/1c/articles/177171/
3. nomad_irk 76 24.03.23 09:34 Сейчас в теме
(2)исходя из публикации, Truncate Table делать все же не стоит.
4. TokarevV 31 24.03.23 09:36 Сейчас в теме
(3) Почему? Я может не внимательно читал, наоборот там написано, что это один из вариантов.
6. nomad_irk 76 24.03.23 09:43 Сейчас в теме
(4)потому что ниже есть лучший ответ, в котором все подробно расписано и сказано, как следует поступать.
9. TokarevV 31 24.03.23 09:50 Сейчас в теме
(6) Может не будешь таинственность нагнетать и озвучишь его?
Это регламентное задание "ПересчетИтоговРегистровНакопления" запустить?
13. nomad_irk 76 24.03.23 09:58 Сейчас в теме
(9)чувак, ты сам-то читал по ссылке? и комментарии в том числе?
Для не читателей:


......
Удалять записи с нулевым итогом нужно по тем ключам (комплектам измерений), по которым длительное время не было операций UPDATE. А этого функционала в платформе нет - есть только глобальный пересчет. В крупных конторах это решается SQL Job'ом выполняющем примерно следующую работу:

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

обычно данный Job запускается раз в 10 секунд, выбирается TOP 1 чтобы уменьшить время блокировки на затратную операцию удаления. Естественно в такие базы уже встроены и планы обслуживания по пересчету статистики и перестроению дефрагментированных индексов. В случаях когда таких "ненужных" записей очень много - то обычно уменьшают период запуска Job, либо отказываются от Регистра Итогов - потому что если у вас много ключей уходит в "ноль" и больше не используется, скорее всего у вас по данным ключам 2 операции движения "пришел" и "ушел" - зачем хранить такую информацию в регистре итогов совершенно не ясно.
......
14. TokarevV 31 24.03.23 10:05 Сейчас в теме
(13) Я прочила этот комментарий
Это для меня дофига делов.
Хто энто такие "Job'ом"? Мне не сделать такое в SQL в обозримом будущем. Гуглить и наобум втыкать запросы в SQL, слабо представляя эффект, не наш путь. Нет уверенности вообще, что дело в нулевых записях, чувак.
15. nomad_irk 76 24.03.23 10:16 Сейчас в теме
(14) может в таком случае пока не лезть вообще, прокачать свой уровень владения SQL и уже потом?
если уж руки чешутся, то на копии выполнить Truncate и сравнить результат с продом.
5. user1393353 11 24.03.23 09:42 Сейчас в теме +0.02 $m
8. TokarevV 31 24.03.23 09:48 Сейчас в теме
(5) Не пробовал, стоит попробовать. Спасибо за вариант
16. barat 27.03.23 13:08 Сейчас в теме
Ничего не будет, в экстренных случаях пользуюсь вот этим способом Зачем в 1С нужно периодически пересчитывать итоги по регистрам?
Оставьте свое сообщение

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