老熊的三分地-Oracle及数据恢复

与本系列的前几篇不同，本文将在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设置特性。