Step 4: 通知監控服務器角色已變更 SQL Server 2000 的日志傳送會在監控服務器上安裝監控工具程序；最好是在第三台服務器。為了通知監控服務器日志傳送的角色已經過變更，您必須在監控服務器上執行 sp_change_monitor_role 預存程序，如程序代碼列表3所示。盡管名稱內含有 change 字眼，但它並不會變更監控服務器的角色。相反地，此預存程序會變更主要/次要服務器內檔案分享所參照(reference)的位置。意思是說：監控服務器 log_shipping_secondaries 資料表內原先參照舊次要服務器的資料會被刪除。而在 log_shipping_primaries 資料表內則是將舊主要服務器名稱更改為新主要服務器名稱。此預存程序並不會將資料新增到 log_shipping_secondarIEs 資料表，因為新的配對服務器目前尚未建置。
程序代碼列表 3： 將角色互換結果通知監控服務器之預存程序。
步驟 5: 在次要服務器上解析登入帳號 您必須先在新主要服務器上解析舊主要服務器登入帳號，使用者才可以存取新主要服務器；方式是使用步驟1所匯出之登入帳號檔案。此匯出檔案可被 sp_resolve_logins 預存程序所讀取，然後解析各服務器間 SID 的差異。舉例來說，程序代碼列表4示范如何在新復原的 Pubscopy 數據庫上執行 sp_resolve_logins 預存程序，去解析原來的登入帳號。BOL文章曾教導您必須在目的數據庫內才能執行該預存程序。事實上，sp_resolve_logins 使用了非完整式參照(unqualifIEd reference)指向 syslogins 視觀表，所以您必須在 master 數據庫內才能執行此預存程序！
程序代碼列表4： 在次要服務器上解析登入帳號的預存程序。
為了達成完整的日志傳送角色互換，您只需在新主要服務器與新次要服務器之間重新設定一次日志傳送即可。因為新主要服務器已內含嶄新的數據庫維護計劃，您將會傾向在維護計劃內直接加入新次要服務器，做為目的服務器。然而經過多次嘗試之後，我發現新主要服務器的 "交易日志備份工作" 總是會失敗，並且日志也不會從新主要服務器傳送到新次要服務器。
所以，您需要另外一種方法。您在執行過日志傳送角色變更的預存程序，以及先前我詳細說明的步驟後，就可以直接達成完整的角色互換 - 在新主要服務器與新次要服務器之間建置一份新的日志傳送計劃。為了建置該計劃，您需遵循下列步驟：
1. 在新主要服務器的數據庫維護計劃內移除日志傳送功能。
2. 在主要服務器上刪除數據庫維護計劃。
3. 在次要服務器上刪除數據庫維護計劃。
4. 維持所有交易日志文件。
5. 在新主要服務器上建立一個新的數據庫維護計劃，指定新次要服務器所在、目的數據庫位置、以及交易日志文件之適當存放位置，如同我在 Part 1所介紹的內容。
6. 重新開始新主要服務器的所有活動。
在您成功設定角色互換且建置新日志傳送配對服務器之後，Enterprise Manager 的日志傳送監視器可能會告知您新次要服務器數據庫並未與新主要服務器數據庫取得同步(out of sync)。如果 "最近一次加載的交易日志" 與 "最近一次備份的交易日志" 之間的時間差超過了 out-of-sync 設定值，您就會收到此報告。直到最近一次的備份資料被加載之後，日志傳送監視器就會回到平常無錯誤狀態。
日志傳送監視器所在位置
Microsoft 強烈建議將日志傳送監視器置放於獨立服務器上。如此一來，無論主要服務器或是次要服務器執行工作失敗時，該監視器都會送出警示(alert)。如果監視器位於主要或次要服務器其中之一，報告結果將取決於監視器所在服務器。如果監視器所在服務器因故停擺，它將無法繼續回報可能的錯誤情況。所以，要讓監視器獨立回報日志傳送系統內主要或次要服務器上可能發生的問題，給予監視器一**立服務器是較佳的實作方式。此外，也可以使用這**立的監控服務器去監控其它日志傳送配對服務器。
如果沒有其它服務器可安裝監控程序，而需要放在主要或次要服務器其中之一。究竟應該把日志傳送監視器放在哪台服務器呢？因為重點是想偵測主要服務器上可能發生的日志傳送問題，所以放在次要服務器比較妥當。如果將日志傳送監視器放在主要服務器上，當主要服務器停擺時，您就無法使用該監視器，監視器也無法在日志傳送發生問題時送出警示。所以呢，如果只有兩台服務器可使用，次要服務器為置放日志傳送監視器較佳的位置。某些時候，為避免災難發生時影響次要服務器，必須將交易日志從某一實體位置傳送到另一個地方(也許有一段距離)。在此情況下，日志傳送監視器最好放在其它地方的獨立服務器，讓災難發生時不至於影響主要與次要服務器。
