一、问题描述

今天，在某客户现场进行巡检，发现有一个系统在进行sqlplus / as sysdba登录的时候特别缓慢。多次测试，最长时间可以达到近10s才能成功登录；
此时，对主机的cpu、内存、io以及网络等参数进行查看，发现使用率均不高，远远没有达到瓶颈，且在登录之前和登录之后，所有操作均非常顺滑，没有丝毫卡顿。
因此，判断该系统就是在sqlplus登录的时候才可能出现卡顿。

由于客户的业务并未反馈使用有问题，所以当时仅将该问题记录到日常错误处理日志中。

但是过了几天后，突然客户的业务使用人员说，他们的某功能经常出现连接超时问题。这个时候，我就很肯定业务也受到了sqlplus登录缓慢所带来的影响。

于是专门翻出这个问题进行进一步的分析和排查。

二、问题分析过程

在之前，其实也遇到过很多次sqlplus登录缓慢的问题，而造成该问题的原因就是客户使用了dns进行ip解析。sqlplus在登录的时候会解析dns，而在解析这一步耗费的时间较长，从而影响了sqlplus登录过程锁消耗的时间。

所以，本次就先入为主，查看是否在服务器环境中存在dns的配置：

cat /etc/resolv.conf

# Generated by NetworkManager

可以发现，主机上并没有dns配置，所以造成sqlplus登录缓慢的常见原因也不是这个造成的。

那么，我们则需要进行进一步的原因排查。

首先，我们需要了解到，针对于oracle数据库的异常排查有一些很有用的方式，比如oradebug、event分析、hanganalyze、strace等等，只有我们选对了异常排查方式，才能够事半功倍。

而对于sqlplus登录缓慢的问题，由于起初不知道是因为数据库原因造成，还是因为命令调用原因造成，所以我们可以考虑选择hanganalyze或者strace的方式进行排查。

针对本次异常，首先对数据库进行了hanganalyze分析，但是分析出的结果并未显示出有阻塞链。所以，问题应该处在sqlplus命令调用原因。此时，我们就可以用strace的方式进行分析了：

strace -T -tt -o /tmp/strace_sqlplus_local.txt sqlplus / as sysdba

通过以上命令，可以生成一个sqlplus命令在执行期间，对linux做了那些调用的文件，通过该文件，我们则可以看到在哪个过程调用比较慢。

通过对生成的文件进行查看分析，发现在以下这一步骤调用时间出现异常：

可以发现此时在该步骤调用的时间有7秒多。

所以，此时我们能确定到问题点在什么地方，但是是什么原因造成的这个地方调用缓慢呢？我们可以看到其中有NTP0的字样，所以当时也怀疑是否与ntp服务有关。

进一步，我对ntp的相关服务进行检查，发现在该服务器上并没有任何ntp的配置，而且ntp服务也都没有开启。

分析到这里，也是有点迷惑了，这一步到底是在做什么？为什么会导致这么慢？此时我也有点无从下手了，还好有公司二线专家，请教了二线专家后，让我在strace中在加入-Fr参数，更近一步的去fork调用的子进程。

strace -T -tt -Fr -o /tmp/strace_sqlplus_local.txt sqlplus / as sysdba

可以看到，在这里有一段mmap()函数的调用耗费的时间比较长，基本上在4s左右（这里可能和上面的时间不匹配，主要是在分析的时候生成了多次，时间不问题）。

而经过查询，发现mmap函数主要是linux下内存映射到文件的一种方法(具体的该函数的内容和功能，我没有详细研究),因此可以猜测，sqlplus登录缓慢的问题，可能出现在内存映射上。

于是再进一步，对oracle的内存分配以及相关的内存参数进行查看，最终发现了一个参数:pre_page_sga，该参数在当前环境中设置的为true，而该参数默认为false。

三、问题原因定位

这个参数有什么作用呢？从官网和其他blog中，查到这个参数的作用如下：
在oracle实例启动时，只会在物理内存中载入sga的各个内存的最小的大小（以粒度为单位），而剩余的sga只会在虚拟内存中分配。只有当进程touch到相应的page时，才会置换到物理内存中。

当参数设置为TRUE时，不仅在实例启动时，需要touch所有的SGA页，并且由于每个oracle进程都会访问SGA区，所以每当一个新进程启动时（在Dedicated Server方式中，每个会话都会启动一个Oracle进程），都会touch一遍该进程需要访问的所有页。

通过以上描述，我们可以知道如果将改参数设置为true的时候，每次我们进行sqlplus登录的时候，实际上都会生成一个oracle进程，而此时改进程会touch一边所有需要访问的内存页。当需要访问的内存页很大的时候，可能就会产生缓慢的情况。

四、问题解决

后面我也建议客户将改参数改为false，在客户修改、重启后进行测试，发现sqlplus登录缓慢问题解决。再次通过strace生成sqlplus的跟踪文件可以发现，此时在NTP0的地方，效率变得非常高了：

五、总结

本次问题是一个常见问题，但是不是一个常见原因导致，一个简单的sqlplus登录缓慢问题，造成原因也很多，从跟踪日志中来看包括dns、内存、adump日志过多、读取glogin.sql等等。这个文章的目的，其实更多的是提供了一种遇到类似问题的分析思路。