一个拷贝操作导致的潜在监听类问题

最近为了统计一些服务器的监听使用情况，于是写了一个简单的脚本，在中控中执行，脚本逻辑很简单，也没有什么亮点。

脚本内容如下：

#check $1 is IP

base_dir=`pwd`

ssh $1 "ps -ef|grep smon|grep -v grep; ps -ef|grep tns|grep -v grep|grep -v netns" > $base_dir/tmp_checkdb.lst

echo '***DB instance as below***'

echo .

cat $base_dir/tmp_checkdb.lst|grep smon|grep -v grep|awk -Fsmon_ '{print $2}'

cat $base_dir/tmp_checkdb.lst|grep tns|grep -v grep|awk -Ftnslsnr '{print $2}'|sed 's/-inherit//g'

脚本的执行情况如下：

# sh checkdb.sh  10.127.133.xxx

***DB instance as below***

.

testdb

 listener_1532

 listener_1523

 listener_testdb_1525

 listener_testdb_1528

 listener_testdb_1529

 listener_testdb_1539

 listener_testdb_1535

 listener_1521

 listener_1522

看到这个结果能够基本得到一个整体的服务概况，这台服务器上有哪几个实例（包括ASM）,对应的监听端口有哪些，目前根据基本的规范，监听器后是带着相应的端口。

但是我看到某一台服务器的时候，突然发现了一个很奇怪的结果：

里面有一行的结果如下:

listener_1532 lsnrctl start listener_1522

看到这个结果着实让我有些摸不着头脑了，到底是我解析的问题还是本身的监听的问题，查看细节的信息。

系统级看到的进程情况如下：

$ ps -ef|grep tns

root        125      2  0 Apr26 ?        00:00:00 [netns]

oracle    15416  14816  0 16:26 pts/0    00:00:00 grep tns

oracle    56123      1  0 Jul14 ?        00:00:05 /U01/app/oracle/product/11.2.0.4/bin/tnslsnr listener_1532 lsnrctl start listener_1522 -inherit

oracle    56126      1  0 Jul14 ?        00:00:23 /U01/app/oracle/product/11.2.0.4/bin/tnslsnr listener_1522 -inherit

oracle    56131      1  0 Jul14 ?        00:00:23 /U01/app/oracle/product/11.2.0.4/bin/tnslsnr listener_testdb_1525 -inherit

。。。

可以看到这个监听确实够奇怪的，显示是1532，同时后面还跟了1522的端口，到底是开启了哪个端口呢。看到还有一个监听器是listener_1522,可以基本判断出1522是已经开通的，所以这个场景下开通的是1532端口。

因为这是一个在线业务系统，所以赶紧查看了一下当时的后台连接情况，没有发现什么异常，但是这种情况看起来非常别扭，就想好好纠正过来，简单评估了一下，发现这个端口的连接目前都是有一定的时间频度，使用lsnrctl查看监听器的状态，发现也没有问题，不过为了稳妥起见，还是考虑要把这个问题矫正过来。所以打算使用最快的方式，Kill -9杀掉这个监听的进程，然后迅速开启这个1532的监听器，评估之后就这么操作了，没有任何异常，而杀掉监听器对于原来的连接来说也没有什么影响，所以很快就搞定了这个问题，但是这个问题留给我的疑问是，怎么会出现这种情况呢，我决定复现一下这个问题，在测试之后发现原来这是一个潜在的操作问题。

lsnrctl start后面是跟一个监听器名，相应的监听器端口就可以成功开启，这个场景的问题略有不同，其实是执行了这样的操作：

 lsnrctl start LISTENER_1522 lsnrctl start listener_1521

这样一来，我们可以看出，原来lsnrctl没有校验后面的几个参数，简直就是无视了那些参数，这个做得确实不大合理啊。而这个问题的出现其实在从文本拷贝命令的时候如果拷贝不当，很容易出现这种串行的情况，也对我们手工操作敲响了警钟。这些看起来影响不大的细节很重要，稍有不慎就会影响大局，细节决定成败，就是这个道理。