← На главную

В процессе эксплуатации крупных информационных баз 1С (от сотен гигабайт) администраторы и разработчики нередко сталкиваются с ситуацией, когда штатные процедуры обслуживания, такие как «Тестирование и исправление» с реструктуризацией, выполняются слишком долго, прерываются пользователем или завершаются аварийно. После такой отмены размер файла базы данных (.mdf) не только не уменьшается, но и резко увеличивается, а свободное дисковое пространство исчерпывается. Разберем по шагам, почему это происходит, как провести детальный анализ структуры базы и какими методами можно безопасно вернуть и сократить занимаемый объем.

Причины резкого роста базы после прерывания реструктуризации

Проанализируем ситуацию, происходящую внутри СУБД во время выполнения реструктуризации. Механизм реструктуризации 1С устроен следующим образом:

1. Платформа создает временную копию целевой таблицы со служебными префиксами или суффиксами (например, _TEMP, _NG).
2. Данные порциями переносятся из исходной таблицы во временную с изменением структуры колонок и пересчетом индексов.
3. Исходная таблица удаляется, а временная переименовывается в рабочую.

Если этот длительный процесс отменяется или прерывается принудительно, СУБД откатывает незавершенную транзакцию. При этом временные таблицы реструктуризации не всегда удаляются платформой корректно и могут остаться в базе данных в виде «мусора». Кроме того, массовая отмена операций приводит к катастрофической фрагментации страниц данных и индексов, из-за чего таблицы занимают в разы больше физических страниц в файле .mdf при том же количестве реальных строк. Также важно учитывать, что на базах объемом свыше 100 Гб штатная выгрузка в файл .dt крайне нестабильна и часто завершается ошибкой нехватки памяти, поэтому администрирование баз такого масштаба необходимо выполнять исключительно средствами СУБД.

Шаг 1. Анализ распределения дискового пространства по таблицам

Прежде чем предпринимать какие-либо действия по очистке или сжатию, необходимо выяснить, какие именно объекты занимают основной объем. Заниматься оптимизацией вслепую неэффективно.

Для детального анализа выполним следующие действия в среде SQL Server Management Studio (SSMS):

1. Подключаемся к экземпляру MS SQL Server.
2. В дереве объектов раскрываем список баз данных, нажимаем правой кнопкой мыши по целевой базе данных 1С.
3. Переходим в меню: Отчеты (Reports) -> Стандартные отчеты (Standard Reports) -> Использование дисковой памяти таблицей (Disk Usage by Top Tables).

В сформированном отчете анализируем первые 10–20 самых объемных таблиц. Обращаем внимание на следующие моменты:

1. Наличие служебных таблиц: таблицы с суффиксами _TEMP, _NG или нестандартными идентификаторами, оставшиеся после незавершенного тестирования и исправления.
2. Таблицы итогов и движений: таблицы регистров накопления и бухгалтерии (префиксы _AccumRg, _AccRg) и таблицы пересчета итогов (_AccumRgOpt).
3. Таблицы хранения двоичных данных: объекты с суффиксами _VT, хранилища значений, прикрепленные файлы, картинки, сканы документов, электронные письма.
4. Служебные регистры: версионирование объектов, протоколы обмена, история задач бизнес-процессов, неиспользуемые узлы планов обмена.

Шаг 2. Очистка временных таблиц и обслуживание на уровне СУБД

Если анализ показал наличие зависших таблиц реструктуризации, их необходимо удалить средствами СУБД, предварительно сделав полную резервную копию базы данных. После удаления ненужных объектов важно соблюдать строгую последовательность сервисных процедур.

Правильный порядок обслуживания после удаления лишних данных:

1. Очистка неиспользуемого пространства: для таблиц с типами переменной длины (например, NVARCHAR, VARBINARY, IMAGE) при удалении больших объемов данных выполняется команда DBCC CLEANTABLE, которая освобождает страницы, занятые удаленными переменными колонками.
2. Перестроение индексов (Index Rebuild): операция ALTER INDEX ALL ON [ИмяТаблицы] REBUILD устраняет внутреннюю фрагментацию, уплотняет страницы данных и высвобождает пустое пространство внутри файлов.
3. Сжатие базы данных (Shrink): только после перестроения индексов имеет смысл выполнять сжатие файла данных .mdf с помощью команды DBCC SHRINKFILE или через меню Tasks -> Shrink -> Files. Выполнение сжатия до дефрагментации приводит к мгновенному повторному росту базы и деградации производительности.
4. Сжатие данных на уровне СУБД (Data Compression): на редакциях SQL Server с поддержкой сжатия (Enterprise или Standard в современных версиях) можно включить сжатие страниц (PAGE compression) или строк (ROW compression) для крупных таблиц регистров и документов. Это позволяет сократить физический размер базы данных на 40–60% без изменения метаданных в 1С.

Шаг 3. Оптимизация хранения данных и свертка без потери документов

Если требования бизнеса запрещают удаление исторических документов прошлых лет (например, за 2012 год), уменьшить объем информационной базы можно за счет избирательной свертки регистров.

Рассмотрим варианты оптимизации на уровне логики 1С:

1. Свертка движений регистров с сохранением документов: документы прошлых периодов оставляются в базе в неизменном виде для просмотра и формирования печатных форм, однако их движения по регистрам накопления, бухгалтерии и сведений удаляются до определенной даты (например, до 01.01.2016). На дату границы создаются сводные документы ввода остатков. В результате таблицы движений и итогов многократно уменьшаются, а документы остаются доступными.
2. Вынос файлов во внешнее хранилище: если база раздута за счет присоединенных файлов (сканы, договоры, картинки), необходимо перенести двоичные данные на сетевой диск или в том хранения файлов, очистив реквизиты типа ХранилищеЗначения внутри базы.
3. Очистка узлов обмена и версий: удаление неиспользуемых узлов в планах обмена (где накапливаются таблицы изменений) и очистка устаревших версий объектов в подсистеме версионирования.
4. Управление итогами регистров: в более современных версиях платформы (начиная с 8.3) в механизме управления итогами можно явно ограничить минимальный и максимальный период хранения рассчитанных итогов, что существенно сокращает служебные таблицы итогов.

Шаг 4. Безопасное проведение тяжелых регламентных операций через РИБ

Когда рабочая база не может быть остановлена на несколько суток для длительного тестирования и исправления, а свободного места на сервере не хватает, используем технологию распределенной информационной базы (РИБ):

1. В рабочей базе создаем новый узел плана обмена РИБ.
2. Создаем резервную копию базы и разворачиваем ее на отдельном тестовом сервере или мощной рабочей станции с быстрыми накопителями.
3. В копии базы регистрируем узел как подчиненный и отвязываем базу от постоянного прямого подключения.
4. На отдельном оборудовании без спешки и ограничений по времени выполняем полное тестирование и исправление, реструктуризацию, очистку устаревших данных и сжатие.
5. После завершения всех процедур настраиваем штатный обмен изменениями между рабочей базой и оптимизированной копией, дожидаемся полной синхронизации всех данных, накопившихся за время работы, после чего переключаем пользователей на обновленную базу.