ora-03114和ora-12592

现状：
1.cmd窗口，plsql连接正常.
2.plsqldeveloper 连接数据库正常，执行select 命令报如下错误：
ora-03114 not connect to oracle ,ora-12592 TNS:bad packet
3.plsqldeveloper 上执行 select * from table_name 卡在初始话，直接卡死。
故障排除：
内网正常使用，其他网络环境连入后报如上错误。又见 ora-12592,初步考虑外网到内网的这部分出现问题。经与信息中心沟通，防火墙设置了IP报警把该IP禁掉了，去除该规则。现状情况消失。

关于ORA-12592：
The error 12592 means that the information provided was not acceptable to the TWO-TASK layer. It can occur if the data itself is not valid OR if the packet is in fact corrupt from the Oracle Net (SQL*Net) layer.
Now normally if the packet was corrupt, the Oracle Net layer will report the error prior to sending the information to the TWO-TASK layer. But it has been reported in the past that it can get to the two task layer before it reports the issue.

The error itself occurs in the layer of the database responsible for data conversions. The odd thing here is the layer AFTER the network layer is reporting a network problem. This can occur for a number of reasons:

1. The query itself causes the failure.
   Meaning the query is incorrectly specified. This can be tracked if the dumps occur repeatedly and all appear to occur on the same type of select statements.

2. There is a process failure(either client/server process).
   If the application hung on the front end client and sent incomplete data to the
   server process. This is the hardest to track because we never know what the client was doing when errors dump on the server side.

3. There is an intermittent loss of communication at the network level.
   Meaning a packet of information is not delivered. Most often occurs when larger queries take place and only partial data reaches the server process. Two-task tries to perform the data conversion yet information is missing. This is also extremely difficult to track because the only real option is SQL*Net tracing from both perspectives in order to find out what was occurring when the error occurred. Meaning do we see underlying TCP or Winsock errors if windows clients are involved. If so then those can likely cause the issues with packet delivery.

Therefore finding out what caused it usually happens after it occurs more often and repeatedly in order to determine the actual cause. Normal tracing and logging does not provide enough information to diagnose the issue. It has nothing to do with the node being rebuilt its more the nature of the error itself that require a lot of pre-planning and tracing to narrow down the possible causes.