← На главную

В процессе длительной эксплуатации конфигурации 1С:Управление торговлей ред. 10.3 (особенно доработанной) администраторы и разработчики часто сталкиваются с ситуацией, когда размер базы данных на MS SQL Server начинает расти с огромной скоростью. При этом файл выгрузки .dt может занимать всего 2–3 ГБ, тогда как физический размер базы данных в СУБД превышает 80–100 ГБ. Разберем основные причины такого поведения платформы и СУБД, а также рассмотрим пошаговые методы восстановления оптимального объема базы.

Основные причины аномального роста таблиц и итогов

Проанализируем ситуацию, чтобы понять, из-за чего раздувается база данных и какие таблицы занимают больше всего места:

1. Избыточное индексирование реквизитов регистров. Разработчики при доработке конфигурации часто устанавливают свойство Индексировать у новых или существующих реквизитов в регистрах накопления и сведений (например, в регистре Продажи). В результате размер индексов таблицы может в 3–4 раза превышать объем самих данных. Если таблица данных занимает 1.6 ГБ, то ее индексы при сплошном индексировании реквизитов могут разрастаться до 8 ГБ и более.
2. Незакрытые остатки по измерениям регистров (Пересортица). Для быстрого получения остатков платформа 1С ежемесячно формирует записи в таблицах итогов (например, в таблице _AccumRegTotals). Если по аналитической записи образовался плюс по одному измерению (например, номенклатуре или документу партии) и минус по другому, итоговый остаток в ресурсе равен нулю. Однако платформа считает такие комбинации измерений не закрытыми и вынуждена ежемесячно дублировать их в таблице итогов за каждый последующий период. Со временем это приводит к геометрическому росту таблицы итогов.
3. Незакрытые движения по регистрам НДС. Регистры накопления НДСРасчетыСПокупателями, НДСНачисленный и аналогичные содержат данные, необходимые для проведения регламентных документов по НДС. Если в компании не регулярно или некорректно формируются документы Формирование книги покупок и Формирование книги продаж, то движения по этим регистрам не закрываются в ноль, образуя гигантские таблицы остатков за многие годы.
4. Документы с ошибочной датой. Если пользователь случайно проводит документ с датой из далекого прошлого или будущего (например, 0054 год или 2054 год), платформа начинает рассчитывать и хранить промежуточные итоги с этой даты до текущего момента. Это приводит к мгновенному разрастанию таблиц итогов регистра накопления.
5. Особенности работы MS SQL Server с памятью. СУБД запрашивает дисковое пространство у операционной системы с запасом. При физическом удалении записей или очистке движений освободившееся место остается зарезервированным внутри файла базы данных .mdf (High Water Mark) и не возвращается ОС автоматически без выполнения операции сжатия.

Шаг 1. Проверка и оптимизация индексов конфигурации

Посмотрим на структуру индексов в конфигураторе. Проанализируем реквизиты наиболее «тяжелых» регистров накопления и сведений:

1. Сравним доработанную конфигурацию с типовой конфигурацией поставщика или исходной структурой.
2. Проверим у всех добавленных или измененных реквизитов значение свойства Индексировать. Если у реквизита установлено значение Индексировать или Индексировать с доп. упорядочиванием, а данный реквизит редко используется в качестве фильтра в запросах, снимем этот флаг.
3. Выполним обновление конфигурации БД. Это приведет к удалению лишних индексов в MS SQL Server и сбережет гигабайты дискового пространства.

Шаг 2. Закрытие и выравнивание аналитики регистров

Если проблема заключаются в «повисших» остатках и пересортице по измерениям, необходимо закрыть их в абсолютный ноль:

1. Сформируем отчеты по остаткам регистров накопления (в разрезе всех измерений, включая субконто, партии, характеристики) и проверим наличие нулевых итогов с разной аналитикой.
2. Создадим технический документ Корректировка записей регистров. Спишем минусовые остатки по одной аналитике и начислим по другой, чтобы закрыть ключи аналитики в ноль.
3. Если вести учет НДС в 1С:Управление торговлей 10.3 не требуется (например, вся бухгалтерия ведется в отдельной базе 1С:Бухгалтерия), можно отключить проведение документов по регистрам НДС или очистить исторические данные устаревших регистров НДС. Для физической очистки устаревших данных по согласованию с администратором базы данных на уровне СУБД может применяться команда:
   Скопировать код

   
   TRUNCATE TABLE _AccumReg12345; -- где _AccumReg12345 - имя физической таблицы регистра
   

   Важно: Перед выполнением прямых SQL-команд обязательно создавайте резервную копию базы данных!

Шаг 3. Проведение регламентных процедур в 1С и MS SQL Server

Разберем по шагам последовательность обслуживания базы данных после очистки и выравнивания остатков:

1. Пересчет итогов и тестирование: В режиме 1С:Предприятие или через конфигуратор запустим процедуру Тестирование и исправление (меню Администрирование -> Тестирование и исправление). Обязательно установим флаги Пересчет итогов и Сжатие таблиц.

   Обратите внимание: При процедуре реструктуризации платформа может создавать временные таблицы _v8tmp, поэтому убедитесь, что на диске сервера есть свободное место, превышающее размер базы данных минимум в 1.5–2 раза.

2. Обслуживание индексов и статистики в MS SQL Server: В среде SQL Server Management Studio (SSMS) выполним регламентный скрипт или настроим план обслуживания (Maintenance Plan):
   • Выполним перестроение (REBUILD) или реорганизацию (REORGANIZE) индексов с коэффициентом заполнения страниц FILLFACTOR от 80% до 90%.
   • Обновим статистику базы данных.
   • При необходимости выполним точечное сжатие файла данных: DBCC SHRINKFILE (N'Имя_Файла_Данных', TARGET_SIZE_MB);

Шаг 4. Выгрузка и загрузка через файл .dt (При необходимости)

Для полного пересоздания структуры таблиц и освобождения неиспользуемых страниц СУБД можно использовать стандартный механизм выгрузки и загрузки базы:

1. Выполним выгрузку информационный базы в файл .dt из конфигуратора.
2. Удалим текущую базу с сервера MS SQL (или создадим новую пустую базу данных).
3. Загрузим файл .dt в созданную чистую базу данных 1С. При выгрузке в .dt попадают только первичные данные без вторичных системных таблиц и итогов, которые платформой создаются заново в оптимальном объеме.

Предупреждение: Данный способ подходит для баз некрупного размера. Для баз размером более 20–30 ГБ стандартный механизм выгрузки в .dt официально не рекомендуется 1С для регулярного использования в качестве резервного копирования из-за повышенных рисков сбоя по памяти.

Вывод

Аномальное «разбухание» базы 1С:Управление торговлей 10.3 чаще всего связано со слабым контролем за индексированием добавленных реквизитов и «зависшими» остатками в регистрах накопления НДС и продаж. Проведение аудита конфигуратора на предмет индексов, регулярная корректировка незакрытых итогов и выполнение регламентных работ на MS SQL Server позволяют уменьшить размер базы в несколько раз без потери рабочих данных.