Как устроены базы данных 1С

База данных 1С — это не просто «файл с документами», а двухслойная система: в ней одновременно хранятся конфигурация (описание логики программы) и собственно учётные данные — справочники, документы, регистры. Понимание этого устройства помогает грамотно делать резервные копии, переносить базы, диагностировать падения производительности и не терять данные при обновлениях.

Платформа 1С:Предприятие абстрагирует разработчика от физического хранилища: в конфигураторе вы работаете с объектами метаданных, а платформа сама превращает их в таблицы файловой базы или SQL-сервера. Именно поэтому одна и та же конфигурация может работать и в файловом варианте на локальном компьютере, и в клиент-серверном на MS SQL Server, PostgreSQL или Oracle.

Практическая ценность знания внутреннего устройства проявляется в трёх ситуациях: выбор режима работы для компании, безопасное администрирование (бэкапы, восстановление, тестирование) и поиск причин медленной работы. Ниже разобраны оба режима, структура хранения и типичные ошибки.

Из чего состоит база 1С: конфигурация и данные

Любая информационная база 1С делится на две логические части. Первая — конфигурация: описание объектов метаданных (справочников, документов, регистров, отчётов), программный код на встроенном языке, формы, макеты, роли и права. Именно конфигурация определяет, что вообще можно делать в программе. Вторая часть — данные: конкретные контрагенты, номенклатура, проведённые документы, остатки и обороты.

У конфигурации есть ещё одно важное разделение: основная конфигурация и конфигурация базы данных. Изменения, которые разработчик вносит в конфигураторе, сначала попадают в основную конфигурацию и не видны пользователям. Только после команды «Обновить конфигурацию базы данных» платформа реструктуризует таблицы и применяет изменения к рабочей базе. На больших базах реструктуризация может занимать часы — её планируют на нерабочее время.

Отдельно существует конфигурация поставщика — эталонная версия от разработчика (например, от фирмы «1С» для типовых решений). Сравнение с ней позволяет понять, какие объекты доработаны, и корректно выполнять обновления типовых конфигураций.

Файловый режим: один файл 1Cv8.1CD

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

Файловый режим подходит для небольших команд: ориентировочно до 5–10 одновременно работающих пользователей и баз умеренного размера. Его плюсы — простота: базу можно скопировать как обычный файл, перенести на флешке, разместить в сетевой папке. Минусы — ограниченная производительность при параллельной работе, риск повреждения файла при сбое сети или питания и сложности с тонкой настройкой прав на уровне СУБД.

Критический момент: копировать файл 1Cv8.1CD, пока с базой работают пользователи, нельзя — полученная копия может оказаться в несогласованном состоянии. Для файловых баз корректный способ резервного копирования — выгрузка в файл .dt через конфигуратор или копирование файла только после завершения всех сеансов.

Клиент-серверный режим: 1С поверх SQL

В клиент-серверном варианте данные хранятся в полноценной СУБД: Microsoft SQL Server, PostgreSQL (в том числе сборки PostgresPro), Oracle или IBM DB2. Платформа 1С разворачивается как сервер приложений: кластер серверов 1С принимает подключения клиентов, выполняет код и транслирует обращения к данным в SQL-запросы.

Объекты метаданных превращаются в таблицы СУБД по понятным правилам: справочник «Номенклатура» станет таблицей вида _Reference..., документ — _Document..., регистр накопления — _AccumRg..., регистр сведений — _InfoRg.... К именам таблиц добавляются числовые суффиксы, соответствие объектов и таблиц можно получить штатной функцией «ПолучитьСтруктуруХраненияБазыДанных».

Этот режим снимает ограничения файлового варианта: СУБД обеспечивает параллельную работу сотен пользователей, транзакционную целостность, журналирование и штатные средства резервного копирования. Цена — необходимость администрировать два продукта: и кластер 1С, и СУБД (пользователи, права, бэкапы, обслуживание индексов).

Файловый или клиент-серверный режим

Файловый (1Cv8.1CD)

До ~10 пользователей, небольшой объём данных, минимум администрирования. Ограничения: блокировки при параллельной работе, уязвимость к сбоям сети.

Клиент-серверный (MS SQL / PostgreSQL)

Десятки и сотни пользователей, большие объёмы, регламентные задания, отказоустойчивость. Требует администратора СУБД и отдельного лицензирования.

1С:Фреш / облачный сервис

База размещена у оператора, администрирование включено. Подходит, если нет своей серверной инфраструктуры, но есть требования к доступности из разных точек.

Как объекты конфигурации отображаются в таблицы

Понимание соответствия «объект → таблица» полезно при анализе прямых SQL-запросов и диагностике блокировок. Основная логика такова: ссылочные объекты (справочники, документы, планы счетов) хранят по одной строке на объект с уникальным идентификатором; регистры хранят записи движений с измерениями и ресурсами; для регистров накопления с остатками платформа дополнительно поддерживает таблицу итогов.

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

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

Регистры, итоги и индексы: где рождается производительность

