Oracle RAC 的连接时负载均衡（二）

最新推荐文章于 2021-12-22 14:05:26 发布

conglou7547

最新推荐文章于 2021-12-22 14:05:26 发布

阅读量106

点赞数

文章标签：数据库

Go to My Oracle Blog

又有人说Oracle RAC的负载均衡只能依据会话数，我开始有点受不了一次又一次的解释了，上一次在10g RAC上证明过了，这一次在11g上再证明一次，先来一个根据会话数的，再来一个根据操作平均响应时间的。对比一下，还能不明白？>_<

[@more@]

11.1RAC的连接时负载均衡：
一: 根据会话数
二: 根据操作执行响应时间

# 数据库名：
RDBB

# RAC节点：
eg7714, eg7562

# 客户端：
eg7970

# 创建测试用户和表：
RDBB1> create user racuser identified by oracle;
User created.
RDBB1> grant connect,resource,dba to racuser;
Grant succeeded.
RDBB1> conn racuser/oracle
Connected.
RDBB1> create table test(id number);
Table created.

# 创建负载SQL脚本w.sql：
begin
for i in 1..1000 loop
insert into test select sid from v$mystat where rownum < 2;
commit;
delete from test where id in (select sid from v$mystat where rownum < 2);
commit;
end loop;
end;
/
exit;

# 创建负载Shell脚本w.sh：
while true
do
sqlplus -s racuser/oracle@SERV @w.sql
done

# 创建模拟会话脚本s.sh(25个会话):
./w.sh &
./w.sh &
./w.sh &
./w.sh &
./w.sh &
./w.sh &
./w.sh &
./w.sh &
./w.sh &
./w.sh &
./w.sh &
./w.sh &
./w.sh &
./w.sh &
./w.sh &
./w.sh &
./w.sh &
./w.sh &
./w.sh &
./w.sh &
./w.sh &
./w.sh &
./w.sh &
./w.sh &
./w.sh &

# 创建客户端TNSNAME：
SERV =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = eg7714-vip)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = eg7562-vip)(PORT = 1521))
(LOAD_BALANCE = yes)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = SERV)
)
)

# 创建一个服务，名为SERV：
[oracle@eg7714 ~]$ srvctl add service -d RDBB -s SERV -r RDBB1,RDBB2
[oracle@eg7714 ~]$ srvctl start service -d RDBB -s SERV
查看一下它的连接时负载均衡设置是什么样的：
RDBB1> select name,goal,clb_goal from dba_services where name ='SERV';

NAME GOAL CLB_G
------- ------------ -----
SERV NONE LONG
LBA目标是NONE，CLB目标是LONG，这是默认的配置，意思是根据会话数负载均衡。默认设置又不代表只能根据会话数，等一下可以修改。

# 在客户端发起连接负载
[oracle@eg7970 todd]$ ./s.sh

# 反复执行SQL观察结果，两个节点的会话数基本相等，因为现在是根据会话数在连接负载均衡。
RDBB1> select inst_id,count(*) from gv$session where username='RACUSER' group by inst_id;

INST_ID COUNT(*)
---------- ----------
1 13
2 12
RDBB1> /

INST_ID COUNT(*)
---------- ----------
1 14
2 11

RDBB1> /

INST_ID COUNT(*)
---------- ----------
1 14
2 11

RDBB1> /

INST_ID COUNT(*)
---------- ----------
1 13
2 12
RDBB1> /

INST_ID COUNT(*)
---------- ----------
1 12
2 13

# 现在尝试在其中一个节点提高CPU的负载
在eg7562上开两个终端，让它不停地算质数：
[oracle@eg7562 todd]$ ./primes
[oracle@eg7562 todd]$ ./primes
使eg7562的cpu工作量上升，实际是在Cpu(s): 70.0-80.0% 上下，此时eg7714维持在Cpu(s): 3.0-7.0%

# 再一次反复执行SQL观察结果，发现两个节点的会话数还是不相上下，毕竟是根据会话数来负载均衡的，所以这样的结果是当然的。
SQL> run
1* select inst_id,count(*) from gv$session where username='RACUSER' group by inst_id

INST_ID COUNT(*)
---------- ----------
1 13
2 12

SQL> run
1* select inst_id,count(*) from gv$session where username='RACUSER' group by inst_id

INST_ID COUNT(*)
---------- ----------
1 14
2 11
SQL> /

INST_ID COUNT(*)
---------- ----------
1 13
2 12
SQL> /

INST_ID COUNT(*)
---------- ----------
1 12
2 13
SQL> /

INST_ID COUNT(*)
---------- ----------
1 14
2 11

# 现在，我要把SERV的连接负载均衡方式更改为SERVICE_TIME，也就是平均响应时间，注意这个和很多因素有关，当然很容易想象，在一个CPU负载相对很高的节点上，它在SERVICE_TIME上的得分会高吗？
RDBB1> exec dbms_service.modify_service('SERV',GOAL=>DBMS_SERVICE.GOAL_SERVICE_TIME,CLB_GOAL=>DBMS_SERVICE.CLB_GOAL_SHORT);

PL/SQL procedure successfully completed.
RDBB1> select name,goal,clb_goal from dba_services where name ='SERV';

NAME GOAL
---------------------------------------------------------------- ------------
CLB_G
-----
SERV SERVICE_TIME
SHORT

# 重启服务SERV
[oracle@eg7714 ~]$ srvctl stop service -d RDBB -s SERV -f
[oracle@eg7714 ~]$ srvctl start service -d RDBB -s SERV

# 继续观察会话的分布情况：
RDBB1> run
1 select inst_id,count(*) from gv$session where username='RACUSER' group by inst_id
2*

INST_ID COUNT(*)
---------- ----------
1 23
2 2

RDBB1> /

INST_ID COUNT(*)
---------- ----------
1 20
2 5

RDBB1> /

INST_ID COUNT(*)
---------- ----------
1 20
2 5

RDBB1> /

INST_ID COUNT(*)
---------- ----------
1 22
2 3

RDBB1> /

INST_ID COUNT(*)
---------- ----------
1 19
2 6

结果很明显了，节点2号因为CPU的原因影响了服务SERV的 SERVICE_TIME，从而失去了青睐。

还有其他的负载均衡算法，请参考DBMS_SERVICE文档。

Todd