Создание начального образа Распределенной информационной базы (РИБ) в 1С — это стандартная административная процедура. Однако на практике системные администраторы и разработчики часто сталкиваются с крайне неприятной проблемой: относительно небольшая база данных (например, объемом всего 3.5 Гб) при попытке генерации образа начинает потреблять колоссальное количество дискового пространства. Системная база данных СУБД tempdb разрастается до сотен гигабайт (вплоть до 180 Гб и более), полностью забивает свободное место на диске, после чего процесс аварийно завершается.
В этой статье мы подробно разберем, почему физически происходит этот процесс на уровне СУБД MS SQL Server, как оперативно диагностировать проблему и какие альтернативные, более надежные и быстрые методы создания подчиненного узла РИБ существуют в арсенале опытных специалистов.
Для того чтобы понять, как бороться с проблемой, проанализируем физику процессов, происходящих при взаимодействии платформы 1С и СУБД MS SQL Server во время генерации начального образа РИБ.
А. Хранилище версий (Version Store) и механизм RCSI
По умолчанию современные конфигурации 1С работают в режиме изоляции транзакций Read Committed Snapshot Isolation (RCSI). Этот режим призван минимизировать взаимные блокировки пользователей при одновременной работе. Однако у него есть важная особенность: при изменении данных старые версии строк сохраняются в специальном хранилище версий (Version Store), которое физически располагается внутри базы данных tempdb.
Когда мы запускаем процесс создания начального образа РИБ, платформа 1С открывает одну очень длинную транзакцию на чтение. СУБД обязана гарантировать, что на всем протяжении этой транзакции (которая может длиться часами, пока обрабатываются сотни тысяч объектов) 1С будет видеть строго согласованные данные на момент начала транзакции. Если в этот момент в центральной базе продолжают активно работать пользователи или регламентные задания (вносятся новые документы, проводятся записи, изменяются регистры), все старые версии этих строк начинают лавинообразно копироваться в Version Store внутри tempdb. СУБД не имеет права очистить эти версии, пока активна транзакция создания РИБ. В результате tempdb мгновенно раздувается до сотен гигабайт.
Б. Сложные запросы и построение таблиц регистрации изменений
При создании образа система не просто копирует таблицы «как есть». Ей необходимо сопоставить данные с таблицами регистрации изменений (например, _DocumentChngR), а также применить правила фильтрации данных (если используется РИБ с фильтрами, например, по конкретной организации или подразделению). Для этого СУБД строит сложнейшие планы запросов. Если статистика базы данных неактуальна или повреждены индексы, оптимизатор SQL Server может выбрать неоптимальный план соединения таблиц. СУБД начинает выполнять тяжелые операции сортировки (SORT) и хеширования (HASH JOIN) в оперативной памяти. Если памяти не хватает, данные сбрасываются во временные таблицы СУБД (Internal Objects) внутри той же tempdb, что приводит к ее взрывному росту.
В. Ошибки платформы и декартово произведение
На устаревших релизах платформы (например, в линейке 8.3.16) встречались технологические ошибки, при которых SQL-запрос, генерируемый платформой 1С, транслировался некорректно. СУБД вместо последовательной выборки данных уходила в бесконечные циклы или пыталась построить декартово произведение (Cartesian Product) многомиллионных таблиц. Результаты этих промежуточных вычислений моментально заполняли диск временными файлами.
---
Если вы столкнулись с ростом tempdb, не стоит действовать вслепую. Давайте проанализируем структуру занятого пространства в системной базе данных с помощью простого SQL-запроса в СУБД. Запустите в среде SQL Server Management Studio (SSMS) следующий скрипт во время выполнения процесса создания РИБ:
USE tempdb;
SELECT
SUM(user_object_reserved_page_count) * 8 AS UserObjectsKB,
SUM(internal_object_reserved_page_count) * 8 AS InternalObjectsKB,
SUM(version_store_reserved_page_count) * 8 AS VersionStoreKB,
SUM(unallocated_extent_page_count) * 8 AS FreeSpaceKB
FROM sys.dm_db_file_space_usage;
Проанализируем результаты выполнения запроса:
---
Рассмотрим базовые шаги, которые необходимо выполнить непосредственно в самой информационной базе 1С и СУБД для устранения симптомов проблемы.
Шаг 1. Тестирование и исправление информационной базы (ТИИ)
Перед запуском ресурсоемких процедур всегда выполняйте ТИИ. Нам необходимо убедиться в физической и логической целостности базы данных. Особое внимание уделите пунктам «Реиндексация таблиц» и «Реструктуризация таблиц». Это позволит обновить индексы, исправить возможные повреждения метаданных и ускорить выполнение запросов СУБД.
Шаг 2. Обновление технологической платформы 1С
Поскольку поведение часто связано с неоптимальной работой платформы на уровне генерации SQL-запросов (как в случае с релизом 8.3.16.1224), настоятельно рекомендуется обновить платформу 1С до актуальных стабильных релизов. Фирма «1С» регулярно оптимизирует механизмы создания начальных образов РИБ и исправляет ошибки утечек памяти и неконтролируемого роста временных таблиц.
Шаг 3. Перенос и базовая настройка tempdb в MS SQL Server
Если системный диск СУБД переполняется, перенесите файлы tempdb на отдельный быстрый SSD/NVMe диск большего объема и правильно их сконфигурируйте:
tempdb на несколько файлов данных одинакового размера (количество файлов должно быть равно количеству ядер процессора, но не более 8).---
Что делать, если стандартный механизм создания образа РИБ через Конфигуратор или режим «Предприятие» все равно падает? Существуют проверенные обходные методики, которые позволяют полностью обойти ограничения СУБД по росту tempdb.
Этот метод является промышленным стандартом для баз данных любого объема. Он позволяет полностью исключить тяжелые транзакции выгрузки данных и нагрузку на tempdb. Разберем этот метод по шагам:
// Программный перевод восстановленной копии в статус подчиненного узла РИБ
КодГлавногоУзла = "ГЛ"; // Укажите код вашего главного узла из плана обмена
СсылкаНаГлавный = ПланыОбмена.ВашПланОбмена.НайтиПоКоду(КодГлавногоУзла);
Если ЗначениеЗаполнено(СсылкаНаГлавный) Тогда
ПланыОбмена.УстановитьГлавныйУзел(СсылкаНаГлавный);
Сообщить("База успешно переведена в подчиненный режим РИБ!");
Иначе
ВызватьИсключение "Указанный главный узел не найден в планах обмена базы данных!";
КонецЕсли;
tempdb.Поскольку исходная база автора имеет относительно небольшой объем (всего 3.5 Гб), мы можем временно отказаться от использования ресурсов MS SQL Server для этой операции:
.DT) и разверните ее локально на рабочем компьютере администратора.tempdb физически не возникнет. Процесс гарантированно завершится успешно.1Cv8.1CD) загрузите на целевой SQL-сервер в качестве готовой подчиненной базы данных.Часто СУБД уходит в ступор из-за того, что таблицы регистрации изменений (так называемые таблицы с суффиксом _ChngR) содержат миллионы необработанных записей, которые СУБД пытается прочитать и проанализировать при формировании образа. Перед созданием начального образа убедитесь, что регистрация изменений для создаваемого узла полностью очищена. Образ должен создаваться на «чистый» узел, в котором нет зарегистрированных к отправке объектов.
---
Мы подробно проанализировали проблему лавинообразного роста tempdb при генерации образа РИБ. Главная причина кроется в специфике работы механизма версионирования строк СУБД (RCSI) в сочетании с длительными транзакциями чтения 1С и возможной неоптимальностью запросов на старых релизах платформы.
Для гарантированного решения проблемы рекомендуется:
УстановитьГлавныйУзел), который исключает любые риски переполнения системных баз данных SQL Server.