客户的应用维护同事找了过来：“ 我们的数据库应该是出问题了，我们的批量任务跑了好几次，好像都没跑过去，就一直挂起在那里，没法继续下去了，是不是要重启一下数据库看看 ？”

批量任务跑不下去了，都到了需要重启的阶段了？？？一了解才知道，问题已经出现了有一段时间了，各种分析也没有给出相关结论，最后认为是数据库出现了异常，可能需要重启数据库才能解决； 重启数据库可不是小动作，需要好好评估了。

出现问题的这个系统是一个分析系统，它需要接收很多其他系统的数据，然后使用 impdp 工具将数据导入到数据库中，接下来再做一系列的聚合分析操作；而目前被卡住的步骤实际上是 impdp 的导入操作；

当然，我们在问题查到这里的时候，也会再多看一眼，看看操作系统层面的 impdp 进程到底在干什么；

可以看到，虽然 impdp 命令的日志显示已经导入完成了，但是 impdp 命令没有退出，而且其在数据库端的服务器进程也还没有退出；

如图显示对应 impdp 的数据库服务器进程，它的 program 中包含 udi 字样（如果是 expdp 这里是 ude ），它是负责创建与销毁 datapump 任务；

但是从数据库中看，这个会话还在，只不过这里它的状态是 inactive ，并非处于被阻塞状态，而 inactive 的状态已经持续了将近十几分钟了，也就是日志文件中导入完成到当前的时间；

进程没有正常退出，首先想到的是所有的进程都没法正常退出问题吗？？显然不是，数据库目前还在正常运行，正常的登入登出都没有问题；那么是 datapump 进程在退出时会出现异常吗？？我们在问题时段测试导入导出同样都是没有问题的；是 dump 文件的问题吗？？显然也不是，毕竟日志文件已经显示导出完成了，此时完全不需要 dump 文件了；

这个时候我们不妨看看，客户端进程和服务器进程在操作系统上的状态如何 ：

如上图，其中服务器进程（ 20906220 ）并当前并没有系统调用，而客户端进程（ 8323430 ）则在调用 write 函数，似乎在写什么消息；而反复调用 procstack 8323430 我们看到其调用的 stack 函数都是一样的，这样似乎意味着 impdp 进程无法完成一个写消息的操作；抑或者是因为操作系统的进程已经处于异常状态了？

问题在哪呢？不妨思考一下？接下来该如何分析呢？

前面我们 impdp 的实质工作都做完的情况下，它需要写什么消息呢？

我们来简单的看一下一个导入操作的过程 ：

如上，在操作系统层面指向 impdp 命令，我们指定了 logfile ，但是执行过程中， impdp 仍然会输出相关信息到我们的终端屏幕上；

我们再来看问题系统的 impdp 调用关系 ：

很显然， impdp 命令并不是终端也不是 shell 脚本调用的，而是通过 java 程序调用的，作为终端需要接收 impdp 的输出并打印在屏幕上，那作为 java 程序呢，它会不会去处理这些 impdp 的输出呢？

对于开发的答复，我们需要验证两点 ：

不过在这里我们还是多做了一步测试，大致测试内容如下 ：

从上图能说明什么呢？对于一般的命令或者程序，如果没有报错，那么它的输出我们通常认为会输出到标准输出流，只有出现了异常信息才会输出到错误输出流， 从这里看，我们发现 impdp 命令的输出都打到了错误输出流中 ；如果应用代码中只处理了标准输出流，而没有处理错误输出流，那么我们前面的怀疑就不无道理了 ；

其实，我们需要理解的一点是，如果 java 程序接收了错误流却没有处理， java 对于这些信息是不是会有缓存机制呢？缓存的大小是否有限制呢？是否以往并没有超出缓存的大小，而今天的这个导入的输出数据量已经超出了缓存的大小了呢？

我们简单对比了一下导出日志文件的大小（错误流输出的内容其实与 impdp logfile 的内容是一致的），发现当前出现问题的这个 impdp 的日志文件较以往都要大一些，很显然，日志文件的大小与导入的数据量并没有关系，而是与导入的表和分区的个数相关；而这个导入操作，主要是因为分区数过多而出现了挂起的操作 ；

解释完上面的信息，虽然开发的同事还是将信将疑，我们也只能通过将原来处理标准输出流的部分改成处理错误输出流了？可是现在无法修改 java 代码来解决这个问题；

从正确的处理流程上，其实还是需要改写代码，毕竟代码逻辑里还是需要处理 impdp 的相关输出的，不过如果我们了解到代码获取这些信息只是为了判断导入有没有报错的话，我们只要人工确认导入没有报错，那么绕过这个处理步骤也是可以的；

那么怎么处理呢？首先这里当然不是说直接不调用 java 程序，直接手动导入，毕竟 java 代码中在导入前后还会有一系列复杂的处理流程；我们再仔细看看 impdp 的调用关系 ：

在这里 impdp 的命令是由 java 直接调用起来的，前面提出因为导入命令的错误输出流的数据量过大导致的 ，那么我们是不是可以在这将标准输出流和错误输出流都重定向到其他地方，让 java 程序接收到的错误输出流为空或者极少，就不存在这个问题了 ；

修改完配置文件后，停止 java 程序， kill 相关进程，清理已导入的相关表之后，再次执行 java 程序，导入顺利完成，至此，问题得以解决，后续需要开发处理的，就是将原来对标准输出流的操作改为对错误输出流的操作即可 ；

OK，我们先梳理一下我们遇到的问题是什么，是如何一步一步分析下来的 ：

这个 CASE 处理完后，由于并没有拿到对应的应用代码，也就没能及时重现该问题；不过，最近我又遇到了同样类似的问题，开发同样是通过 java 代码调起脚本，进行 sqlldr 操作，而且在接收了 shell 脚本的标准输出流后，没能及时处理，导致 sqlldr 操作挂起，同样通过 procstack 查看进程堆栈，可以发现进程一直在写消息无法完成 ；

我首先开发那里拿到了相应的 java 测试代码 ：

Here we go!!!

①  准备 test.sh 脚本：

② 传入参数 ， java 代码不断读取（消费）掉接收到的标准输出信息，代码能正常执行：

③ 传入参数 1 ， java 只接收标准输出信息，而不消费掉，那么代码将挂起：

④ 再调整 test.sh ，让其标准输出数据量足够少

⑤ 再执行 java 代码，即使传入的是参数 1 ，因为接收缓冲区足够接收完也能正常执行：

本文转载于中亦安图