Фатальная ошибка подключения ni 12170 oracle что это такое

Обновлено: 25.06.2024

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

После того, как соединение с приложением было установлено, через некоторое время у него возникла проблема с разрывом соединения, что повлияло на их транзакции.

Часть первоначального расследования, приведенная ниже в журнале предупреждений и журнале прослушивания,

Фатальная ошибка подключения NI 12170.

TNS для Linux: версия 11.2.0.4.0 — рабочая версия

Адаптер протокола Oracle Bequeath NT для Linux: версия 11.2.0.4.0 — рабочая версия

Адаптер протокола TCP/IP NT для Linux: версия 11.2.0.4.0 — рабочая версия

Отслеживание не включено.

Структура ошибки Tns:

код основной ошибки: 12535

TNS-12535: TNS: время ожидания операции истекло

вторичный код ошибки: 12560

основной код ошибки: 505

TNS-00505: время ожидания операции истекло

Вторичный код ошибки: 110

Код ошибки операционной системы nt: 0

Адрес клиента: (АДРЕС=(ПРОТОКОЛ=tcp)(HOST=XX.XX.XX.XX)(PORT=XXXX))

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

Увидев указанные выше ошибки в журнале предупреждений, начал анализировать различные параметры, связанные с ORACLE TNS, и настройки ОС/брандмауэра.

Давайте разберемся с этими параметрами подробнее.

sqlnet.ora: SQLNET.INBOUND_CONNECT_TIMEOUT=600

SQLNET.EXPIRE_TIME= 5

Поддержка активности TCP на уровне операционной системы

SQLNET.INBOUND_CONNECT_TIMEOUT

Начиная с Oracle DB Server 10.2.0.1 и более поздних версий значение параметра SQLNET.INBOUND_CONNECT_TIMEOUT по умолчанию составляет 60 секунд, поэтому, если клиент не сможет пройти аутентификацию в течение 60 секунд, в журнале предупреждений появится предупреждение, и соединение с клиентом будет прервано. .

Чтобы понять причину этой проблемы, можно выполнить следующие проверки

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

<р>1. Проверьте, успешно ли и быстро ли установлено локальное подключение к серверу базы данных.

<р>2. Если локальные соединения работают быстро , проверьте сетевую задержку с помощью сетевого администратора.

<р>3. Проверьте, не ухудшилась ли производительность вашей базы данных.

<р>4. Проверьте журнал оповещений на наличие критических ошибок, например, ORA-600 или ORA-7445, и сначала устраните их.

Эти критические ошибки могли вызвать замедление работы сервера базы данных.

Часто для решения этой проблемы необходимо увеличить значение INBOUND CONNECT TIMEOUT как в прослушивателе, так и в базе данных. Обычно рекомендуется установить значение для базы данных (sqlnet.ora) немного выше, чем для прослушивателя (listener.ora). Процесс аутентификации более требователен к базе данных, чем к слушателю.

Как проверить, активен ли тайм-аут входящего трафика для прослушивателя и сервера базы данных:

Вы можете проверить, активен ли параметр, просто подключившись по telnet к порту прослушивателя.

$ телнет XXX.XX.XX.XX XXXX

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

SQLNET.EXPIRE_TIME=n — Обнаружение мертвого соединения

Где n – некоторое количество минут. Желательно ниже 10.

Если этот параметр включен, небольшой тестовый пакет размером 10 байт будет отправляться от узла к узлу через определенные промежутки времени. В нашем примере примерно через 5-минутные интервалы после постановки таймера на охрану будет отправляться пробный пакет до тех пор, пока таймер не будет снят с охраны. Это должно предотвратить прекращение простоя брандмауэром.

Установите этот параметр в файле sqlnet.ora.

По истечении времени таймера SQL*Net на сервере отправляет клиенту «пробный» пакет. (В случае связи с базой данных пунктом назначения ссылки является серверная часть соединения.) Зонд представляет собой пустой пакет SQL*Net и не представляет данные уровня SQL*Net в какой-либо форме, но создает данные. трафик по базовому протоколу.

Если клиентская часть соединения все еще активна, проверка отбрасывается, а механизм таймера сбрасывается. Если клиент завершил работу ненормально, сервер получит сообщение об ошибке из-за вызова отправки, отправленного для зонда, и SQL*Net на сервере даст сигнал операционной системе освободить ресурсы соединения.

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

У DCD есть два преимущества

<р>1. Если SQLNET.EXPIRE_TIME меньше тайм-аута простоя подключения FW, то брандмауэр будет рассматривать этот пакет как активность, и тайм-аут простоя (закрытие брандмауэра) никогда не произойдет, пока и клиентский, и серверный процессы не будут активны.

<р>2. Если значение SQLNET.EXPIRE_TIME (скажем, немного выше) превышает предел бездействия FW, то, как только произойдет отключение, СУБД узнает об этом и закроет соединение.

Проверка активности TCP

Есть ниже 3 параметра, связанных с TCP Keepalive ОС,

net.ipv4.tcp_keepalive_time = 300

net.ipv4.tcp_keepalive_probes = 3

