某日，本人接到客户的一个电话，需要到现场解决一个问题。客户的电话就是命令，于是放下手中的活，急忙赶往客户现场。到达客户现场后，客户反应本地的一个应用程序隔一段时间就报错，同时客户传来了一张报错的图片，如下所示：
从上图来看，客户端的应用程序报错信息是ORA-12560或者TNS-12560错误，通过oerr命令：
得知该错误是协议适配器错误，既然是网络相关的错误，就统统地收集了数据库的监听器日志、sqlnet.log文件以及数据库的alert日志文件，然后依次查看这些文件都没有发现有用的线索。此时陷入了僵局。
客户反映该应用程序不通过tns访问数据库，是通过beq访问的数据库。也就是应用程序不走网络监听访问数据库，而是通过进程间通信访问数据库，这样性能更高。
日志中没有线索，就到OracleSupport网站上查吧，查了半天，发现ORA-12560错误相关的问题都是发生在Windows平台上的，只有一两篇与UNIX环境有关，其中一篇 Creating Inside An Linux/UnixProcess Huge Number (500 and higher) Of Connections Against Database Fails WithNetwork Errors ORA-12157 Or ORA-12560 (文档 ID 563237.1)介绍的是FD_FILESIZE限制了进程打开的文件描述符，在AIX平台下的限制是65536,解决该问题需要安装补丁，因临近假期，数据库打补丁也不现实，只好作罢，此时又限入了僵局，头疼啊。
后来一想，如果是该问题的话，早该报错啦，也不会平稳的运行三年吧。看来这个文档也解决不了问题啊，既然文档中提到了资源限制的问题，那就查一查应用程序属主的资源限制吧，检查结果如下：
看到这些有点感觉了，一个小应用程序32MB内存应该足够用了，说明内存问题不大，那就剩下nofiles打开的文件数这块有点门路了。于是想办法查查该应用程序打开的文件数吧，由于AIX平台没有安装lsof工具，生产环境安装该工具也不允许，那就拿procfiles工具查一下，这个命令的用法挻简单procfiles+应用程序进程的ID（pid）即可查看该进程打开的文件数，加上-n参数即可显示打开的文件名，于是通过procfiles –n pid查询了进程打开的文件数，结果如下
从上图可以看到进程号为2139056，应用程序的命令行为svi start，当前打开的文件描述符的限制为20000。当时该命令显示打开的文件描述符有652个左右。过了一会儿再次查询居然达到900多个，照这样的速度下去，文件描述符一定会达到20000的限制，当达到20000的限制后，应用程序连接数据库的时候也需要打开文件句柄才能够与数据库进行通信，此时由于资源限制，无法打开句柄与数据库通信，就报了一个奇怪的错误12560 TNS:protocol adapter error。
好啦，原因找到了，就是大量打开的文件描述符，达到了资源限制，无法与数据库通信导致的。那么大量打开的文件是什么文件或者什么类型的文件呢，从上图来看，打开的文件是dev 65535，65535，在/dev目录下也不是设备为65535,65535的文件，好在procfiles命令的输出中提示了打开的文件类型为FIFO，这不就是先进先出的管道文件吗。
把这个发现告知应用程序的开发人员后，开发人员查看应用程序版本库后，得知是前一段时间生产环境的应用程序增加了一个任务，在任务中有popen，没有增加pclose函数，具体代码如下：
上述代码中，读取的文件内容到变量sLine中，当sLine的长度为0时，直接返回SUCCESS，而没有pclose关闭文件句柄的操作。在555~556行之间添加一行pclose(fd)问题即可解决。修改后的代码如下：
修改后，通过一系列的编译、链接操作后，生成新的应用程序文件，替换到生产环境中去，启动新的应用程序 ，经过一段时间，通过procfiles命令，查看应用程序打开的文件句柄，发现只有3个打开的文件句柄，至此ORA-12560问题解决。
欢迎扫码关注 “子衿技术联盟”
2）投稿数量较多的作者可获赠礼品。
3）定期从关注的用户中抽取3名幸运关注用户，这3名幸运用户可获赠礼品。
技术干货文章随时欢迎向“子衿技术团队”订阅号投稿。
投稿邮箱：zjjs_team@163.com
