Нередко системные администраторы, обслуживающие инфраструктуру 1С, сталкиваются с ситуацией, которая на первый взгляд кажется парадоксальной: база данных в MS SQL Server занимает сотни гигабайт, а ее выгрузка в стандартный файл .dt оказывается в десятки раз меньше. Эта разница вызывает вопросы о корректности работы базы, ее "раздутости" и эффективности использования дискового пространства. Давайте вместе разберемся, почему так происходит, как правильно диагностировать ситуацию и какие шаги предпринять для оптимизации.
Проанализируем реальный случай: база "1С:Бухгалтерия предприятия" на MS SQL весит 170 Гб, а ее .dt-файл — всего 5 Гб. Администратор провел эксперимент: выгрузил базу в .dt и загрузил в чистую базу SQL, но ее размер снова стал огромным. Это говорит о том, что проблема не в "мусоре", который можно было бы легко убрать.
Чтобы понять корень проблемы, нужно осознать, что файл .mdf (файл данных SQL) и файл .dt — это две совершенно разные сущности по своей структуре и назначению.
База данных MS SQL (.mdf): Это "живой", постоянно работающий организм. Она содержит не только сами данные, но и множество служебных структур, предназначенных для обеспечения быстрой работы и надежности:
.mdf, чтобы при добавлении новых записей не тратить время на расширение файла. Это приводит к внутренней фрагментации.Файл выгрузки (.dt): Это не база данных, а архив. Платформа 1С при создании .dt-файла:
.dt-файла они создаются заново. Это одна из главных причин колоссальной разницы в размере.Вывод: Большая разница в размерах — это абсолютно нормальное и ожидаемое явление. Сам по себе этот факт не является признаком проблемы. Проблема возникает тогда, когда абсолютный размер SQL-базы становится слишком большим, замедляет работу и съедает дисковое пространство.
Теперь выясним, почему сама база в SQL такая большая. Если после выгрузки-загрузки через .dt размер не уменьшился, значит, дело в огромном объеме самих данных, а не в накопленном "мусоре" или пустом месте. Необходимо проанализировать, что именно занимает место. Для этой задачи можно использовать инструмент для анализа распределения объёма базы по таблицам и объектам 1С.
Первым делом нужно понять, какие таблицы в базе самые большие. Для этого используем стандартные средства MS SQL Server Management Studio (SSMS).
Щелкните правой кнопкой мыши по вашей базе данных и выберите Reports → Standard Reports → Disk Usage by Top Tables. Этот отчет наглядно покажет список таблиц, отсортированных по размеру, с разделением на объем данных (Data) и объем индексов (Indexes).
В рассматриваемом случае анализ показал, что львиную долю занимают таблицы с именами вида _AccumRg... (регистры накопления) и _AccumRgT... (таблицы итогов регистров накопления). Например, одна из таблиц итогов занимала более 40 Гб.
Названия таблиц в SQL (например, _AccumRgTn19965) ничего не говорят пользователю 1С. Чтобы сопоставить их с реальными объектами конфигурации, нужно использовать специальные инструменты.
СтруктураХранения = ПолучитьСтруктуруХраненияБазыДанных();
// Далее можно обработать эту структуру и вывести в удобном виде
Анализ в нашем примере показал, что самые большие таблицы — это регистры, связанные с учетом для индивидуального предпринимателя (ИП): РегистрНакопления.ИПМПЗ, РегистрНакопления.ИПМПЗОтгруженные и их таблицы итогов. Это означает, что в базе ведется очень активный учет с огромным количеством номенклатуры и документов, что приводит к миллионам записей в регистрах.
Ключевой момент: Проблема оказалась не в техническом состоянии SQL-базы, а в прикладной логике и объеме данных, которые генерирует сама конфигурация 1С в процессе работы.
Решение проблемы должно быть комплексным и затрагивать как уровень администрирования SQL, так и уровень прикладного решения 1С.
Эти действия помогут поддерживать базу в здоровом состоянии, но кардинально не уменьшат ее размер, если он обусловлен объемом данных.
Правильное обслуживание индексов. Ежедневное полное перестроение (REBUILD) всех индексов — плохая практика. Это избыточная и ресурсоемкая операция, которая может приводить к временному раздуванию лога и самой базы. Используйте интеллектуальные скрипты обслуживания (например, от Ола Халленгрена), которые:
Операция сжатия (SHRINK). Сжимать файлы базы (SHRINKFILE) следует крайне осторожно и редко. Эта операция вызывает сильную фрагментацию индексов, что снижает производительность. Ее имеет смысл выполнять один раз после удаления очень большого объема данных (например, после свертки базы), чтобы вернуть неиспользуемое место операционной системе. Не включайте SHRINK в регулярные планы обслуживания!
Сжатие данных SQL (Data Compression). Начиная с версии SQL Server 2008 R2 Enterprise (и со всех версий SQL 2016 SP1 и новее), доступна функция сжатия данных на уровне страниц (PAGE) или строк (ROW). Это может значительно (иногда в 2-3 раза) уменьшить физический размер базы на диске. При этом нагрузка на процессор возрастает, так как данные сжимаются/разжимаются на лету, но нагрузка на дисковую подсистему снижается. Для баз 1С с "рыхлыми" данными это может дать отличный эффект.
Выполнить сжатие можно следующими командами (обязательно сделайте резервную копию перед выполнением!):
-- Сжатие всех таблиц в базе
EXEC sp_MSforeachtable 'ALTER TABLE ? REBUILD WITH (DATA_COMPRESSION = PAGE)'
-- Сжатие всех индексов в базе
EXEC sp_MSforeachtable 'ALTER INDEX ALL ON ? REBUILD WITH (DATA_COMPRESSION = PAGE)'
Именно здесь кроется ключ к кардинальному решению проблемы большой базы.
Свертка информационной базы. Это самый эффективный метод. Свертка — это процесс, при котором документы и движения по регистрам за прошлые периоды (например, до начала текущего года) удаляются, а вместо них создаются документы ввода начальных остатков. Рабочая база становится значительно меньше, а старые данные сохраняются в архивной копии. Эту операцию должен выполнять опытный 1С-специалист.
Оптимизация учета. Необходимо проанализировать с 1С-программистом, почему регистры так сильно растут. Возможно, есть ошибки в партионном учете, некорректно настроена учетная политика или используются операции (например, "Корректировка записей регистров"), которые создают избыточное количество движений.
Управление итогами. Для некоторых регистров можно настроить период хранения итогов. Например, оставить рассчитанными итоги только за последние 2-3 года. Это можно сделать через "Функции для технического специалиста" → "Стандартные" → "Управление итогами". Это не уменьшит таблицы движений, но может сократить размер таблиц итогов.
В конечном итоге, администратору из нашего примера было рекомендовано инициировать свертку базы силами 1С-специалистов, так как техническими средствами SQL уменьшить базу, наполненную реальными данными, уже невозможно без их потери. В качестве альтернативы классической процедуре можно использовать инструмент для сжатия документов в закрытых периодах.