net.ipv4.tcp_keepalive_intvl = 20

Вы можете включить параметр TCP KeepAlive на уровне операционной системы (ОС). После того, как опция поддержки активности TCP включена и настроена, небольшой тестовый пакет будет отправляться на другой конец через каждый предопределенный интервал бездействия, и он ожидает ACK от другого конца. И ACK будет возвращен только тогда, когда другой конец жив и доступен. Если ACK не возвращается, то после некоторой повторной попытки ОС закроет конечные точки и освободит выделенные для этого ресурсы. Приложение, которое прослушивает этот конкретный сокет, получит сообщение об ошибке, чтобы приложение могло предпринять необходимые действия при получении сигнала об ошибке от ОС.

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

Действия по настройке TCP KeepAlive зависят от конкретной операционной системы. Вам нужно будет обратиться к соответствующей документации по ОС.

TCP KeepAlive применим ко всем сетевым приложениям, работающим в данной операционной системе.

Есть 3 параметра, связанных с TCP keepalive операционной системы (это параметры Linux, но другие операционные системы имеют аналогичные параметры)

TCP_KEEPIDLE (количество времени до отправки первого пакета поддержки активности)

TCP_KEEPCNT (количество тестов для отправки)

TCP_KEEPINTVL (интервал между пакетами проверки активности)

Параметр sqlnet.ora SQLNET.EXPIRE_TIME теперь задает параметр сокета TCP_KEEPALIVE (такой же, как параметр ядра TCP_KEEPIDLE).

Если sqlnet.expire_time=1, то TCP_KEEPALIVE будет установлен на 60 секунд. Другим параметрам KEEPINTVL и KEEPCNT присваиваются значения 6 и 10 соответственно (что очень

разумный). Это означает, что для DCD можно установить как минимум 2 минуты.

Причина проблемы может заключаться в том, что соединение на самом деле простаивает или выполняется очень длинный фрагмент команд SQL. В ходе исследования было обнаружено, что иногда серверы не отправляют пакеты синхронизации/подтверждения даже после того, как клиент отправил слишком много пакетов синхронизации. Некоторые брандмауэры не работают должным образом с масштабированием окна TCP, что приводит к потере сетевой активности.

Установите приведенные ниже параметры, вы должны выбрать правильный номер в зависимости от поведения и требований вашего приложения.

В дополнение к вышеизложенному также установите для параметра TCS Keep active на уровне ОС соответствующее значение как на сервере приложения, так и на сервере базы данных. Например, в этом сценарии настройка на 4 часа работала эффективно.

Приведенное выше решение сработало успешно, и у команды разработчиков больше нет проблем с подключением.

Oracle Net Services — версии с 11.1.0.6 по 12.2.0.1 [выпуски с 11.1 по 12.2]
Oracle Database — Enterprise Edition — версии с 19.12.0.0.0 по 19.12.0.0.0 [выпуски 19]
Информация в этом документе относится к любой платформе.
TNS-12170, ORA-12170, TNS-12535, TNS-00505 alert.log

Симптомы

Вторичный код ошибки nt: 110 Мониторинг базы данных 11g Журнал(ы) предупреждений может отображать частые сообщения, связанные с тайм-аутом, такие как:

– В Oracle Solaris:

Фатальная ошибка подключения NI 12170.

ИНФОРМАЦИЯ О ВЕРСИИ:
TNS для Solaris: версия 11.2.0.1.0 — рабочая версия
Адаптер протокола Oracle Bequeath NT для Solaris: версия 11.2.0.1.0 — рабочая
TCP/IP NT Адаптер протокола для Solaris: версия 11.2.0.1.0 — производственная
Время: 22 января 2011 г., 21:48:23
Трассировка не включена.
Структура ошибки Tns:
основной код ошибки ns: 12535

TNS-12535: TNS: время ожидания операции истекло
ns вторичный код ошибки: 12560
nt основной код ошибки: 505

TNS-00505: время ожидания операции истекло
вторичный код ошибки nt: 145
код ошибки операционной системы nt: 0
Адрес клиента: (АДРЕС=(ПРОТОКОЛ=tcp)(HOST=xx. гггг.zz.abc)(PORT=1092))

---------
"Вторичный код ошибки nt" будет отличаться в зависимости от операционной системы.

Linux x86 или Linux x86-64: "вторичный код ошибки nt: 110"
Сервер HP-UX: "вторичный код ошибки nt: 238"
AIX: "вторичный код ошибки nt: 78"

Изменения

Никаких изменений не требуется, но, возможно, вы недавно обновили базу данных до версии 11g версии 1 или выше или установили новую базу данных Oracle11g.

Примечание. До версии 11gR1 те же самые «Фатальные ошибки подключения NI 12170» записывались в sqlnet.log

Причина

Для просмотра полной информации войдите в свою учетную запись My Oracle Support.

У вас нет учетной записи My Oracle Support? Нажмите, чтобы начать!

В этом документе

Симптомы

Изменения

Причина

Решение

Ссылки