Большинство жалоб на «медленную 1С» связано не с размером базы как таковым, а с тремя факторами: неоптимальные запросы в коде конфигурации, отсутствие подходящих индексов и состояние итогов регистров. Первые два пункта диагностируются технологическим журналом и средствами СУБД (планами запросов), третий — штатной обработкой управления итогами.

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

В клиент-серверном режиме добавляется уровень СУБД: фрагментация индексов, устаревшая статистика, нехватка памяти под буферный пул. Регламентное обслуживание SQL-сервера (обновление статистики, перестроение индексов) должно выполняться по расписанию — без этого даже мощный сервер со временем начинает работать медленнее.

Контрольные точки

Как проверить здоровье базы

Скорость типовых отчётов (оборотно-сальдовая ведомость, остатки склада)

Норма

Формируются за секунды при типичном объёме данных

Тревожный признак

Выполнение занимает минуты, растёт со временем без роста объёма

Состояние итогов регистров

Норма

Итоги рассчитаны на актуальный период, использование итогов включено

Тревожный признак

Итоги отключены или «заморожены» на старую дату

Журнал регистрации и технологический журнал

Норма

Нет массовых ошибок СУБД, взаимоблокировок, таймаутов

Тревожный признак

Регулярные deadlock, ошибки чтения, превышения таймаута

Резервные копии

Норма

Копия создаётся по расписанию и периодически проверяется восстановлением

Тревожный признак

Копии есть, но их никто никогда не восстанавливал

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

Существует три рабочих способа резервного копирования, и у каждого своя область применения. Выгрузка в .dt через конфигуратор — универсальный переносимый формат: файл можно загрузить и в файловую, и в клиент-серверную базу, он переживает смену версий платформы. Минус — на больших базах выгрузка и загрузка занимают много времени и требуют монопольного доступа.

Для клиент-серверных баз основной инструмент — штатные бэкапы СУБД (FULL + DIFF + журналы транзакций в MS SQL, pg_dump или физические копии в PostgreSQL). Они быстры, не требуют завершения сеансов и позволяют восстановить базу на произвольный момент времени. Для файловых баз — копирование 1Cv8.1CD при закрытых сеансах либо выгрузка dt.

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

1. 1
   Сделайте резервную копию рабочей базы (dt или бэкап СУБД)
2. 2
   Разверните копию на тестовом сервере и обновите конфигурацию там
3. 3
   Проверьте ключевые операции: проведение документов, отчёты, обмены
4. 4
   Запланируйте обновление рабочей базы на нерабочее время, завершите сеансы
5. 5
   Обновите конфигурацию базы данных, дождитесь окончания реструктуризации
6. 6
   Проверьте вход пользователей и выполнение регламентных заданий

Типичные ошибки при работе с базами 1С

Самая разрушительная ошибка — копирование файловой базы «на живую» и последующая работа с такой копией как с эталонной. Вторая по частоте — прямые правки данных в SQL, после которых начинаются «чудеса»: документы не проводятся, остатки не сходятся, обновления падают. Третья — хранение файловой базы в сетевой папке с доступом по Wi-Fi или через нестабильный канал.

На стороне администрирования часто встречаются: отсутствие регламентного обслуживания СУБД, заполнение диска журналом транзакций (модель восстановления FULL без бэкапов журнала) и запуск тестирования и исправления без предварительной копии. Каждая из этих ситуаций превращается в потерю данных или многочасовой простой.

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

Можно ли открыть файл 1Cv8.1CD без 1С?

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

Как узнать, в каком режиме работает база?

В меню «Файл — Сведения для техподдержки» или в строке подключения в списке информационных баз: файловый режим указывает путь к каталогу с 1Cv8.1CD, клиент-серверный — имя сервера 1С и имя базы в кластере. Также это видно в свойствах базы в консоли кластера.

Почему база растёт, хотя документов вводится немного?

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

Чем выгрузка dt отличается от бэкапа SQL?

Файл dt — логическая выгрузка на уровне платформы: переносим между СУБД и версиями, но медленный и требует монопольного доступа. Бэкап SQL — физическая копия на уровне СУБД: быстрый, работает без остановки пользователей, позволяет восстановление на точку во времени, но привязан к конкретной СУБД. В идеале используются оба способа.

Когда точно пора переходить с файлового режима на клиент-серверный?

Признаки: одновременно работают больше 8–10 пользователей, документы проводятся с ожиданием блокировок, база превышает несколько гигабайт, появляются ошибки при параллельной работе, нужны регламентные задания без держащего сеанс компьютера. Переход выполняется выгрузкой dt из файловой базы и загрузкой в клиент-серверную.

Опасно ли запускать «Тестирование и исправление» базы?

Сама процедура штатная, но режимы с исправлением (например, удаление битых ссылок или реструктуризация таблиц) могут необратимо изменить данные. Правило: сначала копия базы, затем запуск в режиме «только проверка», анализ найденных ошибок и только потом исправление — с пониманием того, что именно будет изменено.