ANBOB™

也是以前遇到的案例，今天有时间整理记录一下，一套10.2.0.5 RAC ON HPUX, 前做时间Disable LB 参数调整时把remote_listener=”， 随后几天发现listener.log 空间增速异常的快，当时看了下里面多是service_update的信息， 查看top进程，也发现了pmon 进程一直是top 1,使用 cpu 100%， 开始以为是用户新建连接多，负载高，pmon进程向listener 注册load信息频繁了些，但是后来发现一直保护这样的状态，而且有时tsnping 延时比较大，所以判断应该是pmon进程出了问题。

# alert log 中 记录不久前刚做的以下操作

SQL> ALTER SYSTEM SET remote_listener='' SCOPE=BOTH;

# listener log

#tail -f  anbob_anbobdbb.log
07-JAN-2015 14:51:18 * service_update * anbob1 * 0
07-JAN-2015 14:51:18 * service_update * anbob1 * 0
07-JAN-2015 14:51:18 * service_update * anbob1 * 0
07-JAN-2015 14:51:18 * service_update * anbob1 * 0
07-JAN-2015 14:51:18 * service_update * anbob1 * 0
07-JAN-2015 14:51:18 * service_update * anbob1 * 0
07-JAN-2015 14:51:18 * service_update * anbob1 * 0
07-JAN-2015 14:51:18 * service_update * anbob1 * 0
07-JAN-2015 14:51:18 * service_update * anbob1 * 0
07-JAN-2015 14:51:18 * service_update * anbob1 * 0
07-JAN-2015 14:51:19 * service_update * anbob1 * 0
07-JAN-2015 14:51:19 * service_update * anbob1 * 0
07-JAN-2015 14:51:19 * service_update * anbob1 * 0

# fgrep "07-JAN-2015 13:" anbob_anbobdbb.log |fgrep "service_update" |awk '{print $1 " " $2}' |awk -F: '{print $1 ":" $2 }' |sort |uniq -c
15735 07-JAN-2015 13:00
16233 07-JAN-2015 13:01
16401 07-JAN-2015 13:02
16632 07-JAN-2015 13:03
16674 07-JAN-2015 13:04
16506 07-JAN-2015 13:05
16632 07-JAN-2015 13:06
16632 07-JAN-2015 13:07
16603 07-JAN-2015 13:08
16620 07-JAN-2015 13:09
16400 07-JAN-2015 13:10
16842 07-JAN-2015 13:11
16779 07-JAN-2015 13:12
16758 07-JAN-2015 13:13
16821 07-JAN-2015 13:14
16653 07-JAN-2015 13:15
16548 07-JAN-2015 13:16
16548 07-JAN-2015 13:17
16527 07-JAN-2015 13:18
...

# fgrep "07-JAN-2015 13:" anbob_anbobdbb.log  |fgrep "establish" |awk '{print $1 " " $2}' |awk -F: '{print $1 ":" $2 }' |sort |uniq -c

  70 07-JAN-2015 13:00
  17 07-JAN-2015 13:01
  16 07-JAN-2015 13:02
  11 07-JAN-2015 13:03
  11 07-JAN-2015 13:04
  28 07-JAN-2015 13:05
  10 07-JAN-2015 13:06
   5 07-JAN-2015 13:07
  16 07-JAN-2015 13:08
  12 07-JAN-2015 13:09
  10 07-JAN-2015 13:10
  19 07-JAN-2015 13:11
  10 07-JAN-2015 13:12
  11 07-JAN-2015 13:13
  10 07-JAN-2015 13:14
  26 07-JAN-2015 13:15
  20 07-JAN-2015 13:16
...

TIP:
从监听日志中可以看到连接请求每份钟不过20左右， 但是service_update 每分钟高达16000左右， 当时忘记收集pmon 的信息。

MOS 中有note 记录非常的像，但是版本号是11.1， 不过也不排除10.2.0.5 上发生，因为这两版本发行的很近。
After REMOTE_LISTENER change, excessive CPU seen for TNS listener process (文档 ID 982068.1)
Symptoms
After altering the value of the parameter REMOTE_LISTENER, excessive CPU is seen for the TNS listener process (TNSLSNR) and the listener.log file grows rapidly.
Alert log confirms the REMOTE_LISTENER parameter in the SPFILE was altered.
Listener.log shows continuous service_update triggered from PMON to the TNS listener, 100’s per second.
REMOTE_LISTENER had been set to null twice

Cause
Bug 9235880Alter of REMOTE_LISTENER parameter causes service update spinn

Solution
Bug is being worked on by development.
Do not set REMOTE_LISTENER to Null if already Null
Workarounds
If REMOTE_LISTENER is required to by Null, set to value before setting to Null
ALTER SYSTEM SET remote_listener=’example.com’ SCOPE=BOTH;
ALTER SYSTEM SET remote_listener=” SCOPE=BOTH;
Or set to a false value
ALTER SYSTEM SET remote_listener=’example2.com’ SCOPE=BOTH;

Note:
那就尝试配置一个false value
1, 先在tnsnames.ora增加 test 别名 ,指向一个不存在的ip和服务名
2，修改remote_listener=test
ALTER SYSTEM SET remote_listener=’test’ SCOPE=BOTH sid=’anbob1′;
ALTER SYSTEM SET remote_listener=’test’ SCOPE=BOTH sid=’anbob2′;

随后发现listener.log里的service_update 立及恢复了正常，pmon 进程也从top 20 cpu 进程中消失， 问题得以解决。