Service "SYS$SYS.KUPC$C_1_20140110224935.RAC" has 1 instance(s)

今早偶然发现数据库监听多了一个奇怪的service
RHEL 5.4 ，oracle 11gR2 rac

+++如下： 
[oracle@rac1 ~]$ lsnrctl status
LSNRCTL for Linux: Version 11.2.0.1.0 - Production on 11-JAN-2014 17:24:56
Copyright (c) 1991, 2009, Oracle.  All rights reserved.
。。。
。。。
Service "+ASM" has 1 instance(s).
  Instance "+ASM1", status READY, has 1 handler(s) for this service...
Service "SYS$SYS.KUPC$C_1_20140110224935.RAC" has 1 instance(s).
  Instance "rac1", status READY, has 1 handler(s) for this service...
Service "SYS$SYS.KUPC$S_1_20140110224935.RAC" has 1 instance(s).
  Instance "rac1", status READY, has 1 handler(s) for this service...
Service "rac" has 1 instance(s).
  Instance "rac1", status READY, has 1 handler(s) for this service...
Service "racXDB" has 1 instance(s).
  Instance "rac1", status READY, has 1 handler(s) for this service...
Service "racs1" has 1 instance(s).
  Instance "rac1", status READY, has 1 handler(s) for this service...
The command completed successfully

+++service "SYS$SYS.KUPC$S_1_20140110224935.RAC" has 1 instance(s).
刚看到这个，觉得很奇怪，查询资料，说是跟expdp有关
这让我想起了昨天确实在rac1 节点上导出过数据，但是由于导出过程出现故障，所以手工kill_job了expdp动作
也许这个正是因为昨天的expdp操作余留下来的，节点rac2上没有这个问题

SQL> show parameter name
NAME                                 TYPE                   VALUE
------------------------------------ ---------------------- ------------------------------
service_names                        string                 SYS$SYS.KUPC$C_1_2014011022493
                                                            5.RAC, racs1, SYS$SYS.KUPC$S_1
                                                            _20140110224935.RAC

+++检查昨天的alter日志：
ALTER SYSTEM SET service_names='racs1','SYS$SYS.KUPC$C_1_20140110224935.RAC' SCOPE=MEMORY SID='rac1';
ALTER SYSTEM SET service_names='SYS$SYS.KUPC$C_1_20140110224935.RAC','racs1','SYS$SYS.KUPC$S_1_20140110224935.RAC' SCOPE=MEMORY SID=
'rac1';
Fri Jan 10 22:49:37 2014
DM00 started with pid=49, OS id=15795, job SCOTT.SYS_EXPORT_SCHEMA_01
Fri Jan 10 22:49:40 2014
DW00 started with pid=50, OS id=15798, wid=1, job SCOTT.SYS_EXPORT_SCHEMA_01
Fri Jan 10 23:31:49 2014
Immediate Kill Session#: 57, Serial#: 418
Immediate Kill Session: sess: 0x5225bf58  OS pid: 15795
Sat Jan 11 00:15:22 2014
Suspending MMON slave action kewrmafsa_ for 82800 seconds

+++我们可以看出来，oracle在进行expdp之前，先改了service_names的值，然后才开始expdp
但是由于我手工kill了这个操作，导致oracle没有再把这个值恢复回去
正常情况下会自动执行ALTER SYSTEM SET service_names='racs1' SCOPE=MEMORY SID='rac1';操作

多出一个service_name并不会影响库的正常使用，但是看着不好看
我们手工执行一下ALTER SYSTEM SET service_names='racs1' SCOPE=MEMORY SID='rac1';去掉多余的service

SQL> ALTER SYSTEM SET service_names='racs1' SCOPE=MEMORY SID='rac1';

System altered.

SQL> set lines 120
SQL> show parameter service_name
NAME                                 TYPE                   VALUE
------------------------------------ ---------------------- ------------------------------
service_names                        string                 racs1
SQL> 
+++手工注册一下
SQL> alter system register;

System altered.

SQL> exit

Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,
Data Mining and Real Application Testing options
+++再次查看，已经恢复正常
[oracle@rac1 trace]$ lsnrctl status
LSNRCTL for Linux: Version 11.2.0.1.0 - Production on 11-JAN-2014 17:51:44
Copyright (c) 1991, 2009, Oracle.  All rights reserved.
Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521))
...
...
Services Summary...
Service "+ASM" has 1 instance(s).
  Instance "+ASM1", status READY, has 1 handler(s) for this service...
Service "rac" has 1 instance(s).
  Instance "rac1", status READY, has 1 handler(s) for this service...
Service "racXDB" has 1 instance(s).
  Instance "rac1", status READY, has 1 handler(s) for this service...
Service "racs1" has 1 instance(s).
  Instance "rac1", status READY, has 1 handler(s) for this service...
The command completed successfully