При активной разработке и администрировании систем на платформе 1С:Предприятие 8.3 в связке с СУБД PostgreSQL специалисты часто сталкиваются со странным поведением системы: база данных успешно обновлена, однако новые или измененные процедуры, функции или даже целые объекты метаданных упорно «не видны» платформе. При этом, если загрузить ту же самую конфигурацию в абсолютно новую, чистую базу данных, всё работает корректно.
В этой статье мы подробно разберем, почему возникает эта проблема, где именно хранятся «фантомные» данные старой конфигурации и как правильно произвести очистку кэша на всех уровнях — от клиентского компьютера до сервера приложений 1С и СУБД PostgreSQL — без риска повредить работоспособность кластера.
Платформа 1С использует многоуровневое кэширование для оптимизации производительности и снижения сетевого трафика между клиентом, сервером приложений и СУБД. В идеальных условиях механизмы кэширования своевременно обновляют локальные копии метаданных. Однако при использовании так называемых «динамических обновлений» (в простонародье — «демонических»), аварийных завершений сессий пользователей или сбоев сетевого соединения между сервером приложений и PostgreSQL, цепочка актуализации данных разрывается. Сервер 1С продолжает обращаться к старым версиям программных модулей, сохраненным в его локальном кэше.
Очистка стандартного кэша на локальном компьютере пользователя в каталогах AppData в таких ситуациях не приносит результатов, поскольку искаженная информация уже зафиксирована на стороне сервера приложений или в таблицах самой СУБД. Чтобы решить проблему, нам потребуется последовательно проанализировать и очистить кэш на стороне сервера.
Часто в поисках решения системные администраторы совершают критическую ошибку — полностью очищают каталог реестра кластера 1С. Разберем, как выполнить эту процедуру безопасно.
По умолчанию на операционной системе Windows реестр кластера и его кэш расположены по пути: C:\Program Files\1cv8\srvinfo\. Внутри этой директории находится каталог реестра, обычно с именем reg_1541.
Важное предупреждение: Полное удаление папки reg_1541 приведет к уничтожению всего кластера серверов 1С! Будет безвозвратно удален список зарегистрированных информационных баз, настройки администраторов, журналы регистрации, настройки полнотекстового поиска и профили безопасности.
Для безопасной ручной очистки серверного кэша выполним следующие действия:
1C:Enterprise 8.3 Server Agent (или ragent в Linux). Если этого не сделать, файлы будут заблокированы процессами платформы, а принудительное удаление может вызвать сбой файловой структуры.C:\Program Files\1cv8\srvinfo\reg_1541\ (или аналогичный, если порт кластера отличается от стандартного 1541). Путь для Linux-систем по умолчанию выглядит так: /home/usr1cv8/.1cv8/1C/1cv83/reg_1541/.1a2b3c4d-5e6f-7a8b-9c0d-1e2f3a4b5c6d.snccntx (кэш сеансовых данных) и scntxt.1CV8Reg.lst и 1CV8Reg.1cl.Если безопасная очистка серверного кэша 1С не принесла результатов, значит, некорректная версия структуры метаданных зафиксировалась непосредственно в таблицах базы данных под управлением PostgreSQL. Это типичное следствие сбоя при записи конфигурации поверх старой базы.
Для исправления ситуации выполним точечную очистку служебных таблиц 1С через консоль запросов pgAdmin или любую другую утилиту администрирования PostgreSQL. Разберем этот процесс по шагам:
configsave. Данная таблица используется платформой для временного хранения конфигурации в процессе её редактирования и обновления. В стабильном состоянии базы данных, когда конфигуратор закрыт и все обновления применены, эта таблица должна быть абсолютно пустой. Если в ней зависли строки, очистим их запросом:
DELETE FROM configsave;
config и params, указывающие серверу приложений на необходимость слияния старой конфигурации с новыми изменениями «на лету». Если эти маркеры зависли, сервер будет бесконечно обращаться к старым версиям процедур. Удалим эти маркеры с помощью следующих запросов:
DELETE FROM config WHERE filename = 'DynamicallyUpdated';
DELETE FROM params WHERE filename = 'DynamicallyUpdated';
После выполнения этих запросов обязательно откроем базу данных в режиме «Конфигуратор». Чтобы заставить платформу полностью перекомпилировать внутренние индексы метаданных, внесем любое незначительное изменение в конфигурацию (например, добавим пробел в неиспользуемый комментарий общего модуля), сохраним изменения и выполним обновление конфигурации базы данных, нажав клавишу F7.
Иногда сама СУБД PostgreSQL продолжает удерживать в оперативной памяти кэшированные планы выполнения запросов и структуру процедур для открытых сессий. Поскольку сервер приложений 1С постоянно поддерживает пул активных соединений с СУБД для быстродействия, эти внутренние кэши СУБД могут не сбрасываться автоматически.
Для полного сброса у нас есть два пути:
SELECT pg_terminate_backend(pid)
FROM pg_stat_activity
WHERE datname = 'имя_вашей_базы_данных';
После выполнения этого запроса сервер 1С автоматически инициализирует новые, чистые подключения к PostgreSQL, которые заново и корректно прочитают структуру таблиц и процедур.
В завершение рассмотрим, как исключить влияние локального кэша на конкретном рабочем месте пользователя, если изменения не видны только у определенных сотрудников:
/ClearCache. Этот параметр заставляет тонкий и толстый клиенты принудительно очищать кэш метаданных при каждом запуске программы.ibases.v8i. Если удалить базу из списка в окне запуска 1С, нажать кнопку «Добавить» и прописать её заново с теми же параметрами подключения, платформа сгенерирует для неё новый GUID. Старый, возможно поврежденный кэш на диске пользователя просто перестанет использоваться, а для базы создастся новая чистая папка.Регулярное использование этих превентивных мер и понимание структуры хранения кэша позволят вам избегать длительных простоев систем и гарантировать корректную работу всех обновлений в вашей связке 1С и PostgreSQL.