My Oracle Support предоставляет клиентам доступ к более чем миллиону статей знаний и активному сообществу поддержки, состоящему из коллег и экспертов Oracle.

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

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

После работы с поставщиком следующие настройки решили проблему предыдущих проблем, и сообщения об ошибках больше не появлялись. Эти настройки необходимо согласовать с поставщиком.

Войдите в консоль weblogic:
Затем перейдите в консоль --> сервисы --> источники данных --> [DATASOURCENAME] --> Конфигурация --> пул соединений

подтвердите настройки по умолчанию для начальной, минимальной и максимальной емкости
начальная: 1
минимальная: 15
максимальная емкость: 1

время ожидания неактивного соединения = 30
снимите флажок Удалить зараженные соединения с включенным

Это изменяет количество секунд бездействия, после которых зарезервированные подключения будут принудительно возвращены в пул. Если установлено значение 0 (по умолчанию), эта функция отключена.
~~~

Основная причина

Это сообщение указывает на то, что у клиента истекло время ожидания при подключении к серверу.
Вторичный код ошибки сообщения nt: 110 переводится как (сетевой транспорт) для операционной системы Linux.

Этапы диагностики

Для получения дополнительной информации о настройке серверов Oracle Weblogic в качестве руководства можно использовать следующую ссылку, но только после дополнительной консультации с вашим поставщиком
Руководство по настройке Oracle

Это решение является частью программы ускоренной публикации Red Hat, предоставляющей огромную библиотеку решений, созданных инженерами Red Hat для поддержки наших клиентов. Чтобы дать вам необходимые знания, как только они станут доступны, эти статьи могут быть представлены в необработанном и неотредактированном виде.

Постоянный опыт работы с приложениями Oracle EBS, Exadata, RAC, ASM, RMAN, DataGuard, настройками производительности, ПО промежуточного слоя Fusion, Weblogic, SOA, Goldengate, UNIX, безопасностью, защитой и аудитом, устройствами для резервного копирования и восстановления, решениями и т. д. .

Среда, 20 августа 2014 г.

Удаление фатальной ошибки подключения NI 12170 из журнала предупреждений базы данных

В одной из наших производственных баз данных 11gR2 было так много записей о фатальной ошибке подключения NI 12170 + TNS-12535: TNS: время ожидания операции истекло + TNS-00505: время ожидания операции истекло (с разными портами), обнаруженные в обоих Файл журнала предупреждений об экземплярах RAC.

Проблема:

Фатальная ошибка подключения NI 12170.

ИНФОРМАЦИЯ О ВЕРСИИ:
TNS для Linux: Версия 11.2.0.3.0 - Производство
Адаптер протокола Oracle Bequeath NT для Linux: Версия 11.2.0.3.0 - Производство
Адаптер протокола TCP/IP NT для Linux: Версия 11.2.0.3.0 - Производство
Время: 20- AUG-2014 14:17:36
Трассировка не включена.
Структура ошибки Tns:
ns основной код ошибки: 12535

TNS-12535: TNS: время ожидания операции истекло
ns вторичный код ошибки: 12560
nt основной код ошибки: 505

TNS-00505: время ожидания операции истекло
nt вторичный код ошибки: 110
nt код ошибки ОС: 0
Адрес клиента: (ADDRESS= (ПРОТОКОЛ=tcp)(HOST=xxx.xxx.xxx.xxx)(PORT=44326))

Причина:

Одно и то же сообщение об ошибке повторялось почти целый день для каждого сервера приложений.

Наконец-то я нашел причину проблемы. Наша база данных находится за брандмауэром. Брандмауэр имеет значение «время простоя сеанса». Если соединение остается бездействующим в течение времени, превышающего значение «время простоя сеанса», оно разрывает соединения.

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

Решение/Временное решение:

1) Добавьте следующую строку в файл sqlnet.ora на сервере.

SQLNET.EXPIRE_TIME=10

В этой базе данных конфигурации каждые 10 минут проверяется работоспособность серверов приложений. Фактически это механизм определения устаревших соединений по базе данных. Поскольку он отправляет пакеты на серверы приложений каждые десять минут, соединения определяются брандмауэрами как активные и не разрываются.

**В установке, включающей GRID, этот параметр следует задать в файле RDBMS_HOME/network/admin/sqlnet.ora. Это будет расположение по умолчанию для параметров файла sqlnet.ora, на которые ссылается экземпляр.

2) Одним из способов минимизировать влияние является использование параметра SQLNET.INBOUND_CONNECT_TIMEOUT (по умолчанию 60 секунд на 10gR2 и 11g), но иногда этого значения недостаточно.

Oracle также упомянул о возникновении этой ошибки, если вы используете DB Console или Enterprise Manager для мониторинга своих баз данных, а агент em будет неоднократно пытаться подключиться к целевой базе данных, и, по статистике, некоторые из них завершатся ошибкой (частота будет зависеть от того, насколько загружена база данных). ваша система).

В большинстве случаев (конечно, для консоли DB и агента Enterprise Manager) приложение будет пытаться снова подключиться, и ему это удастся.

Читайте также: