Often, when it comes to the database, you may see separate networks configured for the following types of traffic:
Recently, one of the configurations that I was a part of took it a step further than that and had a few additional networks configured:
- Data Guard
- Private Non-Routed Network
One additional requirement was that a scan listener be present for each one of these networks. I wasn’t given the opportunity to set this up either so we had to trust that the other entity set all of the correct parameters. No big deal right?
Once all of the networks were configured and scan listeners were in place for each network, connectivity on each network was very erratic. Clients would connect at times and at other times they would not.
It wasn’t until we used a packet analyzer (Wireshark), that we really saw what was going on. Upon investigation, a colleague found that occasionally the scan listener would return the wrong VIP to the connecting client. Good news was that it was the SAME wrong VIP each time. But why was it doing this? The culprit ended up being incorrect / missing entries in the following parameters.
The Oracle documentation on this was not a ton of help either.
Upon investigation, we found that an entry for each local listener was present in the LOCAL_LISTENER parameter and each SCAN_LISTENER was present in the REMOTE_LISTENER parameter and LISTENER_NETWORKS parameter was blank. As it turns out, LOCAL_LISTENER and REMOTE_LISTENER should contain entries for those listeners present on the first network ONLY.
local_listener='(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=client-vip.example.com)(PORT=1534))(ADDRESS=(PROTOCOL=TCP)(HOST=vlan-vip.example.com)(PORT=1534)))' remote_listener='client-scan:1534','vlan-scan:1534' listener_networks=''
The LISTENER_NETWORKS parameter is responsible for registration of listeners for ALL other networks.
local_listener='(ADDRESS=(PROTOCOL=TCP)(HOST=client-vip.example.com)(PORT=1534))' remote_listener='client-scan:1534' listener_networks='((NAME=netVLAN)(LOCAL_LISTENER=(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=vlan-vip.example.com)(PORT=1534))))(REMOTE_LISTENER=vlan-scan:1534))'
Once these changes were made, the intermittent connection issues were gone and Wireshark confirmed that the listeners were returning the correct VIP for the network being requested.