Рассматриваемая в данной статье ситуация знакома многим системным администраторам и специалистам 1С. Сценарий классический: в организации развернута файловая информационная база (например, 1С:Бухгалтерия 3.0), с которой по локальной сети работают от 5 до 10 пользователей. База расположена на общем сетевом ресурсе (так называемой «шаре») под управлением современной операционной системы (например, Windows Server 2019), а пользователи заходят на своих рабочих станциях под управлением Windows 7 или Windows 10.
В один «прекрасный» момент один или несколько пользователей сталкиваются со сбоем: программа аварийно завершает работу, выдавая сообщение «Файл базы данных поврежден». При этом у остальных коллег база продолжает работать в штатном режиме. Попытки запустить встроенную утилиту проверки физической целостности chdbfl.exe или выполнить «Тестирование и исправление» из конфигуратора не приносят результатов — утилиты рапортуют, что ошибок в базе нет. После перезапуска компьютера пользователя или очистки временных файлов работоспособность восстанавливается, но через некоторое время проблема повторяется снова и снова, причем у разных сотрудников случайным образом.
В этой статье мы подробно разберем природу этого явления, выясним причины его возникновения и рассмотрим по шагам все эффективные способы устранения данной неполадки.
Прежде чем перейти к практическим действиям, проанализируем ситуацию и поймем физику процесса. Файловая база данных 1С (файл 1Cv8.1CD) представляет собой единое хранилище, к которому платформа обращается напрямую. Когда пользователи работают через общий сетевой ресурс, СУБД как таковая отсутствует — всю работу по координации одновременного доступа, транзакций и блокировок берет на себя сетевой протокол операционной системы (обычно это SMBv2 или SMBv3).
Современные операционные системы Windows по умолчанию используют агрессивные алгоритмы сетевого кэширования данных. Это делается для снижения нагрузки на сеть и ускорения открытия файлов. Однако для транзакционной модели файловой 1С такое поведение ОС губительно. Если один пользователь изменяет данные в базе, а операционная система на компьютере другого пользователя отдает ему информацию из локального сетевого кэша вместо того, чтобы запросить ее заново с сервера, платформа 1С обнаруживает рассинхронизацию индексов и таблиц. Для платформы это выглядит как физическое разрушение структуры файла, о чем она незамедлительно сообщает пользователю ошибкой «Файл базы данных поврежден».
Таким образом, в 99% случаев мы имеем дело с фантомным (ложным) повреждением, вызванным сетевыми задержками, агрессивным кэшированием Windows или некорректной работой сетевого оборудования.
---
Это самый надежный, современный и рекомендуемый способ работы с файловыми базами данных 1С. Вместо того чтобы предоставлять пользователям прямой доступ к файлу 1Cv8.1CD через нестабильную сетевую «шару», мы настраиваем веб-сервер, который будет единственным локальным владельцем файла базы. Клиенты же будут подключаться к веб-серверу по протоколу HTTP/HTTPS через тонкий клиент 1С или обычный браузер.
Разберем по шагам процесс публикации базы на примере веб-сервера Microsoft IIS (Internet Information Services), входящего в состав Windows Server:
CGI и ISAPI Extensions / ISAPI Filters.buh_db), выберем тип веб-сервера (IIS), укажем каталог для хранения файлов публикации (например, C:\inetpub\wwwroot\buh_db).IIS_IUSRS или NetworkService (в зависимости от настроек пула приложений IIS).После этого пользователи в окне запуска 1С меняют тип подключения с «На данном компьютере или на компьютере в локальной сети» на «На веб-сервере» и указывают ссылку вида http://имя_сервера/buh_db. Проблема с повреждением файлов исчезнет навсегда, так как сетевой протокол SMB больше не участвует в работе СУБД.
---
Если по каким-то причинам публикация на веб-сервере не подходит (например, требуется использовать специфическое торговое оборудование или сложные внешние компоненты), вторым по надежности вариантом является переход на терминальный доступ.
При работе через RDP (Remote Desktop Protocol) все сеансы пользователей запускаются локально на самом сервере, где физически расположена база данных. Сетевой трафик между клиентом и сервером содержит только картинку экрана, движения мыши и нажатия клавиш. Сам файл базы данных 1Cv8.1CD обрабатывается исключительно в рамках локальной дисковой подсистемы сервера, что исключает влияние сетевых протоколов Windows и микроразрывов связи.
Для реализации этого метода системному администратору потребуется настроить роль Remote Desktop Services (RDS) на Windows Server 2019, лицензировать терминальные подключения и настроить запуск 1С в режиме удаленного приложения (RemoteApp), чтобы для конечного пользователя программа выглядела так, будто она запущена локально.
---
Если перевести пользователей на IIS или RDP в кратчайшие сроки невозможно, и вам временно необходимо продолжать работу через «шару», то следует принудительно отключить механизмы кэширования сетевых папок на всех клиентских компьютерах под управлением Windows.
Рассмотрим подробнее процедуру внесения изменений в системный реестр на рабочих станциях пользователей (в частности, на Windows 7 и Windows 10):
Win + R, введите команду regedit и нажмите Enter для запуска редактора реестра.HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters
DWORD (32 бита). Если их нет, создайте их вручную со значением 0 (ноль):
0 заставляет систему каждый раз запрашивать актуальный список файлов с сервера.0 отключает локальное хранение этих свойств.0 предотвращает ситуации, когда клиент «не видит» только что созданный временный файл базы данных.---
Оппортунистические блокировки — это механизм, позволяющий клиенту захватывать монопольный доступ к файлу на сервере и кэшировать операции чтения и записи локально. В многопользовательской среде файловой 1С это приводит к конфликтам и взаимным блокировкам, вызывая ложные сообщения о порче базы.
Для отключения этого механизма выполним настройки как на сервере, так и на клиентских машинах:
На стороне сервера (Windows Server):
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
DWORD (32 бита) с именем OplocksDisabled и присвойте ему значение 1.На стороне клиентов (Windows 7/10):
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters
DWORD (32 бита) с именем UseOpportunisticLocking и установите его значение в 0.---
Плавающий характер ошибки часто связан с микросекундными потерями пакетов или засыпанием сетевых адаптеров. Выполним оптимизацию настроек сетевых карт на сервере и клиентских ПК:
Large Send Offload (LSO) (Разгрузка большой отправки) — отключить (Disabled).TCP Checksum Offload (Разгрузка контрольной суммы TCP) — отключить (Disabled).Energy Efficient Ethernet или Green Ethernet (Энергосберегающий Ethernet) — отключить (Disabled).Дополнительно на сервере рекомендуется заблокировать механизм автоматического отключения простаивающих сессий. Для этого запустите командную строку от имени администратора и выполните команду:
net config server /autodisconnect:-1
---
Антивирусные продукты, особенно со встроенными сетевыми экранами (Firewall), очень чувствительны к постоянному интенсивному обмену данными между платформой 1С и сетевой папкой. Они могут блокировать или задерживать проверку мелких временных файлов блокировок 1С (файлов с расширением *.1cl), что мгновенно приводит к ошибке целостности базы у пользователя.
Выполните следующие рекомендации по настройке антивируса:
1cv8.exe на клиентах в список доверенных программ и исключений сканирования.---
Если сетевой сбой уже произошел, поврежденная копия структуры базы могла сохраниться в локальном кэше платформы на компьютере пользователя. Даже после устранения проблем с сетью пользователь будет продолжать видеть ошибку из-за кэшированных данных.
Для гарантированного устранения последствий сбоя выполните ручную очистку кэша на проблемном ПК:
Win + R, введите %userprofile%\AppData\Local\1C\1Cv8 и удалите все папки с длинными буквенно-цифровыми именами (UID).%userprofile%\AppData\Roaming\1C\1Cv8.Мы проанализировали причины возникновения плавающей ошибки «Файл базы данных поврежден» при работе по сети и изучили методы борьбы с ней. Помните, что администрирование файловой базы через сетевую «шару» всегда несет в себе риски подобных сбоев при росте числа пользователей. Наиболее надежным решением, которое сбережет время администратора и нервы пользователей, является переход на публикацию базы через IIS/Apache или использование терминального доступа (RDP).