Как исправить ошибку «Сервер баз данных не обнаружен» при крахе PostgreSQL с кодом 0xC0000005

← На главную

В процессе администрирования клиент-серверных версий «1С:Предприятие» под управлением СУБД PostgreSQL на операционной системе Windows администраторы часто сталкиваются с внезапным отключением всех пользователей. При этом в клиентских сессиях возникает критическая ошибка: «Сервер баз данных не обнаружен». Сама виртуальная машина с СУБД остается доступной по протоколу RDP, сеть работает стабильно, однако запустить «1С:Предприятие» невозможно ни с клиентских рабочих станций, ни локально на самом сервере приложений.

В этой статье мы подробно разберем природу этого сбоя, проанализируем логи СУБД, выясним причины аварийного завершения процессов PostgreSQL с кодом исключения 0xC0000005 и рассмотрим эффективные методы локализации и устранения данной проблемы.

Шаг 1. Анализ логов PostgreSQL и диагностика проблемы

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

Сначала управляющий процесс СУБД фиксирует крах одного из дочерних процессов и начинает принудительное закрытие всех остальных активных соединений для предотвращения разрушения данных в разделяемой памяти (shared memory):


2020-03-19 10:27:04.648 MSK [7100] ПРЕДУПРЕЖДЕНИЕ: закрытие подключения из-за краха другого серверного процесса
2020-03-19 10:27:04.648 MSK [7100] ПОДРОБНОСТИ: Управляющий процесс отдал команду этому серверному процессу откатить текущую транзакцию и завершиться, так как другой серверный процесс завершился аварийно и возможно разрушил разделяемую память.
2020-03-19 10:27:04.648 MSK [7100] КОНТЕКСТ: при изменении кортежа (6,5) в отношении "pg_statistic"

Чуть позже в логах появляется ключевая запись, раскрывающая техническую суть произошедшего сбоя:


2020-03-19 11:50:52.520 MSK [5064][]СООБЩЕНИЕ: 00000: процесс сервера (PID 1468) был прерван исключением 0xC0000005
2020-03-19 11:50:52.520 MSK [5064][]ПОДРОБНОСТИ: Завершившийся процесс выполнял действие: SELECT 1 FROM pg_catalog.pg_type as t WHERE typname = 'mchar' AND pg_catalog.pg_type_is_visible(t.oid);
2020-03-19 11:50:52.520 MSK [5064][]ПОДСКАЗКА: Описание этого шестнадцатеричного значения ищите во включаемом C-файле "ntstatus.h"
2020-03-19 11:50:52.520 MSK [5064][]ПОЛОЖЕНИЕ: LogChildExit, postmaster.c:3569
2020-03-19 11:50:52.520 MSK [5064][]СООБЩЕНИЕ: 00000: завершение всех остальных активных серверных процессов

Разберем подробнее эту информацию. Код исключения 0xC0000005 в операционной системе Windows означает Access Violation (нарушение прав доступа при работе с оперативной памятью). Это указывает на то, что процесс СУБД попытался обратиться к недопустимому или защищенному адресу памяти, что привело к его немедленной остановке операционной системой.

Действие, которое выполнял упавший процесс, представляет собой стандартный сервисный запрос платформы «1С:Предприятие». При инициализации каждого нового подключения платформа проверяет наличие и видимость специфических для 1С типов данных — mchar и mvarchar. Падение происходит именно в момент вызова системной функции СУБД pg_catalog.pg_type_is_visible(t.oid).

Шаг 2. Выяснение причин краха СУБД

Почему обычный поисковый запрос к системному каталогу приводит к падению всей СУБД? Рассмотрим несколько ключевых причин, вызывающих такое поведение системы.

1. Конфликт библиотек ICU в операционной системе Windows

Специфический тип данных mchar (разработанный для обеспечения совместимости логики сравнения строк в 1С с СУБД MS SQL Server) критически зависит от работы сторонних библиотек ICU (обычно это файлы icuuc.dll, icuin.dll, icudt.dll). Эти библиотеки отвечают за корректную работу с национальными кодировками, алфавитами и сортировками.

В операционной системе Windows существует глобальная переменная среды PATH. Если на сервере установлены другие программы (например, стороннее ПО для работы с базами данных, веб-серверы или специализированные утилиты), которые содержат свои собственные, несовместимые версии библиотек ICU, и пути к ним прописаны в системном PATH выше путей к PostgreSQL, служба СУБД может загрузить некорректные версии DLL. При обращении к функциям типа mchar происходит рассинхронизация адресного пространства памяти, что моментально вызывает исключение 0xC0000005 и падение процесса postgres.exe.

2. Физическое повреждение системного каталога и таблицы pg_statistic

Лог СУБД прямо указывает на ошибку в контексте изменения кортежа в таблице pg_statistic. Системные каталоги PostgreSQL (такие как pg_type, pg_statistic, pg_attribute) содержат метаданные обо всех таблицах базы данных. Если в результате аппаратного сбоя, некорректного завершения работы виртуальной машины или ошибок в дисковой подсистеме повредились индексы системного каталога, то при сканировании таблиц функция pg_type_is_visible натыкается на поврежденные указатели в оперативной памяти, вызывая крах процесса.

