FAILOVER，Oracle RAC的高可用性的技術基礎是Failover，就是指集群中的熱河一個節點的故障都不會影響到用戶的使用，連接到故障節點的用戶會被自動轉移到健康節點，從用戶高手而言感覺不到這種切換，這個功能在Oracle中被稱作Failover（故障轉移）。
Oracle RAC的Failover可以細分為3中，分別是：
（1） Client-Side Connect time Failover；
（2） TAF；
（3） Server-side TAF；
注意：
不要再listener.ora中設置GLOBAL_DB_NAME，因為這個參數會禁用Connect-time Failover和TransparentApplication Failover。
Client-Side Connect timeFailover的含義是：如果客戶端tnsname中配置了多個地址，用戶發起請求時，會先嘗試連接地址表中的第一個地址，如果這個連接嘗試失敗，則會繼續嘗試使用第二個地址，直至連接成功或者遍歷了所有的地址。
這種Failover的特點從他的名稱中“connect time”就表達的很清楚了，只在建立連接的那一時刻起作用。也就是說這種Failover方式只在發起連接時采取感知節點故障，如果發現節點沒有響應，則自動嘗試地址列表的下一個地址。一旦連接建立以後，節點出現故障都不會做處理，從客戶端的表現來看就是斷開，用戶程序必須重新建立連接。
啟用這種Failover的方法就是在客戶端的tnsnames.ora中添加FAILOVER=ON條目，這個參數默認就是ON，所以即使不添加這個條目，客戶端也會獲得這種Failover能力。
從上文對Client-Side Connecttime Failover特點的分析可以看出，這種failover的意義有限。下載大部分流行的應用系統（比如WebLogic，JBOSS）都是啟動時就建立若干到數據庫的長連接，在應用程序整個生命周期內重用這些連接。Client-Side Connect Time Failover的工作方式是它對應用程序的可用性沒有極大地幫助。
從8.1.5版本Oracle引入了新的Failover機制TAF.所謂TAF，就是連接建立以後，應用程序運行過程中，如果某個實例發生故障，連接到這個實例上的用戶會被自動遷移到其他的健康實例上。對於應用程序而言，這個千億過程透明、不需要用戶的介入，當然這種透明也是有引號的，因為用戶的未提交事務會回滾。相對於Client-Side Connect Time Failover的用戶程序被中斷、拋出連接錯誤、用戶必須中期應用程序，TAF這種方式在提高應用程序HA能力上無疑是前進了一大步。
TAF的配置也很簡單，只需要在客戶端的tnsnames.ora中添加FAILOVER_MODE配置項，這個條目有4個子項目需要定義。
FRAC =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = frac1-vip)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = frac2-vip)(PORT = 1521))
(LOAD_BALANCE=YES)
(
CONNECT_DATA=
(SERVER=DEDICATED)
(SERVICE_NAME=FRAC)
(
FAILOVER_MODE=
(TYPE=session)
(METHOD=basic)
(RETRIES=180)
(DELAY=5)
)
)
)
（1） METHOD選項用於定義何時創建到其他實例的連接，有BASIC和PERCONNECT兩個選項值。
a． BASIC是指在感知到節點故障時才創建到其他實例的連接。
b． PERCONNECT是在最初建立連接時就同時建立到所有實例的連接，當發生故障時，立刻就可以切換到其他鏈路上。
兩種方法的不同很容易比較。BASIC方式在Faiover時會有時間言辭，PERCONNECT方式雖然沒有時間言辭，但是再建立多個冗余兩節會消耗更多的資源，兩者就是用時間換資源和資源換時間的區別。
（2） Type選項用於定於發生故障時對完成的SQL語句如何處理，其有兩種類型：session和select。
這兩種方式對於未提交的事務都自動回滾。區別在於對於select語句的處理，對於select類型，用戶正在執行的select語句也會被轉移到新的實力上，在新節點上繼續返回後續結果集，而已經返回的記錄結果集拋棄。
假設用戶正在節點1上執行查詢，整個結果集共有100條記錄，現在一從節點1上返回10條記錄，這時節點1宕機，用戶連接被轉移到節點2上，如果是session方式則需要重新執行查詢語句；如果是select方式會從節點2上繼續返回剩下的90條記錄，二已經從節點1返回的10條記錄不會重復返回給用戶，對於用戶而言感覺不到這種切換。
很顯然為了實現select方式，oracle必須為每個session保存更多的內容，包括游標、用戶、上下文等，需要更多的資源也是用資源換時間的方案。
（3） DELAY和RETRIES這兩個參數和簡單，代表著重試時間間隔和重試次數。
Failover（TAF）的測試借助於前面監聽和tnsnames的配置，而在11G R2沒有引入之前出現故障用的是直接用集群的vip“漂”進行故障轉移，而在11G R2以後，引入了一個新的ip，即SCAN（SingleClient Access Name）IP，Scan是一個域名，可以解析1到3個scan ip，客戶端可以通過SCAN名解析來訪問數據庫，其好處就是添加和刪除節點時不需要再有額外的客戶端維護，大大減少了維護方面的繁瑣工作。
在集群環境中，我們配置的客戶端是以scan ip的方式進行配置的。當我們某個用戶在外面連接進來的時候，集群會自動的根據負載把該會話連接到一個特定的實例，如果該會話正在select一個表，還未完成，該實例宕機了，oracle會自動將故障節點的失誤切換到另一個實例中執行，這樣的切換對於用戶來說是透明的。用戶不會感覺到異常，所執行操作也將返回正常的結果，這個也是RAC集群的高可用性所在。以下是在session模式做的網絡failover測試；
首先用戶用客戶端服務進行連接：
[oracle@frac1admin]$ sqlplus scott/oracle@frac
SQL*Plus: Release11.2.0.3.0 Production on Wed Apr 16 01:55:37 2014
Copyright (c) 1982,2011, Oracle. All rights reserved.
Connected to:
Oracle Database 11gEnterprise Edition Release 11.2.0.3.0 - 64bit Production
With thePartitioning, Real Application Clusters, Automatic Storage Management, OLAP,
Data Mining and RealApplication Testing options
SQL> showparameter instance_name
NAME TYPE VALUE
---------------------------------------------------------- ------------------------------
instance_name string FRAC2
SQL> create tablebig_a as select * from dba_objects;
SQL>insert intobig_a select * from big_a;
為了保證數據的充足性，多執行幾次上面insert語句，由於磁盤空間限制，我在此執行了4次，共1203888條記錄。
由以上信息可知用戶連接到frac2實例，此時可以執行一些DML操作：
SQL> selectOBJECT_TYPE,count(*) from big_a group by object_type;
在查詢未完成之前，把frac2實例進行宕機，會返回如下錯誤：
SQL> shutdownabort;
ORACLE instance shutdown.
SQL> selectOBJECT_TYPE,count(*) from dba_objects group by object_type;
selectOBJECT_TYPE,count(*) from dba_objects group by object_type
*
ERROR at line 1:
ORA-25408: can notsafely replay call
再次查看的是時候發現已經把會話自動切換到frac1實例：
SQL> /
OBJECT_TYPE COUNT(*)
------------------------------------------------
EDITION 1
INDEX PARTITION 302
TABLESUBPARTITION 32
CONSUMER GROUP 25
SEQUENCE 229
TABLE 2936
INDEX 5266
SYNONYM 28152
VIEW 5186
FUNCTION 305
JAVA CLASS 23165
JAVA SOURCE 2
INDEXTYPE 9
CLUSTER 10
TYPE 2913
RESOURCE PLAN 10
JOB 14
EVALUATIONCONTEXT 15
45 rows selected.
SQL> showparameter instance_name;
NAME TYPE VALUE
---------------------------------------------------------------------------- ------
instance_name string FRAC1
SQL> !hostname
frac1
第三種方式是Server-Side TAF，但從名字上就可以猜出這種方式和之前的TAF有一定的關系。事實上也是這樣，可以把Server-Side TAF看做是TAF的一個變種。首先Server-Side TAF也是TAF，所有TAF的特點他都具有；其次，這種TAF是在服務器上配置，而不像TAF是在客戶端配置的。
前面介紹的Client-Side TAF，配置過程需要修改客戶端tnsnames.ora文件，如果有很多客戶端使用這個數據庫，那麼每次微小的參數調整都要把書友計算機更改一遍，即低效又易出錯。而Server-Side TAF通過結合Service，在數據庫裡保存FAIL_MODE的配置，把所有的TAF配置保存在數據字典裡，從而省去了客戶端的配置工作，現在客戶端的TNS文件就不需要任何TAF的配置選項。
從配置參數而言，Service-Side TAF相比多了一個Instance Role（實力角色）的概念。所謂實力角色，就是當有多個Instance參與一個Service時，可以配置有限使用哪一個Instance為用戶提供服務。用戶總共有兩種可選角色。
a． PREFERRED:首選實例，會優先選擇擁有這個角色的實例提供服務。
b． AVILABLE:後備實例，用戶會優先連接PREFERRD的Instance，當PREFERRED的Instance不可用時，才會被轉移到AVILABLE的實例上。
要想使用Server-Side TAF必須配置Server。Server可以在創建數據庫時創建，也可以在數據庫創建之後修改；既可以通過配置向導也可以通過命令行方式配置。下面分別演示用DBCA和手工兩種方式配置Service的過程。
