在某些环境下，运行11.2版本的RAC数据库的服务器上，连接了多个public网络，那么就会有如下的需求：

1. 给其他的，或者说是新的public网络增加新的VIP地址。
2. 在新的public网络上增加SCAN VIP.
3. 在新的VIP地址上配置监听
4. 在新的SCAN VIP地址上配置监听

实际上从11.2版本开始，grid infrastructure（以下可能会简写为GI）就是一个完整的clusterware，不仅仅是用于数据库，也可以用作应用软件的高可用性。上述的4个需求中，第1个是毫无疑问需要的；第2个需求对运行在grid infrastructure上的应用是必要的；第3个需求在运行在grid infrastructure上的数据库来说是必要的；第4个需求，是针对数据库的，这个需求有点难度，因为在一套grid infrastructure中只能允许有一个SCAN LISTENER的存在，由于可以不通过SCAN IP而是直接通过VIP地址连接数据库，所以这个新的SCAN监听可以不需要，但是为了完整，我们可以用变通的方法来实现。

下面我们用一个实例来演示如何实现上述的所有需求。

先简单介绍一下用于演示的环境：11.2.0.1 grid infrastructure for linux 32bit，共2个节点，节点名是xty3和xty4，没有使用DNS（实际上在有DNS的环境下，也不太可能会有第2个public network），所以下面的演示是以没有DNS来配置的。Grid Infrastructure用的是oracle用户安装的（实际生产建议用单独的grid用户），而RDBMS软件也是用oracle安装的。目前的private network是192.168.153.0，对应的网卡设备名是en1，public network是192.168.0.0，对应的网卡设备名是en0，打算新增加的public network是192.168.76.0，对应的网卡设备名是en2。

先看看/etc/hosts文件的内容：

第1步，配置好新的public network的IP地址和网络路由。注意新的public network IP地址配好后，注意配置好网络路由。

第2步，在所有的节点上编辑/etc/hosts文件，增加如下内容：

192.168.76.134和192.168.76.144是两个节点上新的public network的public ip，192.168.76.135和192.168.76.145是相对应的VIP地址，而192.168.76.155则是准备要在新的public network上增加的SCAN IP。而xty-cluster-svip2则是新增的SCAN名字。

第3步，增加新的public network上的vip地址，这一步比较简单，用root用户执行下面的命令:

在上述命令中，-n参数后面跟的是节点名(hostname)； -k后面的参数表示第几个网络，这里是2，表示第2个public network。-A后面就是VIP地址的属性了，格式为"VIP地址名/子网/网卡设备名"。

然后用crsctl来检查，vip资源已经存在：

ora.net2.network，ora.xty3-vip2.vip,ora.xty4-vip2.vip都是新增的资源。然后使用下面的命令启动新增的VIP：

使用ifconfig 命令也可以确认IP地址已经附加到了新增的public network上，即en2上。所以在这里，新增public network上的VIP配置成功。

第4步，我们来实现第3个需求，也就是在VIP地址上增加监听，这个步骤也很简单，用GI的用户(这个环境是oracle)执行下面的命令：

启动并检查新增加的监听：

可以看到，监听LISTENER_N2增加成功。增加监听也可以使用netca图形界面操作，但还是命令行操作快捷。不过从上面的输出可以看到，新的public
network上的监听并没有监听到相对应的public固定IP。实际上他们监听hostname对应的IP地址。这是由BUG
8678541引起，在11.2.0.2及以上版本中已经修复。

第5步，我们来实现第2个需求，也就是增加SCAN IP，实际上在GI中，只能有一个SCAN，所以新增加的“SCAN IP”，实际上应称为“Application IP”，用两种方法，先介绍简单的，用root命令执行：

然后查看并启动资源：

使用ifconfig命令可以确认IP地址已经加到新的public network上了，由于这个是类似”SCAN IP“的地址，只能在一个节点上起。我们可以用下面的命令来调整这个IP到另一个节点上：

这个实现”SCAN IP“功能的application ip，不属于VIP，也不属于SCAN，因此这个资源是srvctl不能管理的。

下面介绍用第2种方法来实现新的public network上的"SCAN IP"。
把上面建好的资源xty-cluster-svip2停掉并删除：

然后执行下面的命令生成现有的SCAN IP的属性：

接着手工修改一下/tmp/1.txt文件，下面列出修改的部分：

然后配置SCAN并启动:

注意第2种方法使用的SCAN VIP资源的名字跟第1种方法不一样，在实际使用中，可以根据需要选择即可。不过注意在第2种方法中不要用ora.scan1_n2.vip这样的名字，否则srvctl查看这个资源时会出错。
看上去srvctl显示的结果有点异常，只有一个SCAN
Name，是新加的那个。不过至少可以用srvctl看到了，并且这也是可以理解的，因为目前就只能支持一个SCAN
Name，在本文仅处于研究的目的，所以这种方法不建议使用于生产，建议使用上面的第1种方法。

到目前为止，新的public network上的SCAN已经增加成功。

第6步，在新配的SCAN VIP上配置一个SCAN LISTENER。注意不能使用srvctl add
listener命令来配置，因为这种方式实际上是在所有的节点上都加了可同时启动的监听，需要增加的是scan listener。不过srvctl
add scan_listener是不会成功的，因为它会检测到在1521端口上已经有了SCAN
Listener，即使是在高版本的GI中，这个命令增加了-k 参数指定network，也是会报错的。因此只能使用类似上面第2种增加SCAN
VIP的方法来增加新的SCAN Listener，不过这次需要用GI的安装用户（此环境是oracle用户）来执行操作：

修改/tmp/2.txt文件，修改的行如下：

然后配置SCAN Listener并启动：

可以看到新增的SCAN Listener成功在节点xty4上启动，当然在之前的操作步骤中，新的SCAN VIP即N2_SCAN2是启动到了xty4上，所以这个监听也会在xty4上。

我们把新的SCAN VIP调整到节点xty3上：

至此所有的操作已经完成。然后重启一下所有节点的crs，验证一下重启后是否正常。在关闭第1个节点的crs之后，第2个节点上顺利接管了所有的VIP地址，并且所有的SCAN
Listener也运行到了节点2上。然后重启两个节点的crs后，一切看起来比较正常。唯一的不足是由于BUG
8678541引起的问题，使新的public network的VIP地址上的监听，监听到了错误的IP地址上。

以上的操作全部是针对Grid Infrastructure，不过在数据库上，还需要调整参数LISTENER_NETWORKS，而不能使用local_listener和remote_listener参数。这个参数的设置，举例如下：

实际上Grid Infrastructure已经是一个完整的clusterware，完全可以通过自定义的脚本来增加自己想要的资源，以实现高可用性。
本文参考了来自于MOS的文档《How to Configure A Second Listener on a Separate Network in 11.2 Grid Infrastructure [ID 1063571.1]》