В процессе администрирования клиент-серверных информационных баз 1С:Предприятия системные инженеры часто сталкиваются с переполнением системного диска временными файлами. Попытка вручную очистить содержимое папки Temp под учетной записью службы сервера (например, C:\Users\USR1CV8.1CTERM\AppData\Local\Temp) при активных сеансах пользователей и работающих службах кластера приводит к критическим системным сбоям.
Типичное проявление проблемы: при интерактивном сохранении элемента справочника через пользовательский интерфейс платформа выдает исключение вида: Файл не обнаружен 'C:\Users\USR1CV8.1CTERM\AppData\Local\Temp\v8_XXXX_XXX.tmp'. 2(0x00000002): Не удается найти указанный файл. При этом программное создание и запись того же самого объекта (например, через внешнюю обработку или консоль кода) продолжают выполняться без ошибок. Ниже подробно рассмотрены причины такого поведения платформы, риски нарушения целостности базы и регламент полного устранения неполадки.
В клиент-серверной архитектуре 1С:Предприятия рабочие процессы сервера (rphost) непрерывно взаимодействуют с дисковой подсистемой. При открытии и редактировании формы объекта в тонком клиенте задействуется сложный механизм сериализации данных между клиентом и сервером. В каталоге Temp служебного пользователя создаются временные файлы с расширением .tmp, в которых хранятся промежуточные состояния форм, структуры навигации, кэш метаданных сеанса, блокировки и контекст редактирования.
Если временный каталог очищается «на лету» без предварительной остановки процессов платформы, происходят следующие события:
rphost сохраняет в своей оперативной памяти дескрипторы и ссылки на созданные ранее временные файлы.0x00000002 (ERROR_FILE_NOT_FOUND).При чисто программном создании объекта (через Справочники[Имя].СоздатьЭлемент()) обращение к интерактивному контексту формы и ее клиентским временным буферам отсутствует. Код формирует объект непосредственно в контексте сервера и записывает его напрямую в таблицы СУБД в рамках единой транзакции, не запрашивая удаленные временные файлы пользовательского сеанса. Именно поэтому программная запись работает, создавая ложное впечатление, что база данных полностью исправна.
Ручная очистка каталогов под запущенным сервером 1С — это грубое вмешательство в рабочую среду, способное повлечь рассогласование сеансовых данных, зависание рабочих процессов и нарушение ссылочной целостности таблиц СУБД из-за аварийно оборванных транзакций. Перед выполнением любых технических операций необходимо соблюдать строгий протокол:
.dt из поврежденной среды может завершиться ошибкой или создать неполноценный архив, поэтому приоритет всегда отдается резервной копии на уровне СУБД.1Cv8Log или файл 1Cv8.lgd).Первый и обязательный этап восстановления работоспособности — сброс зависших файловых дескрипторов в памяти рабочих процессов сервера и корректная очистка временных папок операционной системы.
Порядок выполнения:
services.msc) с правами администратора.net stop "1C:Enterprise 8.3 Server Agent"
ragent.exe, rmngr.exe и rphost.exe полностью завершили работу. Если какой-либо рабочий процесс завис, завершите его принудительно.C:\Users\USR1CV8.1CTERM\AppData\Local\Temp\
Temp: учетная запись, под которой запускается служба сервера (в данном случае USR1CV8.1CTERM), должна обладать полными правами (Full Control) на эту папку и все вложенные объекты.net start "1C:Enterprise 8.3 Server Agent"
Ограничения: если повреждение затронуло внутренние таблицы сеансовых данных кластера, одного перезапуска службы и очистки папки Temp ОС может оказаться недостаточно, и платформа продолжит выдавать ошибки при обращении к старым сеансам.
Если после перезапуска службы ошибка сохраняется, причина кроется в повреждении серверного кэша контекстов и сеансов, который 1С хранит отдельно от временной папки Windows.
Серверный кэш расположен в каталоге данных кластера (параметр -d при установке агента). По умолчанию путь выглядит следующим образом:
C:\Program Files\1cv8\srvinfo\reg_1541\
Внутри этой директории находятся папки с именами вида snccntx<уникальный_идентификатор_базы> (например, snccntxf9a8323e-fb9d-481d-834f-3d4663dec7f8), содержащие файлы сеансовых контекстов snccntx.dat, snccntx.00000000.dat и временные журналы.
Пошаговый алгоритм безопасной очистки кэша сервера:
net stop "1C:Enterprise 8.3 Server Agent"). Удалять файлы из srvinfo при работающей службе категорически запрещено.C:\Program Files\1cv8\srvinfo\reg_1541\ (номер порта 1541 может отличаться, если кластер настроен на нестандартных портах).snccntx.snccntx.*).Критическое предупреждение: ни в коем случае не удаляйте конфигурационные файлы кластера, находящиеся в корне каталога srvinfo и reg_1541, такие как 1CV8Clst.lst, 1CV8Reg.lst и 1cv8wsmn.lst. Удаление этих файлов приведет к полной потере списка зарегистрированных баз, настроек кластера, администраторов и профилей безопасности!
После очистки файлов snccntx запустите службу сервера. При старте кластер автоматически инициализирует новые чистые структуры сеансовых данных.
В ситуациях, когда повреждение внутренних дескрипторов кластера не устраняется очисткой кэша, применяется метод перерегистрации базы в кластере 1С. Этот способ позволяет полностью обнулить внутренний идентификатор базы в кластере и пересоздать все связанные с ней серверные каталоги, не затрагивая сами данные в СУБД.
Порядок перерегистрации:
Внезапное исчезновение временных файлов в момент транзакции могло прервать запись данных во вспомогательные таблицы или индексы. Поэтому после восстановления запуска базы в обязательном порядке проводится регламентное «Тестирование и исправление» (ТиИ).
Условия и порядок проведения:
Если ТиИ завершилось без критических системных сообщений, можно снять блокировку сеансов и допустить пользователей к работе.
Чтобы избежать повторения инцидента в будущем, настройте обслуживание серверов в соответствии с лучшими практиками администрирования 1С:
Temp, AppData или srvinfo при запущенных службах 1С:Предприятия.Temp файлы старше определенного срока (например, более 1–2 суток), очищать сеансовые папки snccntx и запускать службу обратно.srvinfo, рабочие папки СУБД и каталог Temp служебной учетной записи сервера 1С должны быть добавлены в исключения проверки антивирусного ПО на лету, так как блокировка файлов антивирусом вызывает точно такие же ошибки с кодом 0x00000002.