← На главную

При организации многопользовательской работы с файловой базой данных 1С (файл с расширением .1CD) нередко возникает соблазн разместить файл в общей папке на файловом сервере или сетевом хранилище (NAS), подключив пользователей через тонкий или толстый клиент по локальной сети или через VPN. Проанализируем, как в такой схеме контролируется транзакционная целостность, почему тонкий клиент не защищает базу от физического разрушения и как правильно организовать архитектуру доступа.

Архитектура файловой базы и иллюзия работы тонкого клиента

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

1. Отсутствие серверного процесса на файловом хранилище: На сетевом ресурсе (NAS, SMB-шара Windows или Linux Samba) хранится только пассивный файл .1CD. Никаких вычислительных процессов платформы 1С там не запущено.
2. Локальная микросреда: При запуске тонкого клиента на компьютере пользователя поднимается локальная серверная среда. Это означает, что весь исполняемый код и логика СУБД файлового формата отрабатывают непосредственно на рабочей станции пользователя.
3. Сетевой ввод-вывод: Каждый клиентский сеанс считывает и записывает страницы данных напрямую через сетевой протокол (SMB/CIFS). Если в базе работает 5 пользователей, каждый из них независимо друг от друга обращается к отдельным участкам общего файла по сети.

Таким образом, с точки зрения взаимодействия с файловой системой нет никакой разницы между толстым и тонким клиентом: оба варианта выполняют прямое чтение и запись блоков файла .1CD через разделяемую сетевую папку.

Механизм блокировок и системные причины повреждения данных

В файловой базе 1С уровень изоляции транзакций строится на механизме сериализации посредством файловых блокировок диапазонов байтов (byte-range locks), которые транслируются операционной системе и сетевому протоколу. Выясним причины, приводящие к сбоям и повреждению структуры страниц базы:

1. Нестабильность сетевого транспорта: Если в момент фиксации транзакции (сброса измененных страниц на диск) происходит обрыв VPN-соединения, потеря Wi-Fi сигнала или сбой сетевой карты, пакеты данных не доходят до накопителя. Поскольку полноценного механизма транзакционного журнала (WAL), как в полноценных СУБД, в файловом формате нет, в файле образуются поврежденные страницы (рассинхронизация таблиц и индексов).
2. Кэширование SMB (OpLocks и SMB Leases): Протоколы SMB2 и SMB3 по умолчанию агрессивно кэшируют дескрипторы и фрагменты файлов на стороне клиента. При одновременной записи несколькими пользователями несвоевременный сброс кэша приводит к получению устаревших данных и порче заголовков .1CD.
3. Кэширование метаданных в Windows: Параметры кэша DirectoryCacheLifetime, FileInfoCacheLifetime и FileNotFoundCacheLifetime в ветке реестра LanmanWorkstation\Parameters при ненулевых значениях могут возвращать клиенту неактуальный размер файла, вызывая ошибку «Ошибка формата потока».
4. Аппаратные разгрузки сетевых карт: Функции Large Send Offload (LSO) и энергосберегающие режимы сетевых адаптеров могут приводить к переупорядочиванию служебных управляющих пакетов блокировки, что нарушает целостность параллельных транзакций.
5. Влияние антивирусов: Сканирование файлов блокировок .1CL или тела базы «на лету» блокирует дескрипторы и вызывает ошибку разделения доступа (Sharing Violation).

Варианты безопасной организации работы

Рассмотрим, как исключить риски повреждения данных при различных сценариях развертывания системы.

Вариант 1: Публикация файловой базы на веб-сервере (IIS / Apache)

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

1. Веб-сервер выступает единственной точкой входа и монопольно работает с файлом базы локально, без использования протокола SMB.
2. Клиенты подключаются по протоколам HTTP/HTTPS через интернет, VPN или локальную сеть.
3. В случае обрыва связи между клиентом и веб-сервером сетевая ошибка не передается на дисковую подсистему: веб-сервер корректно завершит или прервет операцию без повреждения структуры файла.
4. Учтем ограничение: доступ через веб-сервер к файловой базе обрабатывает запросы последовательно (в один поток на инстанс), что при большом количестве пользователей снижает скорость работы.

Вариант 2: Использование клиент-серверного варианта (СУБД)

Для гарантированной защиты данных и высокой производительности применяется связка «Кластер серверов 1С:Предприятия + СУБД (PostgreSQL, MS SQL Server и др.)». В этом случае используются полноценные механизмы контроля транзакций, версионирование строк, автоматический откат незавершенных операций и защита от аппаратных сбоев.

Вариант 3: Терминальный сервер (RDP)

Если нет возможности опубликовать базу на веб-сервере, сеансы пользователей запускаются на сервере терминалов, где база лежит на локальном диске. В этом случае обрыв связи RDP-клиента не влияет на запущенный процесс 1С.

Регламент обслуживания и восстановление файловой базы

Если эксплуатация файловой базы продолжается, разберем обязательные правила для поддержания ее работоспособности:

1. Корректное резервное копирование: Запрещено копировать файл .1CD во время активной работы пользователей с помощью проводника или сторонних утилит (бэкап получится поврежденным). Резервную копию следует формировать либо выгрузкой информационной базы в файл .dt в пакетном режиме, либо при полном отключении всех сеансов.
2. Проверка утилитой chdbfl.exe: При возникновении сбоев используем штатную утилиту физической проверки целостности, расположенную в каталоге bin установленной платформы. Она проверяет целостность страниц, заголовков и таблиц файла на физическом уровне.
3. Контроль размера таблиц: Стандартный формат с размером страницы 4 КБ ограничивает размер отдельной таблицы (данных или индексов) объемом 4 ГБ. Начиная с версии 8.3.8, при создании или конвертации базы можно увеличивать размер страницы до 8, 16, 32 или 64 КБ, что позволяет преодолеть этот лимит.

Подключение торгового оборудования через браузер

При работе через веб-клиент (в браузере) подключение оборудования (например, сканеров штрихкодов) требует соблюдения технических условий:

1. Необходимо установить внешнюю компоненту «Расширение для работы с 1С:Предприятием».
2. Драйвер оборудования должен поддерживать технологию Native API.
3. Для сканеров штрихкодов критически важно использовать режим виртуального COM-порта (COM/RS-232), так как режим эмуляции клавиатуры в браузере теряет фокус ввода и работает нестабильно.