Почему 1С вылетает каждые 2 часа с ошибкой базы PostgreSQL и как это исправить?

В процессе эксплуатации 1С в клиент-серверном варианте на базе PostgreSQL нередко возникают критические сбои, сопровождающиеся аварийным завершением серверных процессов. Если вы наблюдаете ошибки вида 0xC0000005 или invalid memory alloc request size, это сигнализирует о физическом повреждении данных в одной из таблиц базы. Рассмотрим, как провести диагностику и восстановить работоспособность системы.

Шаг 1. Диагностика причин падения

Первым делом проанализируем логи PostgreSQL. В них вы обнаружите записи о завершении серверного процесса по исключению 0xC0000005 (ошибка доступа к памяти). Это происходит, когда Postgres пытается считать поврежденную запись, и из-за нарушения структуры данных серверный процесс аварийно завершается, что приводит к разрыву соединений со всеми активными клиентами 1С.

Чтобы понять, какая именно таблица повреждена, изучите логи на предмет запросов, которые исполнялись в момент сбоя. Чаще всего это обращения к регистрам сведений, например, к таблице _InfoRg15978. Идентификация имени таблицы — критически важный этап, так как именно она содержит «битую» запись.

Шаг 2. Создание безопасной среды для экспериментов

Никогда не выполняйте удаление данных в «боевой» базе!

1. Остановите службу PostgreSQL.
2. Скопируйте всю директорию data (каталог данных кластера) в отдельное место на диске.
3. Разверните копию базы на отдельном сервере или поднимите отдельный экземпляр PostgreSQL, указав в конфигурации скопированный каталог data.
4. Дальнейшие манипуляции проводите исключительно с этой копией.

Шаг 3. Локализация и очистка поврежденной записи

После идентификации таблицы (в нашем случае это _InfoRg15978) необходимо избавиться от поврежденных данных, которые препятствуют выполнению pg_dump и работе 1С. Поскольку стандартные инструменты вроде ТИИ (Тестирование и исправление) завершаются ошибкой, мы воспользуемся SQL-инструментарием.

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

-- Пример запроса для поиска поврежденных данных в таблице
SELECT ctid, * 
FROM public._inforg15978 
ORDER BY ctid 
LIMIT 1000 OFFSET 0;

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

-- Удаление конкретной битой записи
DELETE FROM public._inforg15978 
WHERE ctid = '(номер_страницы, номер_строки)';

Шаг 4. Восстановление и профилактика

После удаления поврежденной записи рекомендуется выполнить следующие действия:

1. Переиндексация: Выполните REINDEX TABLE _inforg15978, чтобы привести структуру индексов в порядок.
2. Вакуум: Запустите VACUUM ANALYZE для очистки таблицы от «мертвых» строк.
3. Обновление ПО: Убедитесь, что вы используете актуальный минорный релиз PostgreSQL 11-й ветки. Версия 11.5 давно устарела и содержит известные баги, которые могут приводить к подобным ситуациям.
4. Проверка оборудования: Повреждение страниц данных часто вызвано проблемами с оперативной памятью (отсутствие ECC) или сбоями файловой системы. Обязательно выполните проверку диска системными средствами chkdsk.

Заключение

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