TAF PartIV

与本系列的前几篇不同,本文将在RAC上测试TAF的一些特性。而测试环境又有所不同:运行于Red Hat Enterprise Linux 5上的Oracle 10.2.0.1,客户端为Windows上的10.2.0.1。在客户端的TNSNAME配置如下:

DMDB =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.81)(PORT = 1521))
      (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.82)(PORT = 1521))      
    )
    (CONNECT_DATA =
      (SERVICE_NAME = dmdb)
      (FAILOVER_MODE =
        (TYPE = SELECT)
        (METHOD = BASIC)
        (RETRIES = 180) (DELAY = 5)         
      )      
    )
  )

我们使用sqlplus连接到数据库中(为节省篇幅,对部分无关紧要的输出做了剪裁):

D:\>sqlplus test/test@dmdb
连接到:
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, Real Application Clusters, OLAP and Data Mining options

由于负载均衡的作用,我们需要确定会话连接的实例(节点),下面的输出给出了当前会话连接的节点和会话信息:

SQL> show parameter instance_name

NAME                                 TYPE        VALUE
------------------------------------ ----------- -------
instance_name                        string      rac2

SQL> select sid from v$mystat where rownum=1;

       SID
----------
       147
SQL> select failover_type,failover_method,failed_over from v$session where sid=147;

FAILOVER_TYPE FAILOVER_M FAILED_OVE
------------- ---------- ----------
SELECT        BASIC      NO      

从上面输出的结果中的最后几行可以看出,会话已经启用了TAF

现在将节点2上的实例(也就是rac2)关闭,在sqlplus依次执行下面的命令,得到的结果如下:

SQL> show parameter instance_name

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------
instance_name                        string      rac1

SQL> select sid from v$mystat where rownum=1;

       SID
----------
       146
       
SQL> select failover_type,failover_method,failed_over from v$session where sid=146;

FAILOVER_TYPE FAILOVER_M FAILED_OVE
------------- ---------- ----------       
SELECT        BASIC      YES


从结果来看,会话已经顺利地failover到了第1个节点(rac1)上

在接下来的测试中,为了避免服务器端的自动均衡对测试造成的干扰,我们将两个实例的remote_listener参数设置为空,并使用lsnrctl services命令确认设置已经生效:

SQL> alter system set remote_listener='' sid='rac1';

System altered.

SQL> alter system set remote_listener='' sid='rac2';

System altered.

同时将客户端tnsname设置中原来的两个IP地址改为一个IP地址,即将:

(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.81)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.82)(PORT = 1521))

改为:

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

退出sqlplus,再次运行sqlplus,进行跟上面同样的测试:

SQL> show parameter instance_name

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
instance_name                        string      rac1
SQL> select sid from v$mystat where rownum=1;

       SID
----------
       140

SQL> select failover_type,failover_method,failed_over from v$session where sid=140;

FAILOVER_TYPE FAILOVER_METHOD      FAILED_OVER
------------- -------------------- ------------
SELECT        BASIC                NO

将节点1的实例(rac1)关闭,然后如上面的测试一样的操作,不过这一次,经过漫长的等待之后,出现了ORA-3113错误,Failover失败:

SQL> show parameter instance_name
ORA-03113: 通信通道的文件结束

从结果可以看到,在客户端的tnsname只设置一个地址时,failover失败了。

下面进行另外几组测试,不过不再列出具体的输出,只列出相应的结论:

  • 如果一个会话连接后,更改tnsname,将连接的IP地址从节点1改为节点2,然后关闭节点1的实例,在这个会话重新连接时,仍然使用的是原有的tnsname的设置,而不是新的。这样failover显然失败了。
  • 如果一个会话连接后,然后在两个实例上,设置remote_listener参数,然后关闭会话连接的实例,failover成功。
  • 如果一个会话连接后,然后在两个实例上,设置remote_listener参数,然后关闭会话连接的实例(rac1)和crs,跟预期相符的是,被关闭节点(rac1)的VIP漂移到另一个节点(rac1)上。然而,由于漂移的那个VIP上并没有监听,所以failover又失败了。重启rac1的crs和监听,以及实例rac2重新注册到rac1的监听上之后,failover成功。
  • 如果客户端的tnsname设置为连接两个地址,服务器无论有否设置remote_listener参数,failover总是会成功。
  • 如果客户端的tnsname设置为连接两个地址,但是客户端failover设置为no,即设置如下:

    (ADDRESS_LIST =
    (FAILOVER=NO)
    (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.81)(PORT = 1521))
    (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.82)(PORT = 1521))
    )

    这样的设置,与在客户端tnsname只设置连接一个地址(192.168.0.81)的结果没什么不同。

本文总结:RAC上的TAF测试结果表明,开启了TAF的会话,并不区分连接的数据库是RAC还是单实例库,也不区分数据库到底有多少个实例。客户端在开启了TAF之后,如果会话断开之后,只是根据TNSNAME的设置(广义上讲,指客户端的连接设置,不局限于TNSNAME),重新尝试连接而已。

下一篇将描述10g 数据库的服务器TAF设置特性。

Trackback

5 comments untill now

  1. “客户端在开启了TAF之后,如果会话断开之后,只是根据TNSNAME的设置(广义上讲,指客户端的连接设置,不局限于TNSNAME),重新尝试连接而已。”
    这一点不明白,这个结论是不是根据最后一个测试结论(FAILOVER=on)来说的?在tns连接串中简单设置FAILOVER=on,并不是启用了TAF,而是客户端连接的超时failover(Client Connect-Time Failover)

    老熊 Reply:

    这个结论,来自于最后一个测试结论。不过与您说的相反,在文章中写的是failover=NO,而不是您说的”ON”。在tnsname的设置中如果指定了两个或更多的连接地址,连接时failover是自动开启的。如果我关闭这个特性,这样在测试中我们可以看到,利用TAF功能failover时,只连接了列表中的第一个地址。

  2. 有空研究一下服务器端 服务的 TAF 属性吧!
    我也还不是很清楚。

  3. david3389 @ 2009-05-16 19:46

    熊哥,继续关注。。
    服务器端的TAF是最为关注的一个方面

    老熊 Reply:

    最近比较忙一点,但是会抽个时间写PartV

Add your comment now