Почему не пишется технологический журнал 1С и как устранить сбои с файлом базы данных 1Cv8tmp.1CD?

Системный администратор 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

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

Шаг 1. Исправление файла конфигурации технологического журнала logcfg.xml

Самая распространенная причина, по которой платформа 1С игнорирует файл logcfg.xml, — отсутствие обязательного пространства имен в корневом теге <config>. Платформа строго проверяет валидность XML-структуры, и при отсутствии атрибута xmlns чтение конфигурации сбрасывается без вывода предупреждений пользователю.

Посмотрим на пример некорректного файла конфигурации:


<config>
<log location="C:\Users\Reception2\Documents\1clog" history="168">
<event>
<eq property="Name" value="excp"/>
</event>
<property name="all"> </property>
</log>
</config>

Чтобы технологический журнал начал собираться, заменим корневой элемент и укажем корректный заголовок с пространством имен платформы 1С:


<config xmlns="http://v8.1c.ru/v8/tech-log">
    <log location="C:\Logs\1C_Log" history="168">
        <event>
            <eq property="Name" value="excp"/>
        </event>
        <property name="all"/>
    </log>
</config>

Обратим внимание на основные параметры конфигурации:

  1. location — путь к каталогу, куда будут записываться файлы журнала. Рекомендуется использовать короткие пути на локальном диске (например, C:\Logs\1C_Log), избегая кириллицы и пробелов.
  2. history — период хранения логов в часах, по истечении которого старые файлы будут удаляться автоматически.
  3. event — фильтрация собираемых событий. Значение excp позволяет собирать только исключительные ситуации и аварийные дампы, минимизируя нагрузку на дисковую подсистему.
  4. property name="all" — фиксация всех доступных свойств произошедшего события.

Шаг 2. Проверка расположения файла и прав доступа в файловой системе

Разберем требования к правам доступа и расположению конфигурационного файла:

  1. Каталог размещения: Файл logcfg.xml должен находиться в подкаталоге conf конкретной используемой версии платформы (например, C:\Program Files (x86)\1cv8\8.3.10.2580\bin\conf) либо в общеплатформенном каталоге C:\Program Files (x86)\1cv8\conf.
  2. Права на чтение: У учетной записи пользователя Windows или системной службы, от имени которой стартует процесс 1cv8.exe (или 1cv8c.exe), должны быть права на чтение файла logcfg.xml и каталога conf.
  3. Права на запись: В каталог, указанный в параметре location, учетная запись пользователя должна иметь полные права (Modify / Full Control) на создание файлов и подкаталогов.

Если технологический журнал по-прежнему не создается, проанализируем обращение процессов 1С к файловой системе с помощью утилиты Process Monitor (Procmon) от Microsoft Sysinternals. Установим фильтр по имени процесса Process Name is 1cv8c.exe и операциям с файлами, чтобы точно увидеть, пытается ли платформа прочитать logcfg.xml и получает ли ошибку ACCESS DENIED при попытке создания папки логов.

Шаг 3. Анализ причин ошибки «Отсутствует файл базы данных 1Cv8tmp.1CD»

После успешной настройки технологического журнала событие EXCP фиксирует сбой вида:


55:09.298000-0,EXCP,0,process=1cv8c,Exception=DatabaseException8,Descr="Отсутствует файл базы данных '\\Server2008\1c\УМЦ Доктор Симкин/1Cv8tmp.1CD'"

Файл 1Cv8tmp.1CD создается платформой динамически для выполнения временных выборок, сложных сортировок и хранения промежуточных данных запросов. Выясним основные причины его повреждения или внезапного исчезновения:

  1. Кэширование протокола SMB (SMB2 / SMB3): При многопользовательской работе с файловой базой через сетевую папку (UNC-путь) механизмы кэширования метаданных каталогов Windows не успевают синхронизировать состояние временных файлов между клиентскими ПК. Когда один сеанс завершает работу с временной таблицей, файл удаляется, а второй сеанс из-за задержек кэша пытается его заблокировать, вызывая сбой DatabaseException8.
  2. Смешанный доступ к базе: Одновременный запуск пользователей локально на сервере (через RDP) и по сети через сетевой ресурс (UNC-путь) приводит к рассинхронизации файловых блокировок (файлы *.cfl).
  3. Блокировка антивирусным ПО: Проверка открытых файлов базы данных антивирусом или средствами инкрементного резервного копирования кратковременно блокирует дескриптор файла, что разрывает транзакцию платформы.

Шаг 4. Настройка операционной системы и исключений безопасности

Для стабилизации сетевого взаимодействия с файловой базой выполним системные настройки на всех клиентских машинах и файловом сервере.

1. Отключение клиентского кэширования SMB:

На клиентских компьютерах в ветке системного реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters создадим параметры типа DWORD (32 бита) со значением 0:

  1. DirectoryCacheLifetime = 0
  2. FileInfoCacheLifetime = 0
  3. FileNotFoundCacheLifetime = 0

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

2. Отключение оппортунистических блокировок на сервере:

В ветке реестра сервера HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters зададим параметр типа DWORD: EnableOplocks = 0, после чего перезагрузим службу сервера или операционную систему.

3. Добавление исключений в антивирус:

В настройках антивирусного сканера на сервере и рабочих местах добавим в список исключений:

  1. Каталог с файловой базой данных целиком.
  2. Процессы платформы: 1cv8.exe, 1cv8c.exe, 1cv8s.exe.
  3. Каталоги временных файлов пользователей (%TEMP%, %LOCALAPPDATA%\1C\1cv8).
  4. Расширения файлов 1С: *.1cd, *.1ch, *.cfl, *.tmp.

Шаг 5. Архитектурные решения для предотвращения сбоев файловой базы

Прямой доступ нескольких пользователей к файлу базы данных через общий сетевой ресурс (SMB) архитектурно нестабилен на современных конфигурациях. Для полного устранения проблем рекомендуется использовать один из следующих подходов:

  1. Публикация базы на веб-сервере (IIS или Apache): Файловая база публикуется на локальном веб-сервере. Пользователи подключаются через тонкий клиент по протоколу HTTP/HTTPS (строка соединения вида http://server/base_name). В таком режиме непосредственный доступ к файлу .1CD выполняет только рабочий процесс веб-сервера, что исключает сетевые сбои SMB и рассинхронизацию временных файлов.
  2. Изоляция работы внутри терминального сервера (RDP): Если база не опубликована на веб-сервере, перенесем файл базы на локальный диск сервера и организуем подключение всех пользователей исключительно через сеансы удаленного рабочего стола.
  3. Переход на клиент-серверный вариант (SQL): При регулярных сбоях и активной многопользовательской работе оптимальным решением является переход на полноценную клиент-серверную архитектуру (сервер 1С:Предприятия + СУБД PostgreSQL, MS SQL Server и др.), где управление временными таблицами и транзакционной целостностью выполняется средствами СУБД.
← На главную