Работа с базами данных объемом в несколько терабайт на платформе 1С:Предприятие 8 требует особого подхода. Стандартные методы, такие как «Тестирование и исправление» (ТиИ) или полная свертка базы, часто оказываются неприменимы из-за огромных временных затрат (база может «молотиться» неделями) или жестких требований бизнеса к доступности исторических данных. Рассмотрим подробно, как проанализировать структуру базы и какими методами можно сократить ее объем, сохранив при этом работоспособность системы и доступ к документам прошлых лет.
Прежде чем что-то удалять, мы должны четко понимать, какие именно данные занимают место. В MS SQL Server нет прямого указания на имена объектов 1С, поэтому нам необходимо сопоставить таблицы SQL с метаданными конфигурации. Проанализируем ситуацию с помощью стандартного отчета SQL Server «Disk Usage by Top Tables». Если этот отчет недоступен, мы можем выполнить запрос к системным таблицам СУБД, чтобы получить список самых «тяжелых» объектов.
Выясним причину роста: часто это не сами документы, а вспомогательные данные. Рассмотрим наиболее частых «виновников» избыточного веса базы:
ХранилищеДополнительнойИнформации.ВерсииОбъектов может занимать до 50-70% всего объема базы. Каждое изменение документа создает его полную копию в формате XML.Проанализируем ситуацию с прикрепленными файлами. В старых редакциях УПП файлы по умолчанию хранятся непосредственно в базе данных (тип ХранилищеЗначения). Если мы обнаружили, что справочник ХранилищеДополнительнойИнформации занимает сотни гигабайт, лучшим решением будет вынос файлов в тома на диске.
Хотя штатно старая УПП может не поддерживать работу с томами, мы можем доработать конфигурацию или воспользоваться технологией SQL FILESTREAM. Это позволит вынести VARBINARY(MAX) данные за пределы основного файла .mdf, сохранив при этом целостность базы данных. Если же мы решили оставить файлы в базе, рассмотрим возможность их программного сжатия.
Посмотрим на пример кода, который позволяет пережать изображения (сканы), уменьшая их размер в несколько раз без потери читаемости за счет перевода в градации серого и изменения разрешения:
dpi = Сред(СвойстваФайла.Получить("Horizontal resolution"),2,3);
Если dpi = "400" Тогда
СтрокаКоманды = """" + ПутьККомпоненте + " convert " + ИмяВременногоФайла + " -density 300 -resize 75%% -colorspace Gray -quality 7 " + ИмяРезультата;
WshShell = Новый COMОбъект("Wscript.Shell");
sReturn = WshShell.run(СтрокаКоманды, 1, True);
// Обновляем данные в ХранилищеДополнительнойИнформации
КонецЕсли;
Разберем, что делать с регистром ВерсииОбъектов. Бухгалтерам редко нужны версии документов 5-летней давности. Мы можем настроить регламентное задание, которое будет удалять версии старше определенного срока (например, года). Важно помнить: удаление миллионов записей через НаборЗаписей.Записать() в 1С создаст огромную нагрузку на транзакционный лог SQL. В таких случаях эффективнее удалять данные порциями в периоды минимальной активности.
Также проанализируем регистр ГрафикиРаботПоВидамВремени. Часто в УПП он раздувается до десятков миллионов записей из-за избыточного заполнения. Проверим, нужны ли эти данные за периоды, которые уже закрыты и по которым сдана отчетность. Если нет — смело удаляем их программно, так как они не влияют на расчет текущей зарплаты.
Выясним причину, по которой разностные бэкапы достигают огромных размеров (вплоть до 0.5 Тб в день). Рассмотрим механизм работы Differential Backup: он включает в себя все страницы данных, которые изменились с момента последнего полного бэкапа. Если у вас настроен ежедневный Index Rebuild (пересоздание индексов), SQL Server помечает все страницы как измененные, и разностный бэкап становится сопоставим с полным.
Рекомендуем следующие настройки обслуживания индексов для баз объемом 4 Тб:
Иногда объем базы неоправданно велик из-за итогов. Проанализируем таблицы с именами, заканчивающимися на _T (Totals). Если в системе много «зависших» остатков, 1С хранит нулевые или бесконечно малые значения в итогах. Пересчет итогов и установка границы актуальности на начало текущего или прошлого года помогут физически удалить старые записи итогов из SQL.
Что касается битых ссылок: ТиИ на базе в 4 Тб — это риск остановить предприятие на неопределенный срок. Вместо полного ТиИ мы можем запустить специализированные обработки по поиску ссылок на несуществующие объекты только в самых крупных таблицах. Это позволит точечно «вылечить» базу без глобальных блокировок.
Подведем итог нашей совместной работы. Чтобы реально уменьшить размер базы без свертки, мы должны:
ВерсииОбъектов, оставив данные только за актуальный период.Выполняя эти действия последовательно, мы сможем сократить размер базы с 4 Тб до приемлемых 1–1.5 Тб, сохранив при этом все необходимые бухгалтерии документы и повысив общую производительность системы.