Как почистить кэш SQL-базы 1С

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

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

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

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

Первый уровень — кэш метаданных сервера 1С:Предприятия. Он хранится в файловом виде в каталоге srvinfo агента сервера, внутри папок вида reg_1541 (номер зависит от порта кластера). Там сервер держит скомпилированные описания конфигурации, чтобы не читать их из базы при каждом обращении. Именно этот кэш чаще всего виноват в ошибках «Ошибка формата потока», «Несоответствие версии метаданных» и странном поведении после обновления.

Второй уровень — кэш самой СУБД. В MS SQL Server это процедурный кэш (скомпилированные планы запросов), буферный пул (страницы данных в памяти) и кэш метаданных самого SQL Server. В PostgreSQL — shared buffers и кэш планов подготовленных выражений. Этот кэш живёт в оперативной памяти и сбрасывается при перезапуске службы СУБД либо специальными командами.

Третий, часто забываемый уровень — клиентский кэш 1С на компьютерах пользователей (каталоги с GUID-именами в %APPDATA%\1C\1cv8). Формально это не SQL-кэш, но симптомы его повреждения похожи, и чистить серверный кэш, когда проблема на клиенте, бессмысленно.

Как понять, какой кэш нужно чистить

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

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

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

Очистка кэша метаданных сервера 1С

Это самая частая операция. Порядок действий: завершите сеансы пользователей через консоль кластера или дождитесь окончания рабочего дня, остановите службу «Агент сервера 1С:Предприятия», затем удалите содержимое папок reg_* внутри каталога srvinfo (типичный путь в Windows — C:\Program Files\1cv8\srvinfo, в Linux — /opt/1cv8/... или /var/1cv8/... в зависимости от версии). После этого запустите службу снова. Кэш будет пересоздан автоматически при первом обращении.

Удалять можно только содержимое каталогов reg_* — сами папки и файл 1CV8Clst.lst в srvinfo трогать нельзя: в нём хранится список информационных баз кластера. Потеря этого файла означает, что базы придётся заново регистрировать в кластере вручную. Перед удалением разумно не стирать каталоги, а переименовать их — тогда при неудаче можно быстро откатиться.

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

1. 1
   Завершите активные сеансы пользователей в консоли кластера
2. 2
   Остановите службу агента сервера 1С:Предприятия
3. 3
   Переименуйте или удалите содержимое каталогов reg_* внутри srvinfo (файл 1CV8Clst.lst не трогайте)
4. 4
   Запустите службу агента сервера
5. 5
   Войдите в базу и проверьте, что ошибка ушла, а конфигурация открывается нормально

Очистка кэша MS SQL Server

Для сброса процедурного кэша MS SQL Server используется команда DBCC FREEPROCCACHE. Она удаляет все скомпилированные планы запросов, и СУБД начнёт строить их заново. Можно сбросить кэш как для всего сервера, так и для конкретной базы — второй вариант предпочтительнее, если на сервере работают другие приложения.

Буферный кэш данных очищается командой DBCC DROPCLEANBUFFERS, но на боевом сервере делать это почти никогда не нужно: после сброса SQL Server вынужден читать все данные с диска, и производительность резко просядет, пока кэш снова не прогреется. Эта команда уместна только в тестовых средах для честных замеров производительности.

Часто вместо сброса кэша правильнее обновить статистику — командой UPDATE STATISTICS или через план обслуживания. Устаревшая статистика по таблицам — более частая причина неоптимальных планов, чем «испорченный» кэш. После обновления статистики затронутые планы перекомпилируются автоматически.

-- Сброс процедурного кэша конкретной базы
USE [MyBase1C];
GO
DBCC FREEPROCCACHE;
GO
-- Обновление статистики по всем таблицам базы
EXEC sp_updatestats;
GO

Очистка кэша PostgreSQL

В PostgreSQL нет прямого аналога DBCC FREEPROCCACHE — кэш планов здесь устроен иначе. Планы подготовленных выражений существуют в рамках сессии и сбрасываются командой DISCARD ALL или DISCARD PLANS, но поскольку сервер 1С переиспользует соединения, надёжнее перезапустить сеансы или саму службу PostgreSQL.

Полный сброс всех кэшей достигается перезапуском службы PostgreSQL. Shared buffers при этом очищаются, и первые минуты после старта база будет работать медленнее обычного — это нормально. Как и в случае с MS SQL, часто вместо сброса кэша эффективнее выполнить ANALYZE по базе, чтобы планировщик получил актуальную статистику.

Для баз 1С на PostgreSQL также важно следить за настройками autovacuum: раздувание таблиц (bloat) из-за отключённого или редкого автовакуума даёт симптомы, похожие на проблемы кэша, — запросы постепенно деградируют. Регулярный VACUUM ANALYZE в таких случаях помогает лучше любой очистки кэша.

# Перезапуск PostgreSQL (пример для Linux, имя службы зависит от версии)
sudo systemctl restart postgresql
# Обновление статистики из psql:
# psql -d mybase1c -c "ANALYZE;"

Риски и меры предосторожности

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

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

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

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

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

После сброса кэша СУБД оцените скорость выполнения проблемного запроса или отчёта. В MS SQL полезно посмотреть фактический план запроса в Management Studio и сравнить его с тем, что был до очистки. Если план изменился и время выполнения сократилось — цель достигнута. Если время не изменилось, проблема не в кэше, и нужно анализировать индексы, блокировки и сам запрос.

Зафиксируйте в журнале, что и когда было очищено и какой эффект получен. При повторении проблемы эта информация сэкономит часы диагностики и поможет отличить разовый сбой от системной неисправности.

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