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