從TAF到TAC，業務連續性的追求永無止境

對於資料庫系統來說，高可用和業務連續性是使用者最為關注的問題。在我參與的幾次使用者調研中，業務連續性問題都是排名第一的關注點，而且熱度是排名第二的問題的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難道不是你們更好的選擇嗎?