Что происходит внутри информационной базы 1С 8.3: от файла 1Cv8.1CD до кластера серверов

База 1С работает так: в одном хранилище лежат и данные, и сама конфигурация, а платформа превращает каждый объект метаданных (справочник, документ, регистр) в набор таблиц и сама строит к ним SQL-запросы. В файловом варианте всё это — один файл 1Cv8.1CD на диске. В клиент-серверном — база в Microsoft SQL Server или PostgreSQL, с которой работает кластер серверов 1С.

Пользователь и программист никогда не обращаются к таблицам напрямую. Между ними и данными всегда стоит платформа: она проверяет права, ведёт транзакции, ставит блокировки и пересчитывает итоги регистров. Отсюда главный принцип архитектуры 1С: менять данные можно только через объекты платформы, а не правкой файла или таблиц СУБД.

Файловая и клиент-серверная база: где физически лежат данные

Платформа 1С:Предприятие 8.3 поддерживает два варианта хранения. Прикладная логика в обоих одна и та же, разница — в том, кто хранит данные и кто выполняет серверный код.

Цифры в строке «ориентир» — практические, а не жёсткие ограничения. Файловая база может работать и с десятью пользователями, но при одновременном проведении документов они начинают ждать друг друга: таблица блокируется целиком.

Какие файлы лежат в каталоге файловой базы

📁 Если открыть папку файловой базы, вы увидите:

• 1Cv8.1CD — сама база: данные, конфигурация, пользователи, настройки форм. Формат закрытый, открыть его средствами SQL нельзя.
• папку 1Cv8Log — журнал регистрации. В новом формате это файл 1Cv8.lgd (база SQLite), в старом — 1Cv8.lgf и набор файлов .lgp.
• папку 1Cv8FTxt — индекс полнотекстового поиска, если он включён.

Список баз, который пользователь видит в окне запуска, хранится не в базе, а у пользователя на компьютере — в файле ibases.v8i в каталоге %APPDATA%\1C\1CEStart\. Там же, в %APPDATA%\1C\1cv8\ и %LOCALAPPDATA%\1C\1cv8\, лежит кэш конфигурации. Его сбрасывают параметром запуска /ClearCache, когда после обновления у пользователя «залипла» старая версия форм.

Что хранится на сервере 1С

В клиент-серверном варианте данные лежат в СУБД, а у кластера 1С есть свой реестр. Он находится в каталоге srvinfo, в папке вида reg_1541. Главный файл реестра — 1CV8Clst.lst: в нём описаны кластер, рабочие серверы и зарегистрированные информационные базы. Удалять или править этот файл вручную нельзя — кластер потеряет список баз, а пользователи не смогут подключиться.

Конфигурация и метаданные: как объекты 1С становятся таблицами

Конфигурация — это описание прикладного решения: какие есть справочники, документы, регистры, формы и модули. Она хранится в той же базе, что и данные, в служебных таблицах. Основные из них:

• Config — конфигурация базы данных, по которой сейчас работают пользователи;
• ConfigSave — основная конфигурация, которую правит разработчик в Конфигураторе;
• DBSchema — описание того, как метаданные отображены на таблицы;
• Params и Files — служебные параметры и файлы.

Отсюда известная пара «основная конфигурация» и «конфигурация базы данных». Пока разработчик не выполнил Конфигурация → Обновить конфигурацию базы данных (клавиша F7), пользователи работают по старой версии. После обновления платформа сравнивает метаданные со структурой таблиц и при необходимости выполняет реструктуризацию: создаёт новые таблицы, добавляет поля, переносит данные.

Как называются таблицы в СУБД

Имена таблиц и полей в СУБД обезличены: вместо «Номенклатура» там _Reference с числом. Вот как объекты отображаются на таблицы:

У каждой записи справочника и документа есть ссылка _IDRRef — 16-байтный уникальный идентификатор. Поле _Version нужно для контроля версий объекта, _Marked — пометка удаления, у документов есть _Posted, _Date_Time и _Number.

