TNS-12547,TNS-12560,ORA-609

环境现象是CPU使用居高不下，异常多的LOCAL=NO连接。netstat -ant|grep CLOSE_WAIT能看到不少等待关闭的连接。redo切换频繁。

2个解决方法。

一：

数据库的INBOUND_CONNECT_TIMEOUT参数设置的默认时间60秒太短，导致的业务访问数据时间超过了默认时间，连接进程被kill掉，也就是opiodr aborting。
这种ORA-609错误是会被记录到alert文件中的，但是不会导致服务异常。

ORA 609的解释是
00609, 00000, "could not attach to incoming connection"
// *Cause:  Oracle process could not answer incoming connection
// *Action: If the situation described in the next error on the stack
//         can be corrected, do so; otherwise contact Oracle Support.

解决这类的问题初步的方式，需要主要的这是初步的方式就是增加参数INBOUND_CONNECT_TIMEOUT值，或是该参数值设置为0 ，0表示永不超时，但是设置为0会导致系统资源被独占从而带来系统负载压力。

在以下两个文件中，增加以下值

Sqlnet.ora: SQLNET.INBOUND_CONNECT_TIMEOUT=180
Listener.ora: INBOUND_CONNECT_TIMEOUT_listener_name=120

修改完成后，可以在lsnrctl中reload一下就可以，没必要重启监听
 

二：修改fast_start_parallel_rollback为false。

观察alert日志发现重做日志文件不断切换，分析应该是有较多的事务没有完成提交或者有较多没有提交的事务完成回滚。现在面临的问题是我们没有很多时间去等待所有的事务去完成回滚或提交。解决问题的思路就是如何尽快结束这些事务的回滚或提交。

　　1) 查看spfile文件中是否有fast_start_parallel_rollback参数的设置。如果没有显式设置，则该参数的默认值为low。修改该参数值为false

　　2) 将数据库启动到nomount状态：startup nomount

　　3) 修改改参数值：alter system set fast_start_parallel_rollback = FALSE scope=spfile

　　4) shutdown immediate关闭数据库

　　5) startup启动

　　6) 查看该参数是否生效：show parameter fast_start_parallel_rollback

　　7) 等待一段时间

　　8) shutdown immediate数据库可以关闭

　　分析：FAST_START_PARALLEL_ROLLBACK是用来控制事务并行回滚最大进程数的参数。该参数有三个可设值，low，high，false。当设置为false时并行回滚被禁止，由于禁止了并行回滚，在数据库关闭时，需要回滚的事务将被取消。

第二种方法参考连接：https://blog.csdn.net/csdn6538954/article/details/100385160