在rac+dataguard的环境中，为了减少应用宕机时间及改动，提高业务的可用性，要求jdbc客户端配置failover。同时为了很好地做应用分割，又不能load balance。
即在第一个实例不行时，去偿试第二个实例，两个实例都不行时，去偿试data guard。这样的目的看起来简单，其实有些细小的地方值的注意。
下面是一个配置的例子：
[@more@]jdbc:oracle:thin:@(description=
(ADDRESS_LIST =
(LOAD_BALANCE=OFF)(FAILOVER=ON)
(ADDRESS = (PROTOCOL = TCP)(HOST = x)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = y)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = z)(PORT = 1521))
)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = aaaa)
(failover_mode=(type=select)(method=basic))
)
)
其中host x和host y是rac的两个instance的service ip
z是data guard的ip地址。
这种配置在，应用在第一个实例连不上的情况下（包括主机宕掉；监听宕掉；实例宕掉但监听不宕掉三种情况）会去偿试第二个实例，第二个实例也连不上的情况下会去偿试第三个。
这里有几点需要注意：
1。为了达到实例宕掉，但监听不宕的情况下也行，监听需要全部是动态注册的，不允许静态配置的service name。这个理由很明显。因为动态注册的话，当instance宕掉后，其service name就会从监听中消失，此时应用才会去偿试第二个IP地址。如果有静态配置的话，则由于监听是可以接受客户端的请求，将不会去偿试第二个IP地址，而是报出oracle not available的错误。
2.data guard的监听配置两个，平时启着1526端口，用于归档日志的传输，当需要切到data guard时，才将1521端口起来。这样会防止某些情况下，应用连接到data guard上面来。
3.不能设置remote_listener参数，否则会发生监听层面的load balance。同时在配置中需要将load_balance设为no或false，以防止发生client 层面的load balance。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/100091/viewspace-917160/ ，如需转载，请注明出处，否则将追究法律责任。