Чтобы узнать, какая таблица соответствует какому объекту, выполните в консоли запросов или обработке функцию ПолучитьСтруктуруХраненияБазыДанных(). Она вернёт таблицу значений с метаданными, именем таблицы в СУБД и списком полей. Это главный инструмент, когда администратор СУБД присылает «тяжёлый запрос к _AccumRg1234» и нужно понять, какой это регистр.

Табличные части, регистры накопления и итоги

Табличная часть — отдельная таблица

Строки табличной части «Товары» хранятся не внутри документа, а в своей таблице. Каждая строка ссылается на документ-владельца и имеет номер строки. Поэтому документ на 5000 строк записывается заметно дольше, чем на 50: платформа при каждой записи перезаписывает табличную часть целиком.

Регистр накопления: движения плюс итоги

Документ при проведении не меняет остатки напрямую. Он формирует движения — записи в регистр накопления с привязкой к регистратору. Если документ перепровести, платформа удалит его старые движения и запишет новые.

Регистры бывают двух видов:

• 📦 остатков — хранят приход и расход, по ним считают остаток на дату (товары на складах, взаиморасчёты);
• 📈 оборотов — только обороты за период, без остатков (продажи, выручка).

Чтобы не суммировать миллионы движений при каждом отчёте, платформа ведёт таблицу итогов. Для регистра остатков итоги хранятся по месяцам, плюс актуальные итоги на текущий момент. Отчёт «Остатки на 15-е число» берёт итог на начало месяца и досчитывает движения за 14 дней.

Когда итоги «едут» (отчёт показывает одно, а сумма движений другое), их пересчитывают. В интерфейсе «Такси» это Все функции → Стандартные → Управление итогами, вкладка с пересчётом итогов. В Конфигураторе то же делает Администрирование → Тестирование и исправление с флажком пересчёта итогов.

Регистры сведений и бухгалтерии

Регистр сведений хранит значения на дату или без периода: курсы валют, цены, ставки. Регистр бухгалтерии — проводки с корреспонденцией счетов и субконто, у него свои таблицы движений, итогов и значений субконто. Принцип тот же: документ пишет движения, платформа ведёт итоги.

Транзакции и блокировки: почему двое не спишут один товар

Каждая запись — транзакция

Любая запись объекта в 1С выполняется в транзакции. Проведение документа — это одна транзакция: записать документ, удалить старые движения, записать новые, выполнить проверки. Если на любом шаге возникла ошибка, откатывается всё. Половины проведённого документа в базе не бывает.

Программист может открыть свою транзакцию методами НачатьТранзакцию(), ЗафиксироватьТранзакцию() и ОтменитьТранзакцию(), чтобы записать несколько объектов как одно целое.

Автоматический и управляемый режим блокировок

У конфигурации есть свойство «Режим управления блокировкой данных»: автоматический, управляемый или смешанный. Современные типовые конфигурации работают в управляемом режиме.

• 🔒 Автоматический — блокировки ставит сама СУБД. Блокируется больше, чем нужно, пользователи чаще ждут друг друга.
• 🎯 Управляемый — блокировки ставит менеджер блокировок 1С, а разработчик сам указывает, что заблокировать. СУБД работает с минимальным уровнем изоляции.

Пример управляемой блокировки перед контролем остатков:

Блокировка = Новый БлокировкаДанных;
ЭлементБлокировки = Блокировка.Добавить("РегистрНакопления.ТоварыНаСкладах");
ЭлементБлокировки.УстановитьЗначение("Склад", Склад);
ЭлементБлокировки.Режим = РежимБлокировкиДанных.Исключительный;
Блокировка.Заблокировать();

Код выполняется внутри транзакции проведения. Пока она не завершилась, второй документ по тому же складу ждёт — и не спишет товар, которого уже нет.

Объектные блокировки

Кроме транзакционных, есть блокировки объектов:

