After deploying an Oracle Database Appliance, a standard set of production listeners are configured on bond0. This includes one listener on each of the virtual ip interfaces, and two SCAN listeners.
In my environment, I would very much like to have additional listeners on bond1. I use this as a management network, and find it convenient to let DBAs and operators run their tools over this network.
According to Oracle Support, there should not be any special considerations on ODA, and thus we can follow support note ID 1063571.1 just like we would with any other 11gR2 RAC infrastructure.
In my humble opinion, this particular support note isn’t too clear even if you have access to My Oracle Support, so I’ll describe the steps I used for my setup:
Production network on bond0 is 10.20.30.0/24
Management network on bond1 is 192.168.0.0/24
First out we need host file entries on both nodes for the new VIP interfaces:
/etc/hosts:
# VIP HOSTNAMES
10.20.30.42 oda1-vip.dolicapax.org oda1-vip
10.20.30.43 oda2-vip.dolicapax.org oda2-vip192.168.0.23 oda1m-vip.dolicapax.org oda1m-vip
192.168.0.24 oda2m-vip.dolicapax.org oda2m-vip
Next we add the virtual ip interfaces to CRS. The network resource (specified with the -k 2 option) should be create implicitly:
su – root
cd /u01/app/11.2.0.3/grid/bin/
./srvctl add vip -n oda1 -k 2 -A 192.168.0.23/255.255.255.0/bond1
./srvctl add vip -n oda2 -k 2 -A 192.168.0.24/255.255.255.0/bond1
We can verify that the network resource and the virtual ip interfaces have been created with crsctl:
[root@oda1 bin]# ./crsctl stat res -t |grep -E ‘net|vip’
ora.net1.network
ora.net2.network
ora.oda1.vip
ora.oda1m-vip.vip
ora.oda2.vip
ora.oda2m-vip.vip
ora.scan1.vip
ora.scan2.vip
The final step is to create the actual listener. Oracle reccomends that you do this with the network configuration assistant netca. The command must be run from the grid user.
roy@kayna:~$ ssh oda1 -l grid -X
grid@oda1’s password:
Last login: Tue Oct 23 22:15:41 2012 from 192.168.0.46
/usr/bin/xauth: creating new authority file /home/grid/.Xauthority
[grid@oda1 ~]$ netca
Just select Listener confguration and then Add and walk through the wizard, selecting the correct network resource (subnet) along the way. Note that netca sees the original listener on default port of 1521, and will not allow another on the same port. I went with a name of LISTENER_M and a port of 1522 for my configuration.
This will take care of both listener.ora and OCR configuration.
However, I really do want the new listener to be listening the default port of 1521. netca complains that another listener is already configured on this port, even though it’s not on the same interface. The workaround is to manually remove and recreate the listener with srvctl using the -s option.
su – grid
srvctl stop listener -l LISTENER_M
srvctl remove listener LISTENER_M
srvctl add listener -l LISTENER_M -s -p 1521 -k 2
srvctl start listener -l LISTENER_M
We’re all set, and can now see the new listener (along with the default listeners) on the correct interface and port using netstat.
[grid@oda1 ~]$ netstat -ln | grep 1521
tcp 0 0 192.168.0.23:1521 0.0.0.0:* LISTEN
tcp 0 0 10.20.30.32:1521 0.0.0.0:* LISTEN
tcp 0 0 10.20.30.30:1521 0.0.0.0:* LISTEN
tcp 0 0 10.20.30.34:1521 0.0.0.0:* LISTEN
[grid@oma1 ~]$ ssh oma2
[grid@oma2 ~]$ netstat -ln | grep 1521
tcp 0 0 192.168.0.24:1521 0.0.0.0:* LISTEN
tcp 0 0 10.20.30.33:1521 0.0.0.0:* LISTEN
tcp 0 0 10.20.30.31:1521 0.0.0.0:* LISTEN
tcp 0 0 10.20.30.35:1521 0.0.0.0:* LISTEN
or with lsnrctl
[grid@oda2 ~]$ lsnrctl status LISTENER_M
LSNRCTL for Linux: Version 11.2.0.3.0 – Production on 23-OCT-2012 22:47:00
Copyright (c) 1991, 2011, Oracle. All rights reserved.
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER_M)))
STATUS of the LISTENER
————————
Alias LISTENER_M
Version TNSLSNR for Linux: Version 11.2.0.3.0 – Production
Start Date 23-OCT-2012 22:36:49
Uptime 0 days 0 hr. 10 min. 13 sec
Trace Level off
Security ON: Local OS Authentication
SNMP OFF
Listener Parameter File /u01/app/11.2.0.3/grid/network/admin/listener.ora
Listener Log File /u01/app/11.2.0.3/grid/log/diag/tnslsnr/oda2/listener_m/alert/log.xml
Listening Endpoints Summary…
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=LISTENER_M)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=192.168.0.24)(PORT=1521)))
The listener supports no services
The command completed successfully
As you can see, the listener is up but supporting no services. Unless we want this to be a static listener, we need to tell the database to make it’s presence known.
We accomplish this by using the new LISTENER_NETWORKS parameter.
SQL> alter system set listener_networks = ‘((NAME=MGMT_NET)(LOCAL_LISTENER=oda1m-vip:1521)(REMOTE_LISTENER=oda2m-vip:1521))’ SID=’testdb1′ SCOPE=both;
System altered.
SQL> alter system set listener_networks = ‘((NAME=MGMT_NET)(LOCAL_LISTENER=oda2m-vip:1521)(REMOTE_LISTENER=oda1m-vip:1521))’ SID=’testdb2′ scope=both;
System altered.
A new look at the listener status will show that the instances are now properly registered:
Services Summary…
Service “TESTDB” has 2 instance(s).
Instance “TESTSB1”, status READY, has 1 handler(s) for this service…
Instance “TESTDB2”, status READY, has 1 handler(s) for this service…
The command completed successfully
