TAF PartI

TAF,透明应用故障转移(Transparent Application Failover),是Oracle数据库提供的一项高可用特性,普遍应用于RAC环境中,当然也可以用于Data Guard和传统的HA实现的主从热备的环境中。

TAF中的Transparent和Failover,点出了这个高可用特性的两大特点:

  • TAF是用于故障转移的,也就是切换。当Oracle连接的会话由于数据库发生故障不可用时,会话能够自动切换到RAC中的其他可用的节点上,或者切换到Standby上面,或者切换到HA方式中的另一个可用的节点上面。
  • TAF的故障转移,对应用来说是透明的,应用系统不需要进行特别的处理就能够自动进行故障转移。

但是,TAF是完美的吗?是不是使用了TAF,应用就能真的无缝地进行切换呢?对应用和数据库有没有其他什么要求?要回答这些问题,我们需要全面地了解、掌握TAF。我始终认为,要用好一个东西,首先得掌握这个东西背后的工作原理与机制。

首先来看看Failover。Failover有两种,一种是连接时Failover,另一种则是运行时Failover。前者的作用在于,应用(客户端)在连接数据库时,如果由于网络、实例故障等原因,连接不上时,能够连接数据库中的其他实例。后者的作用在于,对于一个已经在工作的会话(也就是连接已经建立),如果这个会话的实例异常中止等,应用(客户端)能够连接到数据库的其他实例(或备用库)。

首先,TAF是ORACLE客户端提供的一项特性。使用TAF,对客户端的环境有一定的要求。比如JAVA的JDBC驱动、Oracle客户端的版本等(8i开始支持TAF)。这个问题将在本系统文章的后面部分详细描述。

下面看一个有趣的例子:

Oracle服务器:运行在Linux AS4上的10.2.0.4,单实例数据库。
Oracle客户端:Windows 2003上的9.2.0.8
客户端TNS的配置:

XTY =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.114)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = XTY)
      (FAILOVER_MODE=
       (TYPE=SELECT)
       (METHOD=BASIC))
    )
  )

下面通过sqlplus连接到数据库:

D:\>sqlplus test/test@xty

SQL*Plus: Release 9.2.0.8.0 - Production on 星期四 3月 12 09:29:38 2009

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

连接到:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> SELECT SID FROM V$MYSTAT WHERE ROWNUM=1;

       SID
----------
       146

SQL> SELECT MACHINE, FAILOVER_TYPE, FAILOVER_METHOD, FAILED_OVER
2 FROM V$SESSION WHERE SID=146;

MACHINE              FAILOVER_TYPE FAILOVER_METHOD FAILED_OVER
-------------------- ------------- --------------- -----------------
WORKGROUP\DREAMF     SELECT        BASIC           NO   

从V$SESSION视图里面可以看到当前连接的会话,启用了TAF特性。
这个时候,我们当数据库DOWN下来,然后再启动:

SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORACLE instance started.

Total System Global Area  167772160 bytes
Fixed Size                  1266392 bytes
Variable Size             109055272 bytes
Database Buffers           54525952 bytes
Redo Buffers                2924544 bytes
Database mounted.
Database opened.

然后在客户端再次查询:

SQL> SELECT MACHINE, FAILOVER_TYPE, FAILOVER_METHOD, FAILED_OVER
2 FROM V$SESSION WHERE SID=146;

未选定行

可以看到,SQLPLUS并没有报错,只是查询的结果为0行。

SQL> SELECT SID FROM V$MYSTAT WHERE ROWNUM=1;

       SID
----------
       154

SQL> SELECT MACHINE, FAILOVER_TYPE, FAILOVER_METHOD, FAILED_OVER
  2  FROM V$SESSION WHERE SID=154;

MACHINE              FAILOVER_TYPE FAILOVER_METHOD FAILED_OVER
-------------------- ------------- --------------- --------------
WORKGROUP\DREAMF     SELECT        BASIC           YES

这里可以看到,SQLPLUS连接的会话ID(sessoin id)已经发生了变化,同时从v$session中查询的结果可以看到,FAILED_OVER从原来的“NO"变成了"YES”,也就是说,这个会话是经过故障转移重新连接的会话。

这个例子实际上在现实中没有什么意义,但是却清楚地表明了,TAF跟RAC无关,跟Standby数据库无关。这是由客户端实现的一个特性。

--to be continued

Trackback

7 comments untill now

  1. 真是经典啊,快点出part n吧:)

  2. 故障转移和负载均衡都是客户端来实现的。这个我还是从oracle的现场工程师那里得知的。
    最近一直在关注你的“三分地”,期待你更加精彩的文章。

  3. 熊哥,我猜你的part n是不是要写“TAF is not supported for remote database links”和“TAF is not supported for DML statements”。

  4. to allantrey
    想到哪里就写到哪里。^_^

  5. […] 接上文,在这一节中我们来观察一下使用TAF发生故障转移时,Oracle能够保证Select语句能够继续执行的现象。 […]

  6. 这个单实例的案例说明到是的确很经典!

  7. […] 前两篇文章(TAF PartI和TAF PartII)主要描述了在TAF发生故障转移时正在执行SELECT时的行为。本文将观察当故障转移发生时如果正在执行DML和DDL语句的行为。 […]

Add your comment now