При работе крупных информационных баз 1С на бесплатной СУБД PostgreSQL системные администраторы и программисты иногда сталкиваются с внезапными и пугающими сбоями. Один из самых критичных сценариев — аварийное завершение сеанса работы во время транзакции (например, при групповом перепроведении документов), после которого СУБД начинает утверждать, что основных таблиц базы данных просто не существует. При этом из журналов документов могут «исчезнуть» данные за несколько дней.
В этой статье мы подробно разберем причины возникновения ошибок relation "_documentjournalXXXX" does not exist и relation "params" does not exist, выясним, почему пропадают документы, и рассмотрим пошаговый план стабилизации системы без необходимости покупки дорогостоящих лицензий на MS SQL Server.
Давайте внимательно изучим лог-файл, зафиксированный в момент сбоя:
< 2020-03-05 20:30:37.059 MSK >ERROR: relation "_documentjournal6034" does not exist at character 8
< 2020-03-05 20:30:37.059 MSK >STATEMENT: UPDATE _DocumentJournal6034 SET _Date_Time = '2020-02-28 09:34:34'::timestamp ...
< 2020-03-05 20:30:37.071 MSK >WARNING: there is no transaction in progress
< 2020-03-05 20:30:52.249 MSK >ERROR: relation "params" does not exist at character 62
< 2020-03-05 20:30:52.249 MSK >STATEMENT: SELECT Creation,Modified,Attributes,DataSize,BinaryData FROM Params WHERE FileName = $1
Здесь СУБД PostgreSQL возвращает ошибку с кодом 42P01 (undefined_table). Сначала система не может найти таблицу журнала документов _DocumentJournal6034, а затем ключевую системную таблицу 1С — Params (в которой хранится вся конфигурация информационной базы). Сразу после этого выдается предупреждение о том, что транзакция отсутствует, хотя платформа пытается выполнить запись.
Такое поведение СУБД указывает на две основные технические проблемы:
public. При аварийном разрыве соединения процесса rphost с базой данных и мгновенной попытке восстановить сессию (либо при некорректной работе пулера соединений) у новой сессии может сброситься переменная окружения search_path. В результате СУБД начинает искать таблицы в системных схемах или во временных пространствах имен и, не находя их, выдает ошибку отсутствия таблицы.pg_class. Физически файлы таблиц остаются на диске, но СУБД «забывает» об их существовании.После перезапуска базы пользователи часто обнаруживают, что за последние несколько дней в журналах нет ни одного документа, хотя физически они заносились в базу. Почему это происходит?
При перепроведении или изменении документов платформа 1С выполняет операцию в рамках транзакции. Сначала очищаются движения и записи в таблице журнала документов (в нашем случае _DocumentJournal6034), а затем должны записаться новые данные. Из-за аварийного падения процесса rphost транзакция прервалась. При этом физические таблицы конкретных документов (например, _Document320, _Document345 и т.д.) остались целыми и невредимыми — пострадал только сам общий журнал.
Как восстановить данные без использования бэкапа:
Если у вас произошел подобный сбой, не спешите откатываться на вчерашний бэкап и терять дневную работу пользователей. Поскольку сами документы физически существуют в базе, их отображение в журнале можно восстановить стандартными средствами платформы. Для этого выполните следующие шаги:
В рассматриваемом кейсе база данных развернута на ОС Windows Server 2008 R2. Работа PostgreSQL под управлением Windows исторически сопряжена с повышенными рисками:
Дополнительным фактором нестабильности выступает старая версия платформы 8.3.14.1779. В ветках 8.3.14 наблюдались подтвержденные утечки памяти в процессах rphost при выполнении тяжелых запросов со временными таблицами. При достижении лимита памяти кластер 1С принудительно перезапускал рабочий процесс, аварийно обрывая активные транзакции в PostgreSQL, что и приводило к вылету программиста и последующим сбоям СУБД.
Если бюджет компании ограничен, покупать лицензии MS SQL Server нет необходимости. PostgreSQL — это мощная и стабильная СУБД, способная легко выдерживать работу 30 и более активных пользователей при условии правильной настройки. Давайте по шагам разберем, что нужно сделать.
Это самый важный шаг для обеспечения стабильности. Мы рекомендуем перенести сервер баз данных на Linux (например, Ubuntu Server, Debian или Postgres Pro OS). При этом сервер приложений 1С (кластер) может спокойно оставаться на вашем текущем сервере под управлением Windows. СУБД на Linux работает в разы стабильнее, эффективнее управляет разделяемой памятью (shared_buffers) и не страдает от специфических файловых блокировок Windows.
Обязательно обновите программное обеспечение до актуальных версий:
rphost и некорректным поведением транзакций на PostgreSQL.Для предотвращения порчи системных таблиц базы данных при пиковых дисковых нагрузках:
Стандартные настройки PostgreSQL ориентированы на минимальное потребление ресурсов и совершенно не подходят для баз данных 1С. Откройте файл конфигурации postgresql.conf и скорректируйте следующие параметры (расчет приведен для сервера с 32 ГБ ОЗУ):
# Выделяем под кэш СУБД около 25% от общего объема ОЗУ
shared_buffers = 8GB
# Лимит памяти для сложных запросов и сортировок на одно соединение
work_mem = 128MB
# Память для временных таблиц
temp_buffers = 128MB
# Память для обслуживания (индексы, вакуум)
maintenance_work_mem = 2GB
# Настройка эффективного размера кэша диска (около 50-75% ОЗУ)
effective_cache_size = 24GB
# Увеличиваем лимит блокировок для транзакций (актуально для тяжелых документов)
max_locks_per_transaction = 250
# Настройки оптимизации автовакуума, чтобы таблицы не распухали
autovacuum_max_workers = 4
autovacuum_vacuum_scale_factor = 0.05
autovacuum_analyze_scale_factor = 0.05
После изменения параметров обязательно перезапустите службу СУБД PostgreSQL для применения настроек.
Выполнив эти шаги, мы получим отказоустойчивую, быструю и полностью бесплатную систему управления базами данных, которая по надежности не уступает платным решениям от Microsoft.