记一次ArcGis sql写空间数据耗时超长问题

问题背景

一系统采用了采用arcgis产品处理空间数据，数据存储在Oracle数据库；

数据库操作系统 

Red Hat Enterprise Linux Server release 5.7 (Tikanga)

Linux localhost.localdomain 2.6.18-274.el5 #1 SMP Fri Jul 8 17:36:59 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux

数据库

Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production

问题现象：

sql 写空间数据，耗时超长。同时ADDM报告中也报告了该问题。

具体为第一次执行很慢，第二次执行很快，但是退出连接，再次连接上，第一次执行任然很慢，达到84秒。

在分析这个问题过程中，同时发现ssh 连接也很慢

注：这些现象看似不相关，到后面排查出问题后，才发现实际是有联系。

问题分析过程

一、联系esri官方支持人员

他听说数据库版本是11.2.0.3，直接要求我们升级数据库。

因为arcgis 官方文档确实是要求11.2.0.4 。（注：最开始数据库是11.2.0.3，多种原因导致安装了此版本，安装完毕后，我查阅了esri官方文档要求是11.2.0.4，同时出于麻烦和认为版本上差异不大，因此没坚持官方要求）

别无它法，只能升级数据库。

二、升级数据库后

升级完毕后，发现任然很慢，并且每次都是84秒左右。同时，直接在数据库上执行也同样。

此时，再次咨询esri支持人员，直接得出结论说是数据库问题，与gis软件无关。

由于是放假期间，暂时联系不上其它技术支持人员，只能尝试自己分析解决。

1、原理分析

在Oracle数据库层面，Oracle允许调用外部函数，即动态链接库中函数，前提是要配置extproc，11g版本是通过配置extproc.ora文件。

在gis层面，使用sql操作空间数据，需依赖 arcgis 提供的动态链接库文件，linux上位libst_shapelib.so。

当执行sql时，Oracle的监听器会产生一个进程，此进程会调用对应外部库函数，然后返回结果给数据库，数据库再返回给用户。

默认情况下，Oracle是每一个会话产生一个进程，会话退出后，此进程也就退出。

这也就是解释了第二次执行快的原因，因为第一次已经加载了，后面自然就快了，同时也解释了，退出后再次登录执行有变慢。

但任然无法分析到第一次慢的原因。

同过 大量的google 百度搜索，找到同样问题的案例，可惜没有解决办法。

2、查阅Oracle资料 配置MTA

通过搜索，在Oracle 官方站上，有对extproc的介绍，同时Oracle也表明，在默认情况下，如果存在大量外部函数调用，会性能低下（通过上述的原理介绍，可以理解，因为每一个会话都新建和销毁，肯定是消耗资源和低性能的）。

因此Oracle提供MTA解决方案：即多线程代理，有点类似线程池的概念。

尝试此方案，此过程略（参考官方文档，也是云里雾里，不过还好，Oracle资源文档够丰富，因此配置成功）

实施上述方案后，马上验证，确实很快，第一次执行只需3-4秒，非常高兴，然而，当退出后，再次连接执行，却报错了。看样子又遇到一个坑了，进过尝试，发现关闭代理，再打开，第一次又可以执行，但问题依旧，第二次执行报错，就这样，这个方案也不行了。

此时夜已深，遂停止研究，回家休息。

3、发现linux开启selinux

第二天继续分析，怀疑库文件有异常，因此重新拷贝了文件后问题依旧。在拷贝文件的时候，发现arcgis安装目录中居然还存在一个同名但不在官方说明的路径中库文件，且文件大小稍小，拷贝此文件后，问题依旧，偶尔还会出现失败。

想到我司还有其他系统使用另外版本的库文件，但版本较低，此时，死马当活马医了，同时也想验证是否是新的库文件是否存在bug。拷贝库文件后，发现直接报错，且报错与selinux 相关。随即查询发现，此服务器开启selinux。

准备关闭selinux，但印象中，以前某个环境中关闭后，重启系统无法启动，需要修改引导。但此机器已在机房，放假期间难于进入，同时用户也在使用系统，随放弃关闭。

此时，又过去半天时间了，同时也反馈给老总，联系其它技术人员（esri或Oracle）。

4、linux 利器strace

晚饭后，休息一会儿，此问题未解决，心中不爽。突然想起linux中有strace进行系统调用跟踪。马上打开电脑，学习了解linux相关工具和用法，准备开始跟踪分析。此时，才发现，这个进程是动态产生的，遂对lisener进程进行跟踪，没发现有用信息。要是间接产生该进程就好了，即㐓跟踪了。

此时使用sqlplus 直接连接数据库，然后随手看了一下系统进程，居然extproc进程有了。此时直接使用命令进行进程跟踪

strace -t -f -p 8479

8479 为进程ID

然后马上执行sql

发现有不断的超时信息，仔细阅读，发现问题所在，它进行dns解析，但这个dns服务器是连不上的，所以系统在等待网络超时，问题发现了，马上看dns 配置，果然错误，这个ip已经无法连通。

马上注释掉，然后再次执行sql，时间只用了0.5秒。

经过多次验证，确认问题解决。

此时又快23点了，但内心异常兴奋，问题终于解决了。

同时，ssh 在关闭掉gssapiauthentication 后，连接也是一瞬间。

一个简单的错误，导致一堆问题。

基础系统和软件的安装和配置还是不能交给无计算机素质的人处理，他们大多数只会下一步下一步，有可能会整出很多问题。

同时庆幸linux有strace，同时有多了一个案例推介选择linux作为服务器系统了。