TNS-12535/12606 and ORA-3136 on Connection to Database (Doc ID 2313573.1)

今天遇到一问题 telnet 都是通的，但是两台数据库服务器还是无法 sqlplus 连接，最后发现两台服务器的 mtu 值不同，其中一台为 1500 一台为9000，

以前只是认为 telnet 端口就是没问题的，但是没想到还有 mtu 的限制。最后找到了如下的文档，将9000改到了1500 后恢复访问。网络一直都是我的薄弱环节。

In this Document

APPLIES TO:

Oracle Net Services - Version 12.1.0.2 to 12.2.0.1 [Release 12.1 to 12.2]
Information in this document applies to any platform.

SYMPTOMS

When trying to connect the database, client reporting the following Error:

ORA-28547: connection to server failed, probable Oracle Net admin error

The database alert log is reporting the error codes.

Fatal NI connect error 12170.

VERSION INFORMATION:
TNS for Linux: Version 12.1.0.2.0 - Production
Oracle Bequeath NT Protocol Adapter for Linux: Version 12.1.0.2.0 - Production
TCP/IP NT Protocol Adapter for Linux: Version 12.1.0.2.0 - Production
Time: 30-SEP-2017 19:46:10
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
nt OS err code: 0
Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=XXX.XXX.XXX.XXX)(PORT=50745))
Sat Sep 30 19:46:10 2017
WARNING: inbound connection timed out (ORA-3136)

CHANGES

None

CAUSE

As per per analysis we could see that the client is sending a connect packet and then waiting for the response approximately for 7 minutes and finally getting timed out.

The Oracle Net server trace shows the following:

==============================

[30-SEP-2017 19:45:22:079] nsbasic_bsd: 00 02 03 02 03 00 01 00 |........|
[30-SEP-2017 19:45:22:079] nsbasic_bsd: 00 00 00 |... |
[30-SEP-2017 19:45:22:079] nsbasic_bsd: exit (0)
[30-SEP-2017 19:45:22:079] nsbasic_brc: entry: oln/tot=0
[30-SEP-2017 19:45:22:079] nttfprd: entry
[30-SEP-2017 19:52:32:033] ntt2err: entry =================================> 7 Minute delay.
[30-SEP-2017 19:52:32:033] ntt2err: exit
[30-SEP-2017 19:52:32:033] nttfprd: exit
[30-SEP-2017 19:52:32:033] nserror: entry
[30-SEP-2017 19:52:32:033] nserror: nsres: id=0, op=68, ns=12535, ns2=12560; nt[0]=505, nt[1]=60, nt[2]=0; ora[0]=0, ora[1]=0, ora[2]=0
[30-SEP-2017 19:52:32:033] nsbasic_brc: exit: oln=0, dln=0, tot=0, rc=-1
[30-SEP-2017 19:52:32:033] nioqrc: wanted 1 got 0, type 0
[30-SEP-2017 19:52:32:033] nioqper: error from nioqrc
[30-SEP-2017 19:52:32:033] nioqper: ns main err code: 12535
[30-SEP-2017 19:52:32:033] nioqper: ns (2) err code: 12560
[30-SEP-2017 19:52:32:033] nioqper: nt main err code: 505
[30-SEP-2017 19:52:32:033] nioqper: nt (2) err code: 60
[30-SEP-2017 19:52:32:033] nioqper: nt OS err code: 0
[30-SEP-2017 19:52:32:033] nioqer: entry
[30-SEP-2017 19:52:32:033] nioqer: incoming err = 12151
[30-SEP-2017 19:52:32:033] nttaddr2bnd: entry
[30-SEP-2017 19:52:32:033] snlinGetNameInfo: entry
[30-SEP-2017 19:52:32:033] snlinGetNameInfo: exit
[30-SEP-2017 19:52:32:033] nttaddr2bnd: Resolved to xxx.yyy.zz.00
[30-SEP-2017 19:52:32:033] nttaddr2bnd: exit
[30-SEP-2017 19:52:32:033] nioqce: entry
[30-SEP-2017 19:52:32:033] nioqce: exit
[30-SEP-2017 19:52:32:033] nioqer: returning err = 3113

This was deemed to not be an Oracle*Net issue as the tracing indicates the issue was at the Network level.

As a test (and only a test - not a recommended solution), set a lower SDU value between Client and Database to reduce packet sizes.
If this works, then there is something at the Network level causing detainment of packets.
The most common cause, is a different MTU setting (again at the Network not Oracle level).

SOLUTION

This specific issue was fixed after the Systems Admin lowered the MTU size.

Network team determined MTU of 1500 (default) was too high, lowered the MTU to 1350 and the application is connecting as expected.

REFERENCES

NOTE:561429.1 - DNS Issue: Connections To Oracle 11g are Slow or Delayed
NOTE:274483.1 - The relation between MTU (Maximum Transmission Unit) and SDU (Session Data Unit)
NOTE:44694.1 - SQL*Net Packet Sizes (SDU & TDU Parameters)
NOTE:1302367.1 - Remote Oracle Net connections hang at Authentication point or end with ORA-3135