Adding an additional listener to ODA

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
Management network on bond1 is

First out we need host file entries on both nodes for the new VIP interfaces:


# VIP HOSTNAMES oda1-vip oda2-vip oda1m-vip 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/
./srvctl add vip -n oda1 -k 2 -A
./srvctl add vip -n oda2 -k 2 -A

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’

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
/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* LISTEN
tcp 0 0* LISTEN
tcp 0 0* LISTEN
tcp 0 0* LISTEN
[grid@oma1 ~]$ ssh oma2
[grid@oma2 ~]$ netstat -ln | grep 1521
tcp 0 0* LISTEN 
tcp 0 0* LISTEN
tcp 0 0* LISTEN
tcp 0 0* LISTEN

or with lsnrctl

[grid@oda2 ~]$ lsnrctl status LISTENER_M

LSNRCTL for Linux: Version – Production on 23-OCT-2012 22:47:00

Copyright (c) 1991, 2011, Oracle. All rights reserved.

Version TNSLSNR for Linux: Version – 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
Listener Parameter File /u01/app/
Listener Log File /u01/app/
Listening Endpoints Summary…
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



This entry was posted in ODA, Oracle, Technical and tagged , , , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *