SQL Server誤區30日談 第11天 鏡像在檢測到毛病後剎時就可以毛病轉移。本站提示廣大學習愛好者：（SQL Server誤區30日談 第11天 鏡像在檢測到毛病後剎時就可以毛病轉移）文章只能為提供參考，不一定能成為您想要的結果。以下是SQL Server誤區30日談 第11天 鏡像在檢測到毛病後剎時就可以毛病轉移正文
誤區 #11:鏡像在檢測到毛病後剎時就可以毛病轉移
毛病
數據庫鏡像的毛病轉移既可以主動提議，也能夠手動提議。
在主動提議的情形下,是由鏡像辦事器履行毛病轉移操作（你沒有看錯，其實不是由見證辦事器來做毛病轉移的決議）,在見證辦事器和鏡像辦事器都發明沒法和主體辦事器交流信息(這個進程被稱為”構成仲裁”,譯者注:也就是經由過程法式對集群停止監管，集群可用的根據來自監管法式的算法，好比依據:每一個節點的設置裝備擺設，文件同享情形，磁盤拜訪情形，每一個節點的可用性等來肯定集群能否可用)而且鏡像方法是同步時，可以停止毛病轉移。(譯者注：所謂的同步指的是主體辦事器必需期待鏡像辦事器的日記寫入後，能力夠提交事務。絕對異步來講機能更差，但更平安，而且還不須要SQL Server是企業版)。
手動毛病轉移是由你提議的,手動提議能夠是因為不存在見證辦事器(以致於沒法“構成仲裁”)，或是在主體辦事器如今成績時鏡像的運轉形式不是“同步”。
當主體辦事器產生毛病時，鏡像辦事器在日記隊列Redo完成之前不會上線(所謂的日記隊列就是由主體辦事器傳送到鏡像辦事器的日記，但還沒有在鏡像辦事器Replay)。即便你鏡像的運轉形式是同步,也僅僅只能解釋日記被寫入鏡像磁盤，但不克不及包管日記在鏡像辦事器被重放。而關於毛病轉移來講，鏡像辦事器必需閱歷Roll Forward階段能力夠上線.但Roll Back階段是鏡像上線後才會做的。
在SQL Server尺度版和企業版地點的CPU低於5個內核，Roll Forward只要一個線程。關於企業版而且CPU過剩5核，為每4個核分派一個Roll Forward線程。所以完整可以看出毛病轉移所需的時光取決於須要對日記停止Redo處置的隊列年夜小，CPU的核數，和鏡像辦事器的負載。
因為年夜家都以為鏡像任務在同步方法時可以敏捷停止毛病轉移，所以很少有人檢測日記Redo隊列。但因為Redo隊列的年夜小肯定了毛病轉移時Downtime的年夜小，所以檢測鏡像辦事器Redo隊列變得非常主要。
有關這裡更細節的文章，你可以參看:Estimating the Interruption of Service During Role Switching
