對于數據庫系統來說，高可用和業務連續性是用戶最為關注的問題。在我參與的幾次用戶調研中，業務連續性問題都是排名第一的關注點，而且熱度是排名第二的問題的2倍以上。對于企業級應用或者關鍵系統來說，業務連續性是永恒的話題。券商的數據庫出問題了，那么能否在數秒內恢復業務？銀行的數據庫出問題了，能否RPO=0,RTO接近于0？對于絕大多數中小金融機構的大多數系統，運營商的大多數系統，政府、醫療、制造業的絕大多數關鍵系統而言，單機集中式數據庫的處理能力是足夠的，用戶最需要擔心的其實只是高可用的問題。

Oracle 在1998年推出Oracle 8i的時候，推出了一個叫做透明應用故障切換TAF（Transparent Application Failover）的技術組件。從而讓OPS節點故障時實現連接的自動切換。20年后，Oracle 18C中的高可用從透明估值切換演變成了透明應用連續性TAC（Transparent Application Continuity），這個功能將會成為Oracle 23C首推的高可用切換方案。今天我們就來簡單地了解一下Oracle的數據庫高可用技術的發展歷程。國產數據庫廠商也應該能夠從這個發展歷程中受到一定的啟發，從而優化國產數據庫的高可用能力。

個人認為Oracle的數據庫高可用大體可以分為TAF/FCF/TAC（AC）三大階段?？赡苡行┡笥褧衅渌囊恍┓侄畏椒?。TAF主打的是OPS/RAC的透明故障切換。這是一種客戶端故障切換技術，當客戶端發現數據庫實例無法正常工作的時候，經過數次RETRY無效，則自動發起連接切換。這種切換有兩種模式，一種是SESSION模式，重新創建一個新的會話，拋棄以前做的所有任務，重新開始新的工作。還有一種是SELECT模式，如果發生切換的會話正在做一個只讀事務，則正在做的SELECT可以繼續進行。這是因為與SELECT相關的所有數據與控制信息在PGA中是完整的，不需要依賴服務器的SGA和服務器的狀態。    

TAF功能夠強，只不過切換的時間會長了一點，因為客戶端感知故障，多次RETRY，都會浪費一定的時間。而一些關鍵應用需要更快地切換時間。因此快速連接故障切換（FCF）在Oracle中應運而生了，這個技術在Oracle 11G隨著UCP連接池的推出，變得更加完善了。FCF技術依賴于Fast Application Notification (FAN)。傳統上，數據庫實例產生某些變化（服務、實例、節點的DOWN 或 UP）時，應用程序會掛起，直到超時，此時應用程序會收到相關的SQL異常。隨 Oracle Database 11g 引入FAN，事件以快速可靠的方式通知給訂閱者。借助Oracle 10g開始引入的 Oracle 通知服務 (ONS)，數據庫實例宕機時，服務或者節點50毫秒或更短的時間內啟動故障轉移。

FCF解決了快速切換的問題，如果應用程序里捕獲了ONS中的事件產生的客戶端錯誤，并且自動放棄當前的業務邏輯，重新完成業務邏輯，那么在客戶端幾乎可以對RAC某個節點的故障無感知。不過FCF有一點是對TAF的一個倒退，那就是FCF要放棄所有的故障前的操作。哪怕有一條SELECT已經查了2小時，還有1秒鐘就可以完成。

為了解決這個問題，讓系統的高可用更加完備，Oracle在12C中對整個數據庫高可用框架進行了重構。引入了全局數據服務(GDS)、事務守護者Transaction Guard (TG)等機制?；谶@些新的機制，實現了應用連續性（AC）和透明應用連續性（TAC）。并且將高可用框架擴展到了RAC以外。ADG/OGG復制環境中，也可以使用這些高可用解決方案。

Oracle要實現的目標是，當系統故障切換的時候，能不能做到應用無感。也就是說，如果切換是無損切換（比如RAC節點故障，同步ADG的故障切換，ADG的SWITCHOVER等場景）的時候，是不是可以實現快速的無損切換，讓業務連續性得到最大的保護呢？為了實現這個目標，Oracle引入了TG和故障事務重播。基于此，DML/DDL等寫操作都可以實現透明切換。

從Oracle Database 12c開始，每個事務都與一個邏輯事務 ID (LTXID) 相關聯。其目的是幫助可靠地確定運行中 COMMIT 語句的結果。已分配 LTXID由 RDBMS 在每個事務開始時更改（即遞增），僅在以下情況下由 RDBMS 更改：相應的事務要么被提交，要么被回滾。為了更好的實現TG，Oracle 12c 引入了“數據庫請求”的概念。UCP 在連接檢出時透明地劃分數據庫請求的開始和連接的結束。同時“可恢復的錯誤”的概念引入也相當關鍵。Oracle  12c 將所有 SQL 異常分為兩大類：可恢復錯誤和 不可恢復（即違反約束）。所有錯誤消息都有一個附加的名為 OracleException.IsRecoverable 的屬性。

有了這些基礎技術以后，TAC的實現就能牛逼了。當RAC的節點故障時，如果你配置了TAC，那么故障的SESSION能自動切換到接管實例上，未完成的 讀寫操作繼續完成，應用端無需捕獲錯誤，也不會捕獲到錯誤。應用端的感受僅僅是好像當前事務比以往略微慢了一點點。

TAC不僅可以在RAC中實現，對于ADG環境中依然可以實現。如果ADG采用了同步復制模式，那么數據肯定是無損的，因此ADG可以在FAILOVER的時候通過TAC來實現切換。如果ADG不是同步模式的 ，那么為了確保故障回放的一致性，此切換僅僅能在SWITCHOVER這種無損切換中使用。在ADG上的TAC實現效果與RAC上并無太大區別，只是切換的時間長了不少而已。    

從上面我對Oracle高可用技術發展的描述上，大家應該可以看出Oracle為了提高數據庫的可用性而做的努力。目前國產數據庫也在推出類似Oracle RAC的技術，在這些國產的“RAC”里，無一例外地支持了類似TAF的技術。我覺得在Oracle已經演進到了TAC的今天，我們的國產數據庫廠商哪怕不做個彎道超車，追上Oracle，實現真正的平替也是很必要的吧。

另外對于我們親愛的用戶和應用開發商，我也想說兩句，二十多年過去了，你還只會用TAF做故障切換嗎？TAC難道不是你們更好的選擇嗎？