引起这种问题的原因有如下几个：1. 网速不通2.网速过慢3.客户端与服务器端有防火墙，导致listener的返回包穿不过防火墙。

根据你的情况是第2种。解决办法为：在服务器端的listener.ora文件中指定：   CONNECT_TIMEOUT_ = 0

最后一种引起ORA-12535错误的原因是由于不正确的设置listener queue size或操作系统中的nofiles参数引起的，如果是这种原因引起的，解决方法如下：1. Increase listener queue size. 2. Increase nofiles value (ulimit -n )3. Restart the listener

4.windows系统的放火墙(关闭或将端口1521开通)

--------------------------------------------------------------------------

ora-12535 : TNS:operation timed out 客户穿越防火墙、路由器PING TNSPING都通SQLPLUS 报 ORA-12535错误：

分析： 防火墙/路由器IP地址转换 是关键1、metalink doc：http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=FOR&p_id=32766.996   随机端口的http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=52808.1    listener hang住2、CONNECT_TIMEOUT=0 trace 3、NT下应付这种随机端口的方法：use_shared_socket :http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=124140.1(How to configure USE_SHARED_SOCKET on Windows NT/2000)http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_id=66382.1&p_database_id=NOT(Firewalls, Windows NT and Redirections)第一种方法： set a Windows registry value USE_SHARED_SOCKET, put this registry key under your ORACLE registry:\\HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\HOME Create the key USE_SHARED_SOCKET and assign the value TRUE. After that you need to restart the Oracle service and also the Oracle listener, then it should work. One problem of this setting is if your listener is down, all the connections will be cut. This is different than Oracle on Unix platform works 第二种方法： 需要在MTS模式下(共享模式)Oracle默认是专用模式。 　　经试验发现，如果不在init文件中设参数的话，Oracle仍然会要求一个随机端口和 1521端口来共同通讯，只是这个随机端口，并不随客户端会话和登录的变化而变化，在 没有重启服务器时，是固定的。 　　(试验发现，在专用模式下，每次连接，oracle服务器会按+1方式，提供一个非 1521的端口。) 　　 　　所以，还需要在init.ora文件的最后加上一条参数： 　 　　 mts_dispatchers="(address=(protocol=tcp)(host=myoradb)(port=1521))(dispatchers=1)" 　　 　　这样才真正实现只用一个端口，穿过防火墙 successful configuration can be seen using the 'netstat -a' command from a Command Prompt    OR   Analyze a client trace by setting folloving parameters in the client SQLNET.ORA    TRACE_LEVEL_CLIENT= 16   TRACE_DIRECTORY_CLIENT =

本地模拟试验基本命令：netstat -an     查看本机通信情况lsnrctl status 查看监听器情况ping            查看本地网络tnsping ***     查看TNS解析sqlplus         查看客户端应用

试验一：将本地网络IP地址只允许通过TCP1521端口则本地C:\>ping liqPinging liq [192.168.1.50] with 32 bytes of data:Reply from 192.168.1.50: bytes=32 time<10ms TTL=128C:\>tnsping ora9iAttempting to contact (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = liq)(PORT = 1521))) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME =ora9i)))OK(40毫秒)而：SQL> conn system/liq    ***************采取操作系统认证可以进入数据库已连接。SQL> conn system/liq@ora9i ××××××× 走TNSNAME解析 就报错ERROR:ORA-12541: TNS: 没有监听器警告: 您不再连接到 ORACLE。SQL> conn system/liq已连接。SQL>分析：此时可以PING通，TNSPING也通，但是不能用SQLPLUS登陆 与ORA:12535错误问题类似

试验二：开放所有端口当然可以一路成功试验三：网络只允许TCP 1521通信 而添加键值USE_SHARED_SOCKET=TRUE到注册表中也可以了！！！！！！！

FROM ORALCE METALINKrandom port and redirectionfrom metalink doc: 66382.1On Windows NT, when a connect request comes in to the listener, the listener spawns an Oracle thread. This thread is a listening thread and is started on a wild-card address, meaning that the thread is listening for connections on the current IP address and an unused port number given to the thread by the networking software. The Oracle thread will contact the listener using IPC and inform the listener of its listening address, connection load, and some other status information. The listener sends back to the client a REDIRECT address. This tells the client to reconnect to the newly spawned Oracle thread. Since this Oracle thread is on a random port (a range of ports cannot be defined), the firewall will not let the connection throughTNS-12203

(i) The first way is to use a firewall that has a SQL*Net proxy built into      it.connect to proxy and pass connection to listener         2. send redirect to client         3. connect to redirected address via the proxy         4. oracle accepts the connection                             firewall                                ||     +------+      |client|                    ||                 |listener |(port=1521)     +------+ --------1------> proxy ----1------> +---------+       A    \                    /||\       |     \---------3-------/ || \-----3------> +---------+       |                         ||                 | oracle   |(port=xxxx)       +--------------4---------||-------4------- +---------+

