Two RAC services of the same name in a GI cluster

Question

Grid Version : 11.2.0.3
Platform : RHEL 5.4
In our 11.2.0.3 GI cluster , we have DBs of version 11.2.0.3 and 11.2.0.2 running.
Only today I've realized that you can create two services of the same name in a cluster.
ORCL      db is of version 11.2.0.3
NATSUP db is of version 11.2.0.2
I managed to create a service named DNP_TST_02 on both DBs.
--- After env variables for 11.2.0.3 db Home
--- Creating DNP_TST_02 service in 11.2.0.3 DB
srvctl add service -d ORCL -s DNP_TST_02 -r ORCL1 -a ORCL2
srvctl start service -d ORCL -s DNP_TST_02
srvctl status service -d ORCL -s DNP_TST_02
-- Tested connectivity using
sqlplus tst_for_drop/[email protected]:1628/DNP_TST_02.hk.standardchartered.com
--- Creating DNP_TST_02 service in 11.2.0.2 DB
srvctl add service -d NATSUP -s DNP_TST_02 -r NATSUP1 -a NATSUP2
srvctl status service -d NATSUP -s DNP_TST_02
srvctl start service -d NATSUP -s DNP_TST_02
srvctl status service -d NATSUP -s DNP_TST_02
-- Tested connectivity
sqlplus tst_for_drop/[email protected]:1628/DNP_TST_02.hk.standardchartered.com
---But, wouldn't a service of the same name confuse the listener ?
If the user you are trying to connect exist in both DBs, should the listener/CRS will be more confused. Right ?
If the users exist in both DBs and have the same password, then it will be worse . Right ?
So, should be CRS be allowing two service of the same name in two DBs in one GI cluster ?

Answer 1

Hello, Garry - you can get exactly the same effect in a single instance environment. I've run this in two separate databases that happen to be on the same machine:SQL>  alter system set service_names=dup scope=memory;
System altered.
SQL> alter system register
  2  ;
System altered.
SQL> exit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
oracle@domU-12-31-39-0E-D5-A2:[/home/oracle]
$ lsnrctl status
LSNRCTL for Linux: Version 11.2.0.3.0 - Production on 08-JAN-2013 07:18:53
Copyright (c) 1991, 2011, Oracle.  All rights reserved.
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC1521)))
STATUS of the LISTENER
Alias                     LISTENER
Version                   TNSLSNR for Linux: Version 11.2.0.3.0 - Production
Start Date                07-JAN-2013 09:24:30
Uptime                    0 days 21 hr. 54 min. 23 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Parameter File   /u01/app/oracle/product/11.2.0/db_2/network/admin/listener.ora
Listener Log File         /u01/app/oracle/diag/tnslsnr/domU-12-31-39-0E-D5-A2/listener/alert/log.xml
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1521)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=domU-12-31-39-0E-D5-A2.compute-1.internal)(PORT=1521)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=domU-12-31-39-0E-D5-A2.compute-1.internal)(PORT=8080))(Presentation=HTTP)(Session=RAW))
Services Summary...
Service "DUP" has 2 instance(s).
  Instance "class", status READY, has 1 handler(s) for this service...
  Instance "orcl", status READY, has 1 handler(s) for this service...And yes, you get connected randonly through the usual connect time load balancing:$ sqlplus scott/tiger@domU-12-31-39-0E-D5-A2:1521/DUP
SQL*Plus: Release 11.2.0.3.0 Production on Tue Jan 8 07:28:50 2013
Copyright (c) 1982, 2011, Oracle.  All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> select name from v$database;
NAME
ORCL
SQL> !sqlplus scott/tiger@domU-12-31-39-0E-D5-A2:1521/DUP
SQL*Plus: Release 11.2.0.3.0 Production on Tue Jan 8 07:29:09 2013
Copyright (c) 1982, 2011, Oracle.  All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> select name from v$database;
NAME
CLASSI can see how it would be unavoidable in a single instance environment, but clusterware really shouldn't permit it. I think it is almost a bug, service names should be unique within a cluster.