這當然是錯誤的! 每次故障轉(zhuǎn)移都伴隨著某種形式的恢復。但是如果當正在執(zhí)行的事務(wù)沒有Commit時，由于服務(wù)器或?qū)嵗罎е逻B接斷開，SQL Server可沒有辦法在故障轉(zhuǎn)移后的服務(wù)器重新建立事務(wù)的上下文并繼續(xù)執(zhí)行事務(wù)-無論你使用的故障轉(zhuǎn)移方式是集群，鏡像，日志傳送或是SAN復制。 對于故障轉(zhuǎn)移集群來說，當故障轉(zhuǎn)移發(fā)生后，一個SQL Server實例在另一個故障轉(zhuǎn)移集群的節(jié)點啟動。所有實例上的數(shù)據(jù)庫都要經(jīng)歷Recovery階段-也就是所有沒有Commit的事務(wù)都要被回滾。 對于數(shù)據(jù)庫鏡像來說，來自主體服務(wù)器的日志不斷傳送到鏡像服務(wù)器進行Redo操作。當鏡像服務(wù)器被切換作為主體服務(wù)器時，原鏡像服務(wù)器的事務(wù)日志將會變?yōu)镽ecovery模式，這使得好像原鏡像服務(wù)器經(jīng)歷了一次崩潰那樣，在這之后所有的連接都會導向原鏡像服務(wù)器。 對于事務(wù)日志傳送來說，事務(wù)日志被定期備份并傳送到輔助服務(wù)器.當主服務(wù)器崩潰時,DBA按照恢復順序?qū)⑤o助服務(wù)器恢復后上線.但最終步驟都是要執(zhí)行recovery步驟，也就是將沒有提交的事務(wù)進行回滾。 對于SAN復制來說，本地SAN的I/O被復制到遠程SAN上進行重放，當故障轉(zhuǎn)移發(fā)生后,系統(tǒng)將會連接到遠端SAN但數(shù)據(jù)庫仍然需要執(zhí)行recovery步驟，這和故障轉(zhuǎn)移集群極其類似。 “唯一”使得正在執(zhí)行的事務(wù)在故障轉(zhuǎn)移發(fā)生后仍然得以繼續(xù)執(zhí)行的技術(shù)使用帶有實時遷移功能的虛擬化技術(shù)，因為這時連接本身并不知道其連接的對象已經(jīng)變?yōu)榱硪慌_物理服務(wù)器。 但是無論使用那種技術(shù)，如果”連接”失效，正在執(zhí)行的事務(wù)將會丟失，所以處理這類問題的這部分工作就需要在程序中用代碼實現(xiàn)某種“重新執(zhí)行”的功能。

版權(quán)聲明：本站文章來源標注為YINGSOO的內(nèi)容版權(quán)均為本站所有，歡迎引用、轉(zhuǎn)載，請保持原文完整并注明來源及原文鏈接。禁止復制或仿造本網(wǎng)站，禁止在非www.sddonglingsh.com所屬的服務(wù)器上建立鏡像，否則將依法追究法律責任。本站部分內(nèi)容來源于網(wǎng)友推薦、互聯(lián)網(wǎng)收集整理而來，僅供學習參考，不代表本站立場，如有內(nèi)容涉嫌侵權(quán)，請聯(lián)系alex-e#qq.com處理。