В процессе администрирования и автоматизации сопровождения систем на базе 1С:Предприятие часто возникает задача программного изменения параметров информационной базы (ИБ) без использования графического интерфейса «Консоли администрирования». Типичный пример — автоматическое отключение ограничения по времени бездействия сеансов в тестовых копиях баз, которые создаются еженощно из рабочих дампов. Если в рабочей базе установлено «Время завершения сеанса при бездействии» в 120 минут, то в тестовой базе для удобства разработчиков этот параметр часто требуется обнулить.
В этой статье мы подробно разберем, где именно в структуре SQL-сервера хранятся эти настройки, в каком формате они представлены и как можно ими манипулировать средствами систем управления базами данных.
Давайте проанализируем структуру базы данных 1С на уровне SQL Server. Все системные настройки, не относящиеся к метаданным конфигурации, но определяющие поведение конкретной информационной базы, хранятся в служебной таблице Params. Рассмотрим запрос, который позволяет извлечь интересующие нас данные:
SELECT
[FileName]
,[Creation]
,[Modified]
,[Attributes]
,[DataSize]
,[BinaryData]
FROM [Имя_Вашей_Базы].[dbo].[Params]
WHERE [FileName] = 'ibparams.inf'
Обратим внимание на поле FileName. Файл ibparams.inf — это ключевой объект, в котором 1С хранит параметры ИБ, такие как:
Однако при просмотре результата запроса мы увидим, что поле BinaryData содержит двоичные данные. Просто так «прочитать» или отредактировать их в SQL Management Studio не получится.
Выясним причину, по которой данные в BinaryData не читаются обычным текстовым редактором. Платформа 1С использует алгоритм сжатия zlib (Deflate) для упаковки текстовых конфигурационных файлов перед их записью в SQL. После распаковки содержимое представляет собой текстовый файл в специфическом формате 1С, который часто называют «псевдо-JSON» или «формат 1С-сериализации» (с использованием фигурных скобок { }).
Рассмотрим структуру этого файла на примере. Внутри распакованного ibparams.inf находится структура, где значения параметров разделены запятыми и сгруппированы в блоки. Например, значение времени бездействия в 120 минут будет храниться в секундах — 7200. Наша задача сводится к тому, чтобы найти это число в распакованном массиве и заменить его на 0.
Если нам нужно разово понять, какие байты меняются при смене настроек, мы можем воспользоваться внешним кодом (например, на Delphi или C#), чтобы выгрузить данные, распаковать их и сравнить два состояния файла. Проанализируем пример кода, который вычитывает байты:
procedure TForm1.GetIBParams();
var
dataBytes: TBytes;
dataText: String;
i: Integer;
begin
ADOQuery.SQL.Text := 'SELECT BinaryData FROM Params WHERE FILENAME=''ibparams.inf''';
ADOQuery.Open;
dataBytes := ADOQuery.FieldByName('BinaryData').AsBytes;
dataText := '';
for i := 0 to length(dataBytes) - 1 do
begin
dataText := dataText + chr(dataBytes[i]);
end;
// Далее данные нужно декомпрессировать (zlib)
Memo1.Lines.Text := DecompressZlib(dataText);
end;
Сравнивая результаты до и после изменения настроек в консоли 1С, мы увидим, в каком именно месте текстового блока меняется значение. Важно убедиться, что первые 4 байта или другие служебные поля не являются контрольной суммой (хэшем). Как показывает практика, для ibparams.inf изменение числовых значений не требует пересчета сложных хэшей, достаточно корректно упаковать данные обратно в zlib.
Поскольку наша цель — автоматизировать процесс средствами SQL при восстановлении базы, наиболее элегантным решением будет создание SQL CLR функции. Это позволит вызывать методы сжатия и распаковки прямо в SQL-запросах.
Разберем логику такого решения по шагам:
System.IO.Compression.Uncompress(varbinary) и Compress(string) в SQL Server.
-- Пример логики обновления (псевдокод)
UPDATE Params
SET BinaryData = dbo.Compress(
REPLACE(
dbo.Uncompress(BinaryData),
',7200,', -- ищем 120 минут
',0,' -- меняем на 0 (отключено)
)
)
WHERE FileName = 'ibparams.inf'
Важное предостережение: Метод REPLACE по строке может быть опасен, если число 7200 встречается в других параметрах (например, в тексте сообщения блокировки). Поэтому рекомендуется более детальный парсинг структуры 1С.
Если разработка CLR кажется избыточной, можно воспользоваться методом «шаблонной таблицы», предложенным участниками сообщества. Суть заключается в следующем:
Params для файла ibparams.inf в отдельную таблицу-шаблон.UPDATE, подставляя готовый бинарный блок из шаблона.
UPDATE TargetDB.dbo.Params
SET BinaryData = (SELECT TOP 1 BinaryData FROM TemplateDB.dbo.Params WHERE FileName = 'ibparams.inf')
WHERE FileName = 'ibparams.inf'
Этот метод самый быстрый и надежный, пока не меняется версия платформы 1С, которая может изменить структуру самого файла ibparams.inf.
Проанализируем ситуацию, которая часто ставит в тупик администраторов: данные в SQL изменены, но 1С продолжает работать по-старому. Это происходит из-за того, что кластер серверов 1С (процессы rphost) кэширует параметры информационной базы в оперативной памяти.
Чтобы изменения вступили в силу, необходимо выполнить одно из действий:
Мы выяснили, что параметры ИБ хранятся в сжатом виде в таблице Params. Для автоматического изменения «Времени завершения сеанса» эффективнее всего использовать метод подмены бинарного блока из заранее подготовленного шаблона. Однако помните, что прямая правка таблиц SQL не является штатным механизмом 1С и должна выполняться с осторожностью. Перед проведением подобных операций всегда делайте резервную копию таблицы или всей базы данных.
Если вам требуется более гибкое управление (например, включение регламентных заданий или изменение текста блокировки «на лету»), рассмотрите возможность использования v8int.exe или написание небольшого скрипта на самой 1С, который запускается в пакетном режиме сразу после восстановления базы из бэкапа.