Назад | Перейти на главную страницу

TNS-12535: TNS: тайм-аут операции - Oracle DB

Я вижу много запросов от сервера доступа к данным .Net, у которого время ожидания истекло. Это кажется совершенно случайным, не имеющим отношения к данным или блокировкам данных. Например, истекло время ожидания следующего запроса! 

 SELECT NULL FROM DUAL

Системные журналы показывают, что когда это произошло, ЦП был на 20%, память 42%, диск 3%. Что происходит?

Версия базы данных 10.2.0.3.0 на HPUX. Драйвер ODP - 2.111.6.20 (драйвер 11g)

Я проверил sqlnet.log и обнаружил большое количество этих сообщений об ошибках:

***********************************************************************
Fatal NI connect error 12170.

  VERSION INFORMATION:
        TNS for HPUX: Version 10.2.0.3.0 - Production
        Oracle Bequeath NT Protocol Adapter for HPUX: Version 10.2.0.3.0 - Production
        TCP/IP NT Protocol Adapter for HPUX: Version 10.2.0.3.0 - Production
  Time: 29-JUN-2009 06:42:04
  Tracing not turned on.
  Tns error struct:
    ns main err code: 12535
    TNS-12535: TNS:operation timed out
    ns secondary err code: 12606
    nt main err code: 0
    nt secondary err code: 0

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

  • Как разрешаются псевдонимы TNS? Вы используете локальный файл tnsnames.ora?

  • Предполагая, что вы используете локальный файл tnsnames.ora, используется ли в TNS-псевдониме базы данных IP-адрес или имя хоста? Использование IP-адреса устраняет необходимость попадания в DNS, поэтому, возможно, стоит попробовать это, если проблема в том, что ваш DNS-сервер ненадолго сходит с ума.

  • Вы также можете попробовать настроить прослушиватель резервного копирования и добавить параметр аварийного переключения к псевдониму TNS. Если проблема в том, что сеть икает и теряет пакеты от клиента к слушателю случайным образом, наличие опции аварийного переключения, которую можно попробовать, может решить подавляющее большинство проблем без необходимости выяснять, какая часть сети работает нестабильно. Конечно, это предполагает, что проблема устраняется достаточно быстро, чтобы следующая попытка подключения была успешной, но это вполне может быть разумным предположением. Если добавление слушателя резервного копирования решает проблему, вы можете быть почти уверены, что это проблема сети.

Я обнаружил, что отключение пула соединений более надежно. Я столкнулся с несколькими ситуациями, подобными описанным вами.

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

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

Если вы собираетесь использовать пул, я прочитал рекомендации, что вы должны выполнить команду alter для сеанса. (Нет, я не знаю хорошего. Oracle не уточнил в руководстве)

Брэд

У меня возникла эта проблема, когда выполнялись следующие условия: - Клиент JDBC работал на машине с IP ZZ.ZZ.ZZ.ZZ - Сервер базы данных имел два сетевых адаптера - один с IP XX.XX.XX.XX, а другой с YY. YY.YY.YY - URL-адрес клиента JDBC указывал на IP XX.XX.XX.XX, порт 1521 - Используя таблицу маршрутизации, клиент ZZ.ZZ.ZZ.ZZ смог достичь XX.XX.XX.XX - The по умолчанию "LISTENER" прослушивал порт 1521 YY.YY.YY.YY (имя хоста преобразуется в этот IP-адрес) - параметр LOCAL_LISTENER в SPFILE был NULL - то есть он никогда не устанавливался

Я решил эту проблему, выполнив следующие действия: - Остановил прослушиватель (lsnrctl stop) - Изменен LISTENER.ORA для прослушивания XX.XX.XX.XX (вместо имени хоста по умолчанию YY.YY.YY.YY) - Добавлена ​​запись в TNSNAMES.ORA для установки локального слушателя (LISTENER = (...)), по сути, копии записи, используемой в LISTENER.ORA) - Добавлен параметр LOCAL_LISTENER = LISTENER в spfile (ALTER SYSTEM SET ... SCOPE = SPFILE ) - перезапустил LISTENER (lsnrctl start) - перезапустил базу данных

На самом деле информации недостаточно, чтобы найти решение, но вот несколько вещей, которые можно попробовать.

Можете ли вы воспроизвести это вне приложения? Вы когда-нибудь видели неудачи с tnsping? Можете ли вы надежно пинговать сервер?

Приложение выполняет несколько подключений параллельно? Есть ли ограничения на количество подключений?

Что насчет сети - есть ли брандмауэр между приложением и БД?

Хотя это лечит симптом, а не какое-либо заболевание сетевого стека, вы можете попробовать увеличить inbound_connect_timeout, чтобы увидеть, исчезнет ли проблема.

Чтобы проверить, что вы сейчас используете, вызовите LSNRCTL на хосте базы данных и введите команду:

показать inbound_connect_timeout

Вы должны изменить это в файлах sqlnet.ora и listener.ora вашего хоста db:

sqlnet.ora: SQLNET.INBOUND_CONNECT_TIMEOUT = 100 (при условии, что 100 больше вашего текущего тайм-аута)

listener.ora: INBOUND_CONNECT_TIMEOUT_yourLIstenerNameGoesHere = 100

Также проверьте свой брандмауэр. Входящий порт 1521 на сервере базы данных должен быть открыт (если вы подключаетесь к серверу БД с другого сервера).

Мне только что удалось решить эту проблему, я понял, что если вы работаете на DHCP-сервере, убедитесь, что ваш файл хоста имеет текущий правильный IP-адрес, C:\windows\system32\drivers\etc\host (откройте его с помощью блокнота), и это решит вашу проблему.

Дополнительные советы: пожалуйста, проверьте настройки брандмауэра вашего сервера / ПК. В некоторых операционных системах Windows, например Vista / Win7 / Win Server; брандмауэр включен для сетевых компьютеров SOHO. Обязательно проверьте все сетевые группы частные / офисные / общедоступные. Затем остановите службу брандмауэра и проверьте соединение.