SQL Server誤區30日談 第1天 正在啟動並執行事務在伺服器容錯移轉後繼續執行

誤區 #1：在伺服器容錯移轉後，正在啟動並執行事務繼續執行

這當然是錯誤的!

每次容錯移轉都伴隨著某種形式的恢複。但是如果當正在執行的事務沒有Commit時，由於伺服器或執行個體崩潰導致串連斷開，SQL Server可沒有辦法在容錯移轉後的伺服器重建立立事務的上下文並繼續執行事務-無論你使用的容錯移轉方式是叢集，鏡像，記錄傳送或是SAN複製。

對於容錯移轉叢集來說，當容錯移轉發生後，一個SQL Server執行個體在另一個容錯移轉叢集的節點啟動。所有執行個體上的資料庫都要經曆Recovery階段-也就是所有沒有Commit的事務都要被復原。

對於資料庫鏡像來說，來自主體伺服器的日誌不斷傳送到鏡像伺服器進行Redo操作。當鏡像伺服器被切換作為主體伺服器時，原鏡像伺服器的交易記錄將會變為Recovery模式，這使得好像原鏡像伺服器經曆了一次崩潰那樣，在這之後所有的串連都會導向原鏡像伺服器。

對於交易記錄傳送來說，交易記錄被定期備份並傳送到次要伺服器.當主伺服器崩潰時,DBA按照恢複順序將次要伺服器恢複後上線.但最終步驟都是要執行recovery步驟，也就是將沒有提交的事務進行復原。

對於SAN複製來說，本地SAN的I/O被複製到遠程SAN上進行重放，當容錯移轉發生後,系統將會串連到遠端SAN但資料庫仍然需要執行recovery步驟，這和容錯移轉叢集極其類似。

“唯一”使得正在執行的事務在容錯移轉發生後仍然得以繼續執行的技術使用帶有即時移轉功能的虛擬化技術，因為這時串連本身並不知道其串連的對象已經變為另一台物理伺服器。

但是無論使用那種技術，如果”串連”失效，正在執行的事務將會丟失，所以處理這類問題的這部分工作就需要在程式中用代碼實現某種“重新執行”的功能。