Как почистить кэш 1С в клиент-серверном режиме с SQL

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

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

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

Какие виды кэша существуют в связке 1С + SQL

Понимание структуры кэша помогает чистить только нужный уровень, а не всё подряд. В клиент-серверной архитектуре выделяют четыре основных уровня кэширования.

Первый уровень — серверный кэш кластера 1С. Рабочие процессы rphost держат в памяти скомпилированные модули, метаданные, результаты запросов. Часть этих данных сбрасывается на диск в каталог srvinfo, в подпапки вида reg_1541 (номер зависит от порта кластера).

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

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

Очистка серверного кэша кластера 1С

Это основная процедура при SQL-развёртывании. Выполняется на сервере, где работает агент 1С:Предприятия, и требует остановки службы, поэтому планируйте её на нерабочее время.

Каталог srvinfo по умолчанию находится по пути C:\Program Files\1cv8\<версия платформы>\srvinfo (для 64-разрядной версии — C:\Program Files\1cv8\...). Если платформ несколько, ориентируйтесь на версию, под которой запущен агент. Внутри srvinfo есть подпапка реестра кластера, обычно reg_1541, а в ней — папка snccntx.

1. 1
   Предупредите пользователей и завершите их сеансы через консоль кластера или дождитесь окончания работы
2. 2
   Остановите службу «Агент сервера 1С:Предприятия» (services.msc или net stop)
3. 3
   Перейдите в srvinfo\reg_1541 и удалите папку snccntx (или переименуйте её для подстраховки)
4. 4
   Запустите службу агента сервера 1С
5. 5
   Проверьте, что база доступна и пользователи могут войти

Удалять можно именно snccntx. Файлы 1CV8Clst.lst, 1CV8Clstr.lst и папки с идентификаторами информационных баз трогать не нужно — там хранятся регистрация баз в кластере и журнал регистрации. Их удаление заставит заново прописывать базы в консоли кластера.

Очистка локального кэша на клиентских компьютерах

Даже в SQL-режиме каждый клиент хранит локальную копию метаданных конфигурации. Если после обновления у пользователя «старая» форма или ошибки при открытии объектов — почти наверняка виноват локальный кэш.

Кэш находится в профиле пользователя: %APPDATA%\1C\1cv8 и %LOCALAPPDATA%\1C\1cv8. Внутри — папки с именами в виде длинных идентификаторов (GUID), по одной на каждую информационную базу. Удалить можно как конкретную папку проблемной базы, так и все — при следующем запуске кэш создастся заново.

Альтернативный способ без поиска папок: удалить базу из списка в стартовом окне 1С и добавить её заново с тем же путём. При этом платформа сбросит привязку кэша. Ещё один вариант — параметр командной строки /ClearCache при запуске конфигуратора или тонкого клиента, который очищает кэш для конкретной базы.

taskkill /f /im 1cv8.exe & rmdir /s /q "%APPDATA%\1C\1cv8\cache" & rmdir /s /q "%LOCALAPPDATA%\1C\1cv8"

Нужно ли чистить кэш на стороне SQL Server

Частая ошибка — пытаться «почистить кэш 1С» средствами SQL Server: командами DBCC DROPCLEANBUFFERS или перезапуском службы СУБД. Буферный пул SQL Server не является кэшем 1С и не содержит устаревших метаданных — это кэш страниц данных, который СУБД использует для ускорения запросов.

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

Если проблема выглядит как «данные в базе есть, но 1С их не видит», причина почти всегда не в кэше SQL, а в сеансовых данных кластера, блокировках или в том, что пользователь смотрит не ту базу. Начинайте диагностику с уровней 1С, а не СУБД.

Когда очистка кэша действительно помогает

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

Если же наблюдаются медленные запросы, блокировки, ошибки СУБД или расхождения в данных — кэш ни при чём. Эти проблемы решаются обновлением статистики, пересмотром индексов, анализом запросов и настройкой параметров SQL Server.

Частые ошибки при очистке кэша

Самая распространённая ошибка — удаление содержимого srvinfo целиком. Вместе с кэшем удаляются регистрация баз в кластере и журнал регистрации, и восстановление занимает куда больше времени, чем сама чистка.

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

Как проверить результат после очистки

После очистки серверного кэша и запуска агента первый вход пользователей будет заметно медленнее обычного — платформа заново компилирует модули и заполняет кэш. Это нормально и проходит после первых минут работы.

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

FAQ: частые вопросы об очистке кэша 1С в SQL-режиме