В процессе длительной эксплуатации базы данных 1С (5 лет и более) неизбежно возникает проблема накопления «мертвого груза». Это данные, которые практически не используются в оперативной работе и не нужны для актуальной статистики, но при этом занимают значительный объем дискового пространства и замедляют работу системы. Особенно это актуально для регистров сведений, хранящих историю статусов заказов или логи изменений, где количество записей может исчисляться миллионами, а объем таблиц превышать десятки гигабайт. Разберем подробно, как правильно подойти к очистке таких данных, не нарушив целостность базы и обеспечив максимальный прирост производительности.
Прежде чем приступать к удалению, нам необходимо точно определить, какие именно таблицы занимают больше всего места. Для этого проанализируем ситуацию с помощью стандартных средств SQL или консоли сервера 1С. Рассмотрим отчет «Распределение объема данных по таблицам». Часто выясняется, что основной объем занимают не справочники или документы, а вспомогательные таблицы: регистры сведений с историей версионирования, таблицы итогов или технические логи.
В ситуации, когда таблица одного регистра занимает более 10 Гб, важно понимать, что простое удаление объектов через интерфейс не поможет. Требуется системный подход, включающий программную очистку и последующее обслуживание СУБД.
Удаление миллионов записей обычным способом может привести к переполнению лога транзакций и длительным блокировкам базы. Проанализируем наиболее эффективный метод — использование объекта РегистрСведенийНаборЗаписей с установленным фильтром. Этот способ работает значительно быстрее, так как 1С оптимизирует запрос к СУБД.
Рассмотрим пример кода для удаления данных из периодического регистра сведений за определенный период:
// Определяем период, данные за который нам больше не нужны
ДатаОчистки = ДобавитьМесяц(ТекущаяДата(), -12); // Оставляем данные только за последний год
// Создаем набор записей регистра
НаборЗаписей = РегистрыСведений.СтатусыЗаказов.СоздатьНаборЗаписей();
// Устанавливаем фильтр по периоду (если регистр периодический)
// Или перебираем записи порциями, если фильтр по периоду не поддерживается напрямую
НаборЗаписей.Отбор.Период.Установить(ДатаОчистки, Ложь);
// Записываем пустой набор, что фактически удаляет данные, попадающие в отбор
НаборЗаписей.Записать(Истина);
Важно помнить: если объем данных колоссальный, операцию следует выполнять порциями в транзакциях, чтобы избежать критической нагрузки на сервер. Выясним причину, почему это важно: при записи огромного набора одним махом MS SQL Server может заблокировать всю таблицу, что парализует работу пользователей.
Часто «раздувание» базы происходит из-за включенного версионирования объектов. Все изменения документов записываются в регистры СведенияОПрочитанныхОбъектах или ВерсииОбъектов. Разберем по шагам, как навести порядок в этих данных:
ВерсииОбъектов.После того как мы удалили миллионы записей, физический размер файла базы данных (.MDF) не уменьшится сам собой. SQL Server просто пометит это место как «свободное» внутри файла. Чтобы реально освободить место на диске и ускорить работу, выполним следующие действия:
1. Управление моделью восстановления. Перед массовым удалением данных переведем базу в режим SIMPLE (простая модель восстановления). Это предотвратит бесконтрольный рост файла лога транзакций (.LDF). После завершения всех процедур вернем модель FULL, если это необходимо для вашей стратегии бэкапов.
2. Процедура сжатия (Shrink). Чтобы вернуть место операционной системе, выполним команду SHRINKDATABASE или SHRINKFILE. Проанализируем нюанс: делать это нужно только после завершения всех работ по удалению. Однако помните, что частое сжатие вызывает сильную фрагментацию индексов.
3. Перестроение индексов. Массовое удаление данных — это серьезная нагрузка на индексы. После очистки 10 Гб данных индексы будут фрагментированы почти на 100%. Выполним команду:
ALTER INDEX ALL ON ИмяТаблицы REBUILD;
Это восстановит производительность запросов к регистру, который мы только что очистили.
Если бизнес-логика требует иногда обращаться к старым данным (например, для сравнения динамики за 5 лет), но хранить их в рабочей базе на дорогом SSD накладно, рассмотрим механизм «Внешние источники данных».
Алгоритм действий следующий:
Таким образом, в отчетах мы сможем программно объединять данные из рабочей базы и архивной таблицы, при этом основная база останется легкой и быстрой.
Если база «пухнет» не только из-за логов, но и из-за остатков на регистрах накопления, поможет классическая свертка. Процесс подразумевает удаление документов прошлых периодов и замену их на документы Ввод остатков. Посмотрим на этот процесс критически: это трудоемкая задача, требующая тщательной проверки бухгалтерского и управленческого учета. Однако для регистров сведений (как в случае автора темы со статусами заказов) «свертка» обычно заключается именно в удалении старых записей до определенной даты, так как «остатков» по статусам в прошлом обычно не требуется.
Чтобы ситуация с 10-гигабайтными таблицами не повторилась, внедрим следующие практики:
Используя комплексный подход — от программного удаления наборами записей до глубокой оптимизации индексов на уровне SQL-сервера, — можно добиться существенного сокращения объема базы и значительно ускорить создание резервных копий.