SQL Server誤區30日談 第1天 正在運轉的事務在辦事器毛病轉移後持續履行。本站提示廣大學習愛好者：（SQL Server誤區30日談 第1天 正在運轉的事務在辦事器毛病轉移後持續履行）文章只能為提供參考，不一定能成為您想要的結果。以下是SQL Server誤區30日談 第1天 正在運轉的事務在辦事器毛病轉移後持續履行正文
誤區 #1：在辦事器毛病轉移後，正在運轉的事務持續履行
這固然是毛病的!
每次毛病轉移都隨同著某種情勢的恢復。然則假如當正在履行的事務沒有Commit時，因為辦事器或實例瓦解招致銜接斷開，SQL Server可沒有方法在毛病轉移後的辦事重視新樹立事務的高低文並持續履行事務-不管你應用的毛病轉移方法是集群，鏡像，日記傳送或是SAN復制。
關於毛病轉移集群來講，當毛病轉移產生後，一個SQL Server實例在另外一個毛病轉移集群的節點啟動。一切實例上的數據庫都要閱歷Recovery階段-也就是一切沒有Commit的事務都要被回滾。
關於數據庫鏡像來講，來自立體辦事器的日記赓續傳送到鏡像辦事器停止Redo操作。當鏡像辦事器被切換作為主體辦事器時，原鏡像辦事器的事務日記將會變成Recovery形式，這使得似乎原鏡像辦事器閱歷了一次瓦解那樣，在這以後一切的銜接都邑導向原鏡像辦事器。
關於事務日記傳送來講，事務日記被按期備份並傳送到幫助辦事器.當主辦事器瓦解時,DBA依照恢復次序將幫助辦事器恢復後上線.但終究步調都是要履行recovery步調，也就是將沒有提交的事務停止回滾。
關於SAN復制來講，當地SAN的I/O被復制到長途SAN長進行重放，當毛病轉移產生後,體系將會銜接到遠端SAN但數據庫依然須要履行recovery步調，這和毛病轉移集群極端相似。
“獨一”使得正在履行的事務在毛病轉移產生後依然得以持續履行的技巧應用帶有及時遷徙功效的虛擬化技巧，由於這時候銜接自己其實不曉得其銜接的對象曾經變成另外一台物理辦事器。
然則不管應用那種技巧，假如”銜接”掉效，正在履行的事務將會喪失，所以處置這類成績的這部門任務就須要在法式頂用代碼完成某種“從新履行”的功效。
