关于 lb 的一些实验

关注

转载最新推荐文章于 2026-06-14 00:18:43 发布 326 阅读 AI 写同款· GEO 优化 ›

今天看到一个比较有意思的事情，就是在 rac 中，如果我们为了实现减少 cache fusion 的负担（通常，rac 性能问题，很大程度上，是因为 cache fusion 引起的），而对应用实行隔离，也就是，不同的应用只让它在不同的节点运行，这样，就能减少 cache fusion 的负担，那么，这里就碰到问题了：

如果我们在 tnanames.ora 中，不实现 load_balance 的话，那么如果服务端设置了 remote_listener （服务端的 lb，也就是说，服务端会根据每个节点的 cpu 负担和连接数来判断是否将客户端连接放到相应的节点上）的话，会不会导致连接去了其它的节点呢？

--编者注：看了相关的资料， remote_listener 设置服务端的 lb，服务器并不会根据 cpu 的负担去选择 cpu 负担小的那个节点。Cpu 负担重，只会加快 pmon 进程加快更新 LISTENER 的情况。因为一般情况下，在 cpu 负担比较重的时候，pmon 会每隔 1 分钟就去更新 listener 的情况，这样，就能更好得实现服务端的 lb，而负担小时，有可能 10 分钟才更新一次。

在我的测试中，是不会出现的

Oracle 版本: 10.2.0.4.0，two nodes rac

Os : linux as5

客户端 tnanames.ora 配置：

racdb1 =

(DESCRIPTION =

(ADDRESS_LIST =

(ADDRESS = (PROTOCOL = TCP)(HOST = rac1-vip)(PORT = 1521))

)

(CONNECT_DATA =

(SERVER = DEDICATED)

(sid = RACDB1)

)

服务端：remote_listener 两个节点都配置了对方的 listener

实验1：client 中不配置 lb，那remote_listener 会不会在服务端中实现 lb

在 session 1 中，连接 racdb1 ，并且做大数据量的 insert

Session1:

Sql>insertinto test_a as select * from test_a; ---超过 100W，不断insert

接着，开不同的 session ，去连接 racdb1 ，试试，remote_listener 会不会起作用

实验结果是，remote_listener 不起作用，不会实现服务端的 lb， session 只会去连接 racdb1

实验2：client 中配置了 lb，那 remote_listener 会不会根据节点繁忙程度去实现lb

racdb =

(DESCRIPTION =

(LOAD_BALANCE = ON)

(FAILOVER = on)

(ADDRESS = (PROTOCOL = TCP)(HOST = rac1-vip)(PORT = 1521))

(ADDRESS = (PROTOCOL = TCP)(HOST = rac2-vip)(PORT = 1521))

(CONNECT_DATA =

(SERVER = DEDICATED)

(SERVICE_NAME = RACDB)

(FAILOVER_MODE =

(TYPE = SELECT)

(METHOD = BASIC)

(RETRIES = 180)

(DELAY = 5)

)

在 session 1 中，连接 racdb ，并且做大数据量的 insert

Session1:

Sql>show parameter instance;

instance_name string RACDB1

Sql>insertinto test_a as select * from test_a; ---超过 100W，不断insert

接着，不同session 去连接 racdb，预想的结果是，由于 session1 连接的是节点1，而且，节点1 cpu 很繁忙，那么接下来的连接，都会去连接节点2才对，结果错了，还是会均衡分配不同的 session 去连接不同的实例。

对于这个解释：

Metalink ：263599.1

有一些说明，有可能是 pmon update 监听状态不及时导致的。但是，这个问题在 10gR2 的版本中应该解决了才对。

实验3：每个节点 创建 service ，client 连接 不同的 service（客户端不采用 lb） ，会不会实现 lb。

节点1：使用 dbca 创建 service：OLTP，能通过 crs_stat 看到

节点2：使用 EXECUTE DBMS_SERVICE.create_service (service_name => 'test',network_name => 'test', aq_ha_notifications => TRUE , failover_method => DBMS_SERVICE.FAILOVER_METHOD_BASIC , failover_type => DBMS_SERVICE.FAILOVER_TYPE_SELECT , failover_retries => 180 , failover_delay => 5 , clb_goal => DBMS_SERVICE.CLB_GOAL_LONG); 创建 service：test，在 crs_stat 中看不到

两者都可以通过 dba_service 或者其它 视图看到

客户端tnsnames.ora中配置：

racdb3 =

(DESCRIPTION =

(LOAD_BALANCE = ON)

(FAILOVER = on)

(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.92.200)(PORT = 1521))

(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.92.201)(PORT = 1521))

(CONNECT_DATA =

(SERVICE_NAME=oltp)

)

racdb4 =

(DESCRIPTION =

(LOAD_BALANCE = ON)

(FAILOVER = on)

(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.92.200)(PORT = 1521))

(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.92.201)(PORT = 1521))

(CONNECT_DATA =

(SERVICE_NAME=test)

)

实验结果：连接 racdb3 的，只会连接 节点1，不会连接节点2

连接 racdb4 的，只会连接 节点2，不会连接节点1

但是，会实现 服务端的 lb。

但是，如果我们把 客户端的配置改成：

racdb3 =

(DESCRIPTION =

(LOAD_BALANCE = ON)

(FAILOVER = on)

(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.92.200)(PORT = 1521))

(CONNECT_DATA =

(SERVICE_NAME=oltp)

)

只连接 节点1 的话，那么 服务端的 lb 也不会实现了，只会去连接 节点1。

实验4：使用 dbca 在节点 1 上创建一个 service “oltp”，并且，将节点 1 设成 preferred，节点2 设成 available，这样，就会先连接 节点 1，节点2 待命

在节点 1 上，使用

srvctl start service -d RACDB -s "oltp" 启动 oltp 服务（dbca 创建的服务不会随着 服务器 的启动而自动启动，每次需要手工启动）

在 客户端的 tnsnames.ora 中，配置如下：

racdb3 =

(DESCRIPTION =

(LOAD_BALANCE = ON)

(FAILOVER = on)

(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.92.200)(PORT = 1521))

(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.92.201)(PORT = 1521))

