一个拷贝操作导致的潜在监听类问题(r9笔记第70天)

最近为了统计一些服务器的监听使用情况，于是写了一个简单的脚本，在中控中执行，脚本逻辑很简单，也没有什么亮点。 脚本内容如下： #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}' echo . echo '***DB instance as below***' echo . 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 . ***DB instance as below*** 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没有校验后面的几个参数，简直就是无视了那些参数，这个做得确实不大合理啊。而这个问题的出现其实在从文本拷贝命令的时候如果拷贝不当，很容易出现这种串行的情况，也对我们手工操作敲响了警钟。这些看起来影响不大的细节很重要，稍有不慎就会影响大局，细节决定成败，就是这个道理。