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
----------
146SQL> 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
----------
154SQL> 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
真是经典啊,快点出part n吧:)
[回复]
故障转移和负载均衡都是客户端来实现的。这个我还是从oracle的现场工程师那里得知的。
最近一直在关注你的“三分地”,期待你更加精彩的文章。
[回复]
熊哥,我猜你的part n是不是要写“TAF is not supported for remote database links”和“TAF is not supported for DML statements”。
[回复]
to allantrey
想到哪里就写到哪里。^_^
[回复]
[…] 接上文,在这一节中我们来观察一下使用TAF发生故障转移时,Oracle能够保证Select语句能够继续执行的现象。 […]
这个单实例的案例说明到是的确很经典!
[回复]
[…] 前两篇文章(TAF PartI和TAF PartII)主要描述了在TAF发生故障转移时正在执行SELECT时的行为。本文将观察当故障转移发生时如果正在执行DML和DDL语句的行为。 […]