• оптимистическая — при записи платформа сверяет _Version. Если объект изменил кто-то другой, запись отклоняется с сообщением, что данные были изменены или удалены другим пользователем ;
• пессимистическая — объект блокируется на время редактирования в форме или методом Заблокировать(), второй пользователь не может начать правку.

Если транзакция ждёт слишком долго, пользователь видит ошибку о превышении времени ожидания блокировки. Если две транзакции ждут друг друга — взаимоблокировку. Обе ситуации разбирают по технологическому журналу или журналу регистрации, а не «перезапуском всего».

Как клиент 1С общается с сервером

Цепочка подключения в клиент-серверной базе

1. Клиент обращается к агенту сервера ragent — по умолчанию порт 1540.
2. Агент направляет его к менеджеру кластера rmngr — порт 1541.
3. Менеджер назначает соединение с рабочим процессом rphost. Диапазон портов рабочих процессов задаётся в свойствах рабочего сервера, по умолчанию 1560:1591.
4. Рабочий процесс выполняет серверный код и обращается к СУБД.

Клиент к СУБД не подключается вообще. Поэтому на компьютерах пользователей не нужны драйверы SQL, а в брандмауэре открывают только порты 1С на сервере 1С.

Клиент и сервер в коде

Тонкий клиент и веб-клиент не читают базу сами. Они показывают формы и выполняют клиентский код (&НаКлиенте), а всё, что работает с данными, — серверные процедуры (&НаСервере). Каждый вызов сервера — это обмен по сети, поэтому хорошая конфигурация вызывает сервер редко и передаёт сразу всё нужное.

В файловом варианте схема та же, но «серверная» часть работает внутри процесса клиента. Код переносится между вариантами без переписывания.

Индексы и скорость запросов в базе 1С

Какие индексы строит платформа

Индексы создаёт и пересоздаёт сама платформа при реструктуризации. Она индексирует ссылки, коды, наименования, номера и даты документов, измерения регистров, а также реквизиты, у которых в Конфигураторе установлено свойство «Индексировать» или «Индексировать с доп. упорядочиванием».

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

Что тормозит запросы чаще всего

• 🐢 условие на виртуальную таблицу регистра в ГДЕ, а не в её параметрах — платформа сначала соберёт все остатки, потом отфильтрует;
• 🐢 соединение с вложенными запросами вместо временных таблиц;
• 🐢 обращение «через точку» к реквизитам полей составного типа — запрос соединяется со всеми возможными таблицами;
• 🐢 запросы в цикле вместо одного пакетного запроса.

Обслуживание базы

Для клиент-серверной базы администратор СУБД настраивает регламент: обновление статистики, перестроение индексов, очистку процедурного кэша (для MS SQL). Без обновления статистики планы запросов со временем деградируют, и отчёты, работавшие за секунды, начинают идти минутами.

Для файловой базы есть Конфигуратор → Администрирование → Тестирование и исправление с флажками «Реиндексация таблиц информационной базы» и «Сжатие таблиц информационной базы». Режим требует монопольного доступа и копии базы перед запуском: всех пользователей придётся выгнать на время проверки.

Резервное копирование и восстановление базы

Три способа и чем они отличаются

Выгрузку делают в Конфигураторе: Администрирование → Выгрузить информационную базу. Файл .dt содержит данные, конфигурацию и пользователей и не зависит от варианта хранения. Именно через него переводят базу из файловой в клиент-серверную и обратно.

Для клиент-серверной базы основной инструмент — резервные копии СУБД: полная копия плюс журнал транзакций в MS SQL или pg_dump / физическое копирование в PostgreSQL. Они делаются без выгона пользователей и позволяют восстановиться на конкретный момент времени.

Восстановление

Загрузка .dt выполняется через Администрирование → Загрузить информационную базу.

Копию полезно периодически проверять: развернуть в отдельную тестовую базу и открыть. Копия, которую ни разу не восстанавливали, — это надежда, а не страховка.

Частые вопросы