3. Особенности логического копирования через pg_dump

Очень часто администраторы пытаются решить проблему переносом базы данных на новый сервер с помощью утилит pg_dump и pg_restore. Однако при логическом резервном копировании структура поврежденного системного каталога и некорректно зарегистрированное расширение mchar выгружаются «как есть». При развертывании такого дампа на абсолютно новом сервере СУБД восстанавливается та же самая ошибочная структура метаданных, и новый чистый сервер начинает падать с точно такой же ошибкой 0xC0000005.

4. Влияние защитного ПО (Антивирусы и DEP)

Технология предотвращения выполнения данных (DEP) в ОС Windows защищает систему, блокируя запуск кода из областей памяти, помеченных как «только для данных». Некоторые сборки PostgreSQL или библиотеки расширений (включая mchar.dll) могут выполнять специфические вызовы к памяти, которые DEP или агрессивные алгоритмы антивирусного ПО (например, Kaspersky Endpoint Security) распознают как потенциальную угрозу (Buffer Overflow). В результате процесс принудительно завершается операционной системой с кодом нарушения доступа.

Шаг 3. Способы решения проблемы

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

Метод 1. Восстановление базы через выгрузку и загрузку файла конфигурации (.dt)

Это самый надежный и проверенный способ устранения логических искажений в системном каталоге СУБД. Выгрузка базы в формат .dt средствами самой платформы «1С:Предприятие» полностью очищает базу от платформенной специфики хранения данных СУБД и выгружает исключительно чистые прикладные объекты.

Выполним процедуру по шагам:

Запустите Конфигуратор поврежденной базы данных 1С (если СУБД падает слишком часто и не дает выполнить выгрузку, временно остановите службы других баз данных, чтобы снизить нагрузку и вероятность параллельных запросов).
Перейдите в меню Администрирование — Выгрузить информационную базу... и сохраните файл с расширением .dt.
В консоли администрирования PostgreSQL создайте абсолютно новую пустую базу данных с правильными параметрами локали (для 1С рекомендуется использовать локаль ru_RU.UTF-8 или аналогичную совместимую).
В консоли администрирования серверов «1С:Предприятие» зарегистрируйте новую информационную базу, указав имя только что созданной базы СУБД.
Откройте Конфигуратор новой пустой базы данных «1С».
Перейдите в меню Администрирование — Загрузить информационную базу... и выберите ранее созданный файл .dt.

При загрузке файла .dt платформа «1С» заново обращается к PostgreSQL, создает чистую структуру таблиц и заново регистрирует типы данных mchar и mvarchar. Все накопленные повреждения индексов системного каталога PostgreSQL при этом полностью нивелируются.

Метод 2. Реиндексация системного каталога СУБД

Если выгрузить базу в формат .dt не удается из-за постоянных падений сервера, можно попытаться восстановить целостность системного каталога непосредственно в PostgreSQL с помощью SQL-команд восстановления индексов.

Рассмотрим последовательность выполнения команд:

Подключитесь к проблемной базе данных через утилиту pgAdmin или консольный клиент psql от имени суперпользователя postgres.
Выполните команду восстановления индексов системного каталога для поврежденной базы данных: REINDEX SYSTEM имя_вашей_базы_данных; Эта команда полностью перестраивает все индексы во встроенных служебных таблицах СУБД, что устраняет проблемы с поиском типов данных.
После успешного завершения реиндексации принудительно обновите статистику планировщика запросов и очистите устаревшие записи: VACUUM ANALYZE;

Метод 3. Проверка системного окружения и переменных среды

Чтобы исключить влияние несовместимых DLL на сервере под управлением Windows, выполним следующие действия:

Откройте свойства системы (Win + Break — Дополнительные параметры системы — Переменные среды).
В разделе «Системные переменные» найдите переменную Path и нажмите «Изменить».
Проверьте список путей. Убедитесь, что пути к сторонним программам, содержащим библиотеки ICU, не стоят выше пути к каталогу bin установленного PostgreSQL.
Рекомендуется переместить путь к каталогу bin вашей СУБД PostgreSQL в самый верх списка Path.
Перезапустите службу PostgreSQL, чтобы применить изменения в окружении.

Метод 4. Настройка исключений DEP и Антивирусного ПО

Для предотвращения ложных срабатываний систем защиты информации:

Добавьте каталог установки СУБД PostgreSQL (особенно папки bin и lib) в список исключений сканирования вашего антивирусного ПО. Добавьте процесс postgres.exe в доверенные приложения.
Проверьте настройки DEP (Свойства системы — Дополнительно — Быстродействие — Параметры — Предотвращение выполнения данных). Если DEP включен для всех программ и служб, кроме выбранных, добавьте исполняемый файл СУБД postgres.exe в список исключений.

Заключение

Мы проанализировали причины возникновения критического краха СУБД PostgreSQL при совместной работе с «1С:Предприятие» на операционной системе Windows. Как показывает практика, падение процесса с ошибкой 0xC0000005 чаще всего связано с повреждением структуры системных метаданных СУБД или конфликтом библиотек динамической линковки в Windows. Использование механизма выгрузки/загрузки базы данных через файлы .dt является наиболее действенным решением, гарантирующим полное восстановление стабильности работы всей системы.