(ii)USE_SHARED_SOCKET = TRUE     Place the parameter in the Windows registry under the following locations:     \\HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE (Relases 8.0) or     \\HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\HOME (Release 8i or newer)Restart the system for the parameter to take effect.Here's how USE_SHARED_SOCKET works. The listener binds and creates a       socket on the address specified in the "listener.ora" file.   On this       socket, there is a LISTEN state active that is used by the listener.        When a new connection comes in to the listener, the listener spawns an       Oracle thread on the listening port (i.e. 1521). This happens over and       over again so that you have a listener and several established       connections using port 1521. Pictorially this scenario would look like       this:                     +--------------------+                     |                                 |                     |      This square represents      |      a listening socket for      |                     |      port 1521.                  |                     |                     |      = oracle thread         |      = listener              |                     |                                 |                     +--------------------+*******************random portFinally, a very common question concerning the listener and port numbers is why different port numbers show up in the "listener.log" file.   What you areseeing is the client's source port and client's source IP address.   Here ishow this relates to your firewall:If I want to make a TCP connection to a server (say with TELNET), I need to create a socket. To create a socket, I need 4 pieces of information: a source IP and port, and a destination IP and port.   So, using TELNET as an example (the listening port for the TELNET process is 23 on the server):                source        destination               +-----------+---------------+         IP     |138.2.12.8 |185.45.67.53    |               +-----------+---------------+       port     |     xx      |      23         |               +-----------+---------------+Notice I have labeled the source port as 'xx'.   What happens is that the networking software on the client chooses at random, or in sequential order, a valid port (between 1024 and 65535) so the client can send and receive data. This is what you are seeing in the "listener.log" file.from metalink 124140.1:The net8 connection to a Windows NT/2000 database server normally redirects   the port number to a random number when a user process connects to a ORACLE   shadow process. It does not use the TCP/IP port sharing like on UNIX systems where the clients only need to know the TNS listener port. In order to make Oracle connection to work in a firewall environment, the customers had to get a firewall that has a SQL*Net proxy built in or   with the newest TCP/IP Socket implementation of Windows NT 4.0 (available with   Service Pack#3) and Windows 2000 this can now be handled by the use of the   parameter "USE_SHARED_SOCKET". From metalink 32766.996:Q: The thing still confuses me is since Oracle will pick up a random port upon handshake via default 1521 port, why do we only need to open 1521 to get sqlplus connect to Oracle, instead of opening a range of ports for subsequent random port's use? A:Actually the expected way is to open up a range of ports. Not sure how you are getting away with opening 1521 only. Because even if you open up 1521, the client connection will go through, but once it hits the listener this will fork a new process that will take a random port. this is where the problem resides. Again theoretically this is how it is supposed to work. Not sure if your firewall vendor had added some features that I am not aware of. Can you give us some details on the firewall you are using? And can you do COMPLETE communication when opening 1521? Here is more information In theory, it is possible under certain conditions to configure SQL*Net to pass through a firewall without a SQL*Net application proxy. The ability to do this depends on the nature of the firewall itself (not all firewalls support this), the configuration of the server, and the limitations of the operating system. Firewalls that employ packet filtering may, in general, be configured to allow SQL*Net traffic. Packet filters operate by blocking or allowing communication between machines or networks based on information contained in the IP packet headers. This information includes client and server IP addresses and destination IP port numbers. Note that packet filters themselves don't offer much security. In order to minimize the security risk to your server, configuring a packet filter to allow SQL*Net traffic should only be done if you can minimize the 'hole' in the firewall that you are opening up. Ideally, you would want to restrict incoming connections to a small number of named ports. For example, you might use one SQL*Net Listener only, listening on port 1521. Note that unless your firewall understands SQL*Net and can verify that the connection coming through to port 1521 really is SQL*Net, you are always taking a chance that the hole through your firewall may be co-opted and used for something other than SQL*Net. In some server configurations and some operating systems, you cannot easily limit port access in this manner. Systems running multi-threaded servers, pre-spawned servers, or ones that do not support port-sharing require port redirection. That is, while the incoming connection is attempted at port XXXX, for example, the port 'redirects' the incoming connection to a different port number, say YYYY. The 'redirected' port number may not be known in advance, meaning that in order to allow this type of connection, you'd have to open up the range of ports to which the connection could potentially be redirected. Opening multiple holes in a firewall gives your firewall the consistency of 'Swiss cheese': lots of holes, meaning lots of potential security breaches. Also see limitations of using Checkpoint's Firewall-1 with SQL*Net, below. You can, in theory, open up a hole for SQL*Net in some firewalls without using an SQL*Net application proxy. This is not supported in all configurations of the server, in all operating systems, or in all firewalls, and it is not 'secure.' For more in formation on how you can do this, talk to your firewall vendor Q:Does the COMPLETE communication mean tnsping, sqlplus or something else? Both tnsping and sqlplus are working once opening 1521. A: NO reply

潜在的危险：CONNECTIONS FAIL WITH ORA-12537 WHEN USE_SHARED_SOCKET IS SET IN 8.1.7BUG: 1566794