写完上一篇文章后，感谢网友zzok和wlqj的回馈，根据他们的测试以及Oracle一些文档上的描述，负载均衡的默认配置是与节点忙闲程度有关的。不过节点忙闲程度是PMON进程负责通知，而PMON进程并非事实运行，因此通知很可能有一个延迟，而上面的测试在JOB刚开始运行后不久就开始了，而这时监听还不清楚节点2上繁忙的这个事实。

由于前一段时间这个环境有别的用处，因此一直耽搁了下来，这两天翻BLOG的时候，看到这个问题，于是今天重新测试一次。

本地TNSNAMES的设置可以参考第一篇文章。

今天将文章三中测试重新跑了一次，发现不管后台JOB运行多长的时间，测试结果都与（三）中的测试一致。看来可能是测试方法存在问题。

如果没有压力的情况下，Oracle在负载均衡的时候只考虑通过SERVICE_NAME连接的情况，那么是否Oracle并不是关心实例所在节点的忙闲程度，而是关心通过SERVICE_NAME连接的那些会话的忙闲程度。

下面更改一下测试方式，建立一个TEST.SQL文件，文件中包含一个存储过程，在客户端上建立一个过程，如果连接到实例1，则直接退出会话，如果连接到实例2，则进行大量的计算操作：

bash-2.03$ more test.sql
declare
        v_instance number;
        v_result number;
begin
        select instance_number into v_instance from v$instance;
        insert into t_record values (v_instance);
        commit;
        if v_instance = 2 then
                for i in 1..200000 loop
                        v_result := log(i+1, i+1);
                end loop;
        end if;
end;
/
exit

建立一个shell文件，后台登陆数据库并运行这个存储过程：

bash-2.03$ more test.sh
sqlplus test/test@testrac @test.sql &
sqlplus test/test@testrac @test.sql &
sqlplus test/test@testrac @test.sql &
sqlplus test/test@testrac @test.sql &
sqlplus test/test@testrac @test.sql &
sqlplus test/test@testrac @test.sql &
sqlplus test/test@testrac @test.sql &
sqlplus test/test@testrac @test.sql &
sqlplus test/test@testrac @test.sql &
sqlplus test/test@testrac @test.sql &
sqlplus test/test@testrac @test.sql &
sqlplus test/test@testrac @test.sql &
sqlplus test/test@testrac @test.sql &
sqlplus test/test@testrac @test.sql &
sqlplus test/test@testrac @test.sql &
sqlplus test/test@testrac @test.sql &
sqlplus test/test@testrac @test.sql &
sqlplus test/test@testrac @test.sql &
sqlplus test/test@testrac @test.sql &
sqlplus test/test@testrac @test.sql &
sqlplus test/test@testrac @test.sql &
sqlplus test/test@testrac @test.sql &
sqlplus test/test@testrac @test.sql &
sqlplus test/test@testrac @test.sql &
sqlplus test/test@testrac @test.sql &
sqlplus test/test@testrac @test.sql &
sqlplus test/test@testrac @test.sql &
sqlplus test/test@testrac @test.sql &
sqlplus test/test@testrac @test.sql &
sqlplus test/test@testrac @test.sql &

在数据库中建立T_RECORD表：

SQL> create table t_record (instance_id number);

表已创建。

下面运行test.sh脚本：

bash-2.03$ . test.sh

考虑PMON进程会有延迟，先后四次调用test.sh脚本，每次间隔一到两分钟左右：

bash-2.03$ sqlplus test/test@testrac

SQL*Plus: Release 10.2.0.3.0 - Production on 星期五 4月 24 00:06:12 2009

Copyright (c) 1982, 2006, Oracle.  All Rights Reserved.

连接到:
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production
With the Partitioning, Real Application Clusters, OLAP and Data Mining options

SQL> select instance_name from v$instance;

INSTANCE_NAME
----------------
testrac1

SQL> select instance_id, count(*)
  2  from t_record
  3  group by instance_id;

INSTANCE_ID   COUNT(*)
----------- ----------
          2         23
          1         97

这个结果已经很能说明问题了，如果在把每次调用的时间加上，就可以发现，越靠后的调用，连接分配到实例1上的越多。

那么是否能够说明负载均衡确实与连接到实例的会话忙闲程度有关呢，还不能。注意上面的test.sql文件，包含了一个退出命令，这会使得实例1上的连接迅速退出，而实例2上由于一直处于处理过程，所以连接无法退出。显然这个测试和前面第二篇文章的测试结果一样，只能说明连接数对负载均衡的影响，不能说明节点上负载对负载均衡的影响。

下面将test.sql里面的exit语句去掉，这样实例1上会话只是连接上而已，什么都不做，而实例2上的会话要进行大量的运算。

bash-2.03$ more test.sql
declare
        v_instance number;
        v_result number;
begin
        select instance_number into v_instance from v$instance;
        insert into t_record values (v_instance);
        commit;
        if v_instance = 2 then
                for i in 1..200000 loop
                        v_result := log(i+1, i+1);
                end loop;
        end if;
end;
/

再次运行test.sh脚本，这次运行了6次，观察得到的结果：

SQL> conn test/test
已连接。
SQL> select instance_id, count(*)
  2  from test.t_record
  3  group by instance_id;

INSTANCE_ID   COUNT(*)
----------- ----------
          1        100
          2         80

可以看到，这次实例1上仅比实例2上多出20个连接，差距远远不像第一次测试那么明显，而查询GV$SESSION视图可以看到：

SQL> select inst_id, count(*)
  2  from gv$session
  3  where service_name = 'testrac'
  4  group by inst_id;

   INST_ID   COUNT(*)
---------- ----------
         1        100
         2        103

很好的满足了测试二的结果。只所以实例一上比实例二多了20个连接，是因为测试开始时，实例2上的连接数比实例1上多了20个左右。

这篇测试从开始到结束运行时间超过30分钟以上，如果这么长时间PMON进程都无法将系统忙闲程度反馈给监听，那么即使存在反馈意义也不大了。

通过这个测试，再一次证明RAC的负载均衡与各个实例上的通过监听的连接数量有关，而与各个实例的忙闲程度无关。