Добрый день!
У клиента имеется сильно изменённая база УТ 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
7124.03.23 09:55 Сейчас в теме+0.1 $m
(10)
Вопрос: какие наступят негативные последствия, если сделать "TRUNCATE TABLE _AccumRgT7178"
Это таблица итогов регистра накопления "ЗаказыПокупателей".
Так сделай на тестовой базе TRUNCATE TABLE и пересчитай итоги, и посмотри запросом 1с какие значения на разные даты получаются,
и сравни с рабочей (запрос выполни там).
Если одинаковые, значит всё ок.
11.
user-z99999
7124.03.23 09:55 Сейчас в теме+0.1 $m
(10)
Вопрос: какие наступят негативные последствия, если сделать "TRUNCATE TABLE _AccumRgT7178"
Это таблица итогов регистра накопления "ЗаказыПокупателей".
Так сделай на тестовой базе TRUNCATE TABLE и пересчитай итоги, и посмотри запросом 1с какие значения на разные даты получаются,
и сравни с рабочей (запрос выполни там).
Если одинаковые, значит всё ок.
(9)чувак, ты сам-то читал по ссылке? и комментарии в том числе?
Для не читателей:
......
Удалять записи с нулевым итогом нужно по тем ключам (комплектам измерений), по которым длительное время не было операций UPDATE. А этого функционала в платформе нет - есть только глобальный пересчет. В крупных конторах это решается SQL Job'ом выполняющем примерно следующую работу:
1. найти 1 комплект ключей (измерений) по которому не было движений за последний месяц и которые на данный момент нулевые
2. по данному комплекту измерений удалить запись из таблицы итогов
обычно данный Job запускается раз в 10 секунд, выбирается TOP 1 чтобы уменьшить время блокировки на затратную операцию удаления. Естественно в такие базы уже встроены и планы обслуживания по пересчету статистики и перестроению дефрагментированных индексов. В случаях когда таких "ненужных" записей очень много - то обычно уменьшают период запуска Job, либо отказываются от Регистра Итогов - потому что если у вас много ключей уходит в "ноль" и больше не используется, скорее всего у вас по данным ключам 2 операции движения "пришел" и "ушел" - зачем хранить такую информацию в регистре итогов совершенно не ясно.
......
(13) Я прочила этот комментарий
Это для меня дофига делов.
Хто энто такие "Job'ом"? Мне не сделать такое в SQL в обозримом будущем. Гуглить и наобум втыкать запросы в SQL, слабо представляя эффект, не наш путь. Нет уверенности вообще, что дело в нулевых записях, чувак.
(14) может в таком случае пока не лезть вообще, прокачать свой уровень владения SQL и уже потом?
если уж руки чешутся, то на копии выполнить Truncate и сравнить результат с продом.