(CONNECT_DATA =

(SERVICE_NAME=oltp)

)

之后，在客户端中，不同的 session 不断连接 racdb3，可以看出，只会连接 节点 1 ，但是 这里有两种情况：

1、直接 direct 连接到 节点1

2、先 direct 连接到节点1，然后通过 remote_listener 的lb，再 redirect 到节点1

首先，我们来看下 第 1 种 情况下的 listener.log 的记录：

这种情况，只会在 节点 1 的 listener 上有记录，如下：

07-DEC-2010 09:52:16 * (CONNECT_DATA=(SERVICE_NAME=oltp)(CID=(PROGRAM=G:\oracle\product\10.2.0\db_2\bin\sqlplus.exe)(HOST=FZTXT)(USER=Administrator))) * (ADDRESS=(PROTOCOL=tcp)(HOST=192.168.92.3)(PORT=4098)) * establish * oltp * 0

接下来，我们来看下 第 2 种情况下的 listener.log 的记录：

这种情况，两个节点都有记录，先来看下 节点 2 的：

07-DEC-2010 10:20:12 * (CONNECT_DATA=(SERVICE_NAME=oltp)(CID=(PROGRAM=G:\oracle\product\10.2.0\db_2\bin\sqlplus.exe)(HOST=FZTXT)(USER=Administrator))) * (ADDRESS=(PROTOCOL=tcp)(HOST=192.168.92.3)(PORT=4606)) * establish * oltp * 0

再来看下 节点 1 的：

07-DEC-2010 10:20:12 * (CONNECT_DATA=(SERVICE_NAME=oltp)(CID=(PROGRAM=G:\oracle\product\10.2.0\db_2\bin\sqlplus.exe)(HOST=FZTXT)(USER=Administrator))(SERVER=dedicated)(INSTANCE_NAME=RACDB1)) * (ADDRESS=(PROTOCOL=tcp)(HOST=192.168.92.3)(PORT=4630)) * establish * oltp * 0

重点关注下 inistance_name 这一个关键词，这就表明了是通过 remote_listener 来进行 lb 的。

结论：通过创建 service ，还是能使 应用分离的，而且，更好的地方在于，当节点 1 shutdown 后，通过连接 service ，还能自动 failover 到节点2，这是很好的一个 应用。

实验5：测试一个节点 shutdown 后，通过 service 连上 服务端，能否连上

分别有两个 service，一个是 dbca 创建的 service，也就是能注册到 crs 中，另一个是 dbms_service 创建的 service ，不能注册到 crs 中。

首先，节点 1 使用 dbca 创建 service “oltp”，节点2 使用 dbms_service 创建 service “test”

然后，shutdown 掉节点1 （包括 nodeapps，但不包括 service），然后在 客户端的 tnsnames.ora 上，分别作如下配置：

racdb3 =

(DESCRIPTION =

(LOAD_BALANCE = ON)

(FAILOVER = on)

(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.92.200)(PORT = 1521))

(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.92.201)(PORT = 1521))

(CONNECT_DATA =

(SERVICE_NAME=oltp)

)

racdb4 =

(DESCRIPTION =

(LOAD_BALANCE = ON)

(FAILOVER = on)

(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.92.200)(PORT = 1521))

(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.92.201)(PORT = 1521))

(CONNECT_DATA =

(SERVICE_NAME=test)

)

Racdb3，连接 service “oltp”，racdb4 连接 service “test”

我们发现，所有客户端 ，不管是通过 racdb3 、还是 racdb4，都能连上 节点2。

接下来，我们开启 节点 1 的所有服务，停掉 节点 2 的 instance(srvctl stop instance)。

这时，我们可以通过 service “oltp” 连上节点1，但是使用 service “test” 时，会报如下错误：

SQL> conn fztxt/fztxt@racdb4

ERROR:

ORA-12514: TNS: 监听程序当前无法识别连接描述符中请求的服务

结论：通过实验，发现 ，如果 使用 dbms_service 创建的那个 节点 shutdown掉，那么 就不能 使用该 service 了。而 使用 dbca 创建的，只要在 crs 中，没有 srvctl stop 掉这个 service ，那么，一个节点 down 掉，还能 连到 另一个 节点中。