Очистка кэша клиент-серверной базы 1С на SQL: клиент, сервер, СУБД

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

Чистить нужно то место, где сидит проблема. Удалять всё подряд бессмысленно: после очистки сервера и СУБД первые минуты работа идёт медленнее, пока кэши наполняются заново.

Откуда берётся кэш и что в нём лежит

У клиент-серверной базы три независимых слоя. Они не зависят друг от друга, и очистка одного не затрагивает остальные.

Реальных данных базы во всех трёх слоях нет. Документы, справочники и регистры лежат в файлах .mdf/.ldf вашей базы, и кэш к ним не относится. Удаление кэша данные не затронет.

Что сделать до очистки

Подготовка занимает десять минут и страхует от неприятных сюрпризов.

1. Проверьте, кто сейчас работает. В консоли администрирования серверов 1С откройте кластер, затем «Сеансы» и «Соединения». Для клиентского кэша это не критично, для серверного обязательно.
2. Предупредите пользователей. Очистка серверной части требует остановки службы, а значит, отключения всех сеансов.
3. Сделайте резервную копию базы средствами SQL Server. Кэш в копию не входит, но лишняя копия перед любыми действиями на сервере не помешает.
4. Запишите список информационных баз пользователя, если его придётся удалять профиль. Список баз хранится в файле ibases.v8i (обычно в %APPDATA%\1C\1CEStart), и его лучше не трогать.
5. Закройте все окна 1С на компьютере, где чистите клиентский кэш. Иначе часть файлов окажется заблокирована.

Файлы базы (.mdf, .ldf), каталог кластера целиком и файл ibases.v8i удалять нельзя. Удаляйте только подпапки кэша, которые описаны ниже.

Как почистить кэш 1С на компьютере пользователя

Начинайте отсюда: способ безопасный, занимает две минуты, решает большую часть жалоб.

Вручную через проводник

1. Закройте 1С полностью. Проверьте в диспетчере задач, что нет процесса 1cv8.exe или 1cv8c.exe.
2. Нажмите Win+R, введите %LOCALAPPDATA%\1C\1cv8 и откройте папку.
3. Удалите внутри папки каталоги с длинными именами вида xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx. Это кэш по информационным базам.
4. Повторите то же для %APPDATA%\1C\1cv8.
5. Запустите 1С. Первый вход будет дольше обычного: платформа заново прочитает метаданные.

Файлы 1cv8strt.pf, 1cv8.pfl и список баз ibases.v8i лежат в соседних каталогах, их не трогайте.

Параметром запуска

Если ходить по папкам лень или пользователей много, добавьте ключ /ClearCache в строку запуска ярлыка:

"C:\Program Files\1cv8\8.3.xx.xxxx\bin\1cv8.exe" ENTERPRISE /S "server\base" /ClearCache

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

То же можно сделать для конфигуратора, заменив ENTERPRISE на DESIGNER.

Временные файлы Windows

Отдельно проверьте каталог %TEMP%. Сюда платформа складывает выгрузки, промежуточные файлы печатных форм и вложений. Удалять можно всё, что не занято процессами. На терминальных серверах такие каталоги быстро разрастаются до гигабайтов, особенно если пользователи работают месяцами без перезахода в сессию.

Как очистить кэш на сервере 1С

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

Отключите сеансы и остановите службу

1. В консоли серверов 1С завершите все сеансы информационной базы. Если пользователи не реагируют на предупреждение, разорвите соединения принудительно.
2. Остановите службу «Агент сервера 1С:Предприятия 8.3» через оснастку «Службы» или командой от администратора:

net stop "1C:Enterprise 8.3 Server Agent (x86-64)"

Точное имя службы смотрите в оснастке: оно зависит от версии платформы и разрядности.

Удалите данные сеансов

1. Откройте каталог кластера. Путь указан в свойствах службы в параметре -d, часто это srvinfo.
2. Зайдите в подкаталог кластера (имя вида reg_1541).
3. Внутри найдите папки, начинающиеся с snccntx. Это данные сеансов. Их можно удалить.
4. Папки с GUID-именами, файл 1CV8Clst.lst и остальные служебные файлы оставьте. В них хранятся настройки кластера и список баз.
5. Запустите службу обратно и проверьте, что кластер виден в консоли.

net start "1C:Enterprise 8.3 Server Agent (x86-64)"

Не удаляйте файл 1CV8Clst.lst и каталоги, в которых нет snccntx в названии. Без них придётся пересоздавать кластер и заново регистрировать базы.

Если рабочие процессы разрослись

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

Как сбросить кэш на стороне SQL Server

Это самый осторожный пункт. Кэш СУБД нужен, чтобы запросы не читали диск, и его очистка сразу бьёт по скорости. Применяйте только при понятной причине: подозрение на «застрявший» плохой план запроса или тестирование производительности.

Кэш планов запросов

Если конкретный запрос внезапно стал выполняться в десятки раз дольше, а данных стало не сильно больше, вероятно, SQL Server запомнил неудачный план. Сбросить планы можно так:

DBCC FREEPROCCACHE;

Команда очищает планы всего экземпляра. Если на нём работают другие базы, у них тоже пересоберутся планы. Чтобы затронуть одну базу, используйте ALTER DATABASE SCOPED CONFIGURATION CLEAR PROCEDURE_CACHE; (в новых версиях SQL Server) либо удалите один план по его дескриптору.

Буферный кэш

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

CHECKPOINT;
DBCC DROPCLEANBUFFERS;

После этого первые запросы будут читать данные с диска, и пользователи почувствуют замедление. В рабочее время так делать не стоит.

Статистика и индексы вместо «очистки»

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

EXEC sp_updatestats;

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

Размер tempdb

База tempdb не кэш в строгом смысле, но на ней завязаны сортировки и временные таблицы 1С. Если она разрослась, помогает перезапуск службы SQL Server (при этом tempdb создаётся заново). Это остановка для всех баз экземпляра, планируйте её на нерабочее время. Чтобы проблема не возвращалась, задайте начальный размер файлов tempdb разумным и разнесите их по нескольким файлам.

Регламентная очистка и автоматизация

Руками чистить кэш каждый раз утомительно. Часть работы легко переложить на планировщик.

Скрипт очистки клиентского кэша

Простой bat-файл удаляет кэш при входе в сеанс или раз в неделю:

@echo off
rd /s /q "%LOCALAPPDATA%\1C\1cv8" 2>nul
rd /s /q "%APPDATA%\1C\1cv8" 2>nul

Запускайте его через групповую политику (скрипт входа) или планировщик заданий. Учтите: каждый запуск 1С после такой очистки будет медленнее, поэтому для ежедневного применения скрипт не годится. Раз в неделю или в месяц достаточно.

Рекомендуемое расписание

Для задач SQL Server используйте агент: он умеет запускать скрипты по расписанию и присылать уведомления при ошибке. Если версия SQL Server не содержит агента (Express), подойдёт планировщик Windows с утилитой sqlcmd.

Что проверить после очистки

После любой очистки делайте короткую проверку, чтобы убедиться, что проблема ушла и ничего не сломалось.

Проверьте три вещи. Первое: открывается ли проблемная форма, отчёт или справочник. Второе: нет ли новых ошибок в журнале регистрации. Третье: не выросла ли нагрузка на диск сервера и не держится ли она высокой дольше получаса.

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

Частые вопросы