有套數據庫環境一直報警無法連接，但立馬又報警恢復正常，查看了下alert日誌，大量如下信息：
Fatal NI connect error 12170.
VERSION INFORMATION:
TNS for Linux: Version 12.2.0.1.0 - Production
Oracle Bequeath NT Protocol Adapter for Linux: Version 12.2.0.1.0 - Production
TCP/IP NT Protocol Adapter for Linux: Version 12.2.0.1.0 - Production
Time: 08-OCT-2018 23:17:48
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
...
WARNING: inbound connection timed out (ORA-3136)
-----------------------------------------------------------------------------------
這個報錯信息很常見，一直以來都覺得是應用服務器和數據庫服務器之間存在防火牆，超時後將連接關閉導致的。
但這次的告警是這幾天剛出現的，並且該系統已經上線一年多了。最近在網絡、應用、數據庫端都沒有做過變更，所以懷疑存在其他問題。
-------------------------------------------------------------------------------------
在MOS上搜了下，找到一篇文檔2469518.1
問題描述與我報錯信息符合，給出解釋如下：
JDBC 11g and later connection establishment with databases use a connection mechanism (o5logon) that requires the use of random numbers. These numbers are typically generated by a special device (/dev/random). However, this random number generator relies on entropy in order to generate sufficiently random numbers. This entropy comes from things like mouse pointer movement and keyboard entry. When there is insufficient entropy, the random number generator will not return any numbers. When this happens, the o5logon used by the JDBC library stalls, and has to wait until sufficient entropy is available. This can cause connections to be reset or refused. On Linux boxes, this has been observed to result in the "connection reset" error.
大致意思jdbc 11g及以後的版本，oracle安全連接使用操作系統/dev/random產生的隨機數，但/dev/random依賴於系統中斷，當系統中斷不足的時候，則無法獲取隨機數，此時程序要麼掛起，要麼中斷。
故而，當系統中斷不足，/dev/random取不到隨機數，oracle建立連接失敗。
MOS給的解決方案：
1.The following java options have proven successful in these cases:
-Djava.security.egd=file:/dev/urandom and -Dsecurerandom.source=file:/dev/./random.
TNS timeout errors and ORA-3136 error you are experiencing point to /dev/random issue known to happen on Linux severs and causes Timeout exceptions. These settings are for the use /dev/urandom instead of using /dev/random which has the entropy fault.
2. Also, the server receives a valid client connection request but the client takes a long time to authenticate more than the default 60 seconds set by by the parameter SQLNET.INBOUND_CONNECT_TIMEOUT. Please see Document 465043.1Troubleshooting Guide ORA-3136: WARNING Inbound Connection Timed Out for details. Increasing this parameter provides more time for the authentication to complete.
3. As a workaround, change the security logging to write to file instead of sending it to the database (application change).
---------------------------------------------------------------------------------------
第一種方法可行性最好。
-------------------------------------
之前沒有關注過/dev/random和/dev/urandom，新知識了。