在上周五晚上通宵加班将一套10.2.0.5.0的Linux 虚拟机环境下的数据量为260GB 的双节点RAC数据库顺利迁移至一台物理机器的开发数据库后，这两天开发的同事反映说连不上物理机开发库了。

起初，我也没有太在意，的确是因为这两天公司内部网络不太正常，ping物理开发库延时比较严重，偶有timed out现象，就一直以为是网络的问题了。直到中午的时候，同事说网络基本正常了，用PL/SQL Developer客户端工具连数据库的时候报出Ora-12516的错误，这才引起了我的注意！

上Metalink查了一下，看了“Troubleshooting Guide TNS-12519 TNS-12516 ORA-12519 ORA-12516 [ID 552765.1]”的文章后，才知道了自己迁移数据库后粗心大意犯下的错误。原来的RAC数据库中每个实例中都将process初始化参数都设置了400，sessions=445，而现在是单台数据库对外提供服务，导致会话数不够用，最终导致的Ora-12516的错误！其实，对于这种开发库而言，公司的开发同事并不多，怎么可能导致445个会话还不够连接使用呢？其实，造成问题的最根本原因是开发人员的应用程序中的连接池配置的有问题，连接数配置过高导致的！！！！

找到了问题的基本原因后，就将process初始化参数从400改为600，进而sessions自动被置为665，transactions参数自动置为731。然后，重启数据库。

        在oracle数据库的初始化参数中，有一类参数是推倒参数，其中：

        sessions=1.1*processes+5,transactions=1.1*sessions.

这样，问题得到了基本的解决。

事后，又出现了一些不痛不痒的问题。

这不，年后简单记录下发生在这个春节前的种种问题，及解决问题的方法：

① 会话数不够用，导致Ora-12516的错误。解决方法，加大process初始化参数，或者通知修改应用程序中的连接数；

② 通过在数据库端配置profile来控制每个会话的活动时间，过期由数据库自动断开会话；

③ 通过使用共享服务器模式来控制数据库服务器端的进程资源；

④ 最头大的问题就是，有个开发的同事将自己PC机器的IP地址设置了同数据库服务器相同的IP地址，导致其他开发人员一直连接不上数据库！！！这个问题可不是第一次遇见，解决办法，协同网络管理员将数据库服务器IP绑定到MAC。

其实，这本来是去年春节前遇到的一则案例，后来由于太忙，赶着要回家，于是拖到了今天才发布出来！