Сервер баз данных не обнаружен

Форум Администрирование Сервер, сеть, оборудование (Hardware)

1. Snark13 18.03.20 15:58 Сейчас в теме

Имеется сервер 1С (8.3.16.1063) (поднят на виртуальной машине) + сервер Postgres (отдельная виртуальная машина)

Пользователи подключаются напрямую к серверу, через терминальный сервер и через web

Последнее время стала появляться ошибка - во время работы "Сервер баз данных не обнаружен" причем для все пользователей, при этом подключится к серверу по RDP можно, но на сервер тоже не могу запустить 1С ошибка та же самая.

Может ли это быть ошибка релиза, или это проблемы сервера и сетевого окружения?

Буду благодарен за любые советы по диагностике и локализации проблемы

По теме из базы знаний

Ответы

Подписаться на ответы Инфостарт бот

Свернуть все

2. RustamZz 18.03.20 16:08 Сейчас в теме

(1) Сервер 1С не может соединиться с сервером PostgreSQL. Это может быть проблемы с виртуальной сетью или с самим PostgreSQL. Проверьте в этот момент отвечает ли с сервера 1С сервер PostgreSQL.

5. herfis 513 18.03.20 18:19 Сейчас в теме

(1)

но на сервер тоже не могу запустить 1С ошибка та же самая

Ну так попробуй в этот момент пингануть сервер БД с сервера 1С по имени/адресу которые прописаны в настройках базы.
Если все ок, попробуй пощупать с сервера 1С непосредственно постгрес хотя бы тем же pgadmin

13. user1378080 20.03.20 12:54 Сейчас в теме

(1)
работает в винде или в Linux ?

3. burgomister 59 18.03.20 16:12 Сейчас в теме

Давно уже отказались от PostgreSQL, увы. Больше проблем, чем плюсов.

4. Snark13 18.03.20 17:56 Сейчас в теме

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

6. Snark13 19.03.20 10:43 Сейчас в теме

Что ж проблема локализована, как не печально, но это Postgres. Осталось понять как с этим бороться

вот что есть в логах
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] ПОДСКАЗКА: Вы сможете переподключиться к базе данных и повторить вашу команду сию минуту.
2020-03-19 10:27:04.648 MSK [7100] КОНТЕКСТ: при изменении кортежа (6,5) в отношении "pg_statistic"

7. Snark13 19.03.20 12:03 Сейчас в теме

В дополнении
2020-03-19 11:50:52.520 MSK [5064][]СООБЩЕНИЕ: 00000: процесс сервера (PID 1468) был прерван исключением 0xC0000005
2020-03-19 11:50:52.520 MSK [5064][]ПОДРОБНОСТИ: Завершившийся процесс выполнял действие: SEL ECT 1 FR OM 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: завершение всех остальных активных серверных процессов
2020-03-19 11:50:52.520 MSK [5064][]ПОЛОЖЕНИЕ: HandleChildCrash, postmaster.c:3300

После этого начинается завершение всех процессов

8. herfis 513 19.03.20 18:06 Сейчас в теме

Первым делом я бы память протестировал.

9. Snark13 19.03.20 18:41 Сейчас в теме

С памятью идея была, но во первых эта виртуальная машина, которая полгода проработала без проблем, а во вторых - подняли еще один виртуальные сервер на другом хосте, и ошибка перетекла туда - так что железо отпадает.

Терзают меня смутные подозрения, что может быть какой-то запрос все дело портит. Осталось поймать ту базу в которой это происходит и уже там разбираться.

10. herfis 513 20.03.20 11:09 Сейчас в теме

(9) Да, железо отпадает. Тогда я бы подозревал разрушение системных таблиц.
Т.е. пытался сделать бэкап, потом загрузку бэкапа на "свежем" постгри и после этого ТиИ, чтобы убедиться что с самой базой все ОК.

11. herfis 513 20.03.20 11:10 Сейчас в теме

Если с серваком все ОК, то пользовательский запрос не может приводить к краху сервера. Да и падает на обращении к системной таблице.

12. herfis 513 20.03.20 11:13 Сейчас в теме

Ан нет. Гоню.
pg_catalog.pg_type - это системная таблица. Но базы а не сервака.
Тогда пробовать выгрузить БД в файл и загрузить обратно в новую базу.

14. Snark13 20.03.20 13:05 Сейчас в теме

И сервер 1С и Postgres на win.

С помощью логов Postgres и сервера 1С определил базу, запрос которой был первопричиной краха.
Сделал копию и загрузил ее в новую базу Postgres, так как когда загрузил копию, сделанную 1С, в существующую базу Postgres, то ошибка осталось, даже с учетом тестирования и исправления.

Сейчас все запущено и вроде работает, но как говориться осадок остался - все таки один запрос смог уранить весь сервер с кучей работающих баз.

15. herfis 513 20.03.20 16:08 Сейчас в теме

(14)

все таки один запрос смог уранить весь сервер с кучей работающих баз

Обычный запрос не мог. Каким-то образом покоцались системные таблицы базы. А это тоже сделать непросто. Был какой-то серьезный сбой, скорее всего аппаратный. Ну, для виртуалки "аппаратный". Причем простое power off к такому привести не могло. Если только в настройках постгри не отключена опция предварительной записи транзакций на диск. Такое иногда тоже делают "для скорости", если типа уверены в окружении (три раза ха).

16. Snark13 20.03.20 21:01 Сейчас в теме

Согласен, что первопричиной мог быть "аппаратный" сбой, но смущает, что при переносе на новый виртуальный сервер баз данных Postgres, только что установленный на другом хосте, с помощью средств Postgres (pg_dump/pg_restore) перенеслась и ошибка.

На старом сервере удаление базы и восстановление из копии 1С, и дальнейшее тестирование и исправление не помогло :(

Оставьте свое сообщение

E-mail: