Коллеги, добрый день.
Есть сервер на базе windows 2000 advanced server с написанным уже несуществующим разработчиком windows-сервисом.
Есть другой сервер на базе windows 2000 advanced server с одним экземпляром БД Oracle 8.
Сервис при запуске открывает на БД 7 сессий, которые постоянно висят на базе, как правило в неактивном состоянии.
Cервис критичный для бизнеса.
Внести в него изменения не получится.

Проблема в том, что после смены ядра сети в организации полгода назад периодически (2 раза в неделю, раз в 2 недели) сервис начинает писать в своих логах, что не видит БД Oracle.
При этом сессии на БД продолжают висеть.
Помогает в этой ситуации остановка вручную windows-сервиса, убивание сессий на БД и повторный запуск сервиса.
При этом в журналах БД, системных журналах обоих серверов и журнале сервиса ничего внятного по проблеме не находим.
При остановке windows-сервиса как правило сессии на БД сами не уходят, и kill не всегда помогает, снимаем потоки через orakill.
Время на обоих серверах в порядке.
Сетевики бьют себя пятками в грудь, что дело не в смене ядра сети.

Прошу совета, что можно сделать для мониторинга источника данной проблемы.
Думаю организовать с сервера с windows-сервисом пару параллельных независимых от сервиса сессий на эту БД и еще какую-нибудь и проверить, что в этот момент будет с ними. Но суть в том, что на сервере постоянную авторизацию под какой-либо учетной записью лучше на оставлять. Каким образом это можно реализовать через планировщик заданий ОС?

Vadim Lejnin

1) В листенере перед отвалом пусто.
Размер 144 Мб.
2) Обычно сервис выдает только ORA-03114: not connected to Oracle.
Пару раз также была ошибка ORA-03113: end-of-file on communacation channel, но как правило без нее
3) В том то и дело, что не хотелось бы держать авторизованные сессии учетных записей на обоих этих серверах.
Вот и думаю, как выполнить такое подключение сценарием и планировщиком, чтобы потом в ней можно было выполнить еще и какие-либо команды в случае необходимости. Когда произойдет очередная проблема, не подгадаешь.

"переведут если что на VM"
Собственно, сервер БД виртуальный.

mefman
Юмор ценю, спасибо.
Приходится иметь дело с большим разнообразием систем, от NT до 2012, от 8 до 12 Oracle.

Alexey Zhidkov
Файервола нет.

Запустили в планировщике сценарий парсинга журнала сервиса, который в случае выявления ошибки запускает проверку коннекта к БД с проверкой доступности инстанса и вычиткой блокировок. Может поможет.

Можно подробнее про keepalive?

Нашли корень зла.
Битый патчкорд -> ошибки на порту сетевого оборудования -> потери пакетов на хосте виртуальной инфраструктуры -> проблемы у виртуальной машины сервера БД.