角色變更、角色互換、以及監控服務器所在位置

    當線上數據庫停擺時(可能是計劃內維護工作，或是預期外的狀況)，如果還有備援服務器上的數據庫可供存取，您可能會比較安心一點。一個設計良好的日志傳送系統(將數據庫交易日志文件從主要服務器傳送到備援服務器)即可給予您這樣的自信心。內建于 SQL Serve 2000 企業板與開發版的 Enterprise Manager 工具程序即支持日志傳送功能。

角色變更

    將日志從主要服務器傳送到次要服務器之后，您可在必要時以次要服務器置換掉主要服務器。如果主要服務器發生問題，或是計劃性停擺(例如升級硬件或安裝修正程序)，線上數據庫就必須停止服務一段期間。此時您可以變更次要服務器上數據庫之角色，讓它取代主要服務器之后進而成為線上數據庫。SQL Server 2000 線上手冊(Books Online，BOL)將此項操作稱為日志傳送角色變更(log shipping role change)。在日志傳送過程里，次要服務器需設定在無法復原(nonrecovered)狀態，因此交易日志才能從主要服務器回存到次要服務器(一但您將數據庫復原，就不能再回存交易記錄)。變更角色時，您需將次要服務器的數據庫予以復原，并標示其為新主要服務器數據庫。您也可以將舊主要服務器數據庫設定為新次要服務器數據庫。如果舊主要服務器數據庫并未損壞，那么就可以在新主要服務器與舊主要服務器(已變成新次要服務器)之間重新建置日志傳送功能。這種切換方式我們稱為角色互換(role reversal)。

    這些操作指引可修訂為六個基本步驟，分別為： 1、轉移與匯出登入帳號，2、降級(demote)主要服務器，3、升級(promote)次要服務器，4、通知監控服務器角色已變更，5、在次要服務器上解析登入帳號，6、以及連結數據庫存取與權限。

    步驟 1: 轉移與匯出登入帳號 首先，BOL 建議您建立一個SQL Server 2000 DTS封裝(package)，用來將主要服務器的登入帳號轉移到次要服務器，且執行各服務器間登入帳號SID之解析動作。轉移登入帳號所用的 DTS Transfer Logins Task只能在 SQL Server 2000 DTS Designer內使用。您可在主要服務器上建立與儲存 DTS 封裝，然后呼叫 dtsrun.exe 設定該封裝的執行方式 — 透過主要服務器 SQL Server Agent 的工作(job)。該封裝執行時會將登入帳號從某服務器傳送到另一服務器，但是它并不會解析其登入帳號的SID(在稍后步驟中會說明為何需解析登入帳號)。然而，為了在稍后能順利解析登入帳號，您必須先建立一個檔案，其內包含主要服務器 syslogins 資料表的匯出資料。

    匯出登入帳號到次要服務器時，BOL建議您建立一個兩階段的SQL Server Agent工作：使用bcp匯出，以及復制登入帳號。在第一個步驟，您將使用原始模式的bcp將登入帳號匯出至某個檔案。而在第二個步驟里，您必須將登入帳號復制到次要服務器的某個檔案，以便稍后進行角色變更時可用來解析登入帳號。在步驟5您將使用 sp_resolve_logins 預存程序去解析次要服務器上登入帳號的SID。該工作建立完成后，就可以定期地執行(例如每晚執行一次)。如此一來次要服務器上將隨時保留最新的登入帳號匯出文件，以便進行日志傳送角色變更。

    步驟 2: 降級主要服務器 為了讓主要服務器不再是日志傳送系統的資料來源，您必須將它”降級”。您可以降級主要服務器的來源數據庫，讓它變成潛在的次要服務器。然后在主要服務器上執行sp_change_primary_role 預存程序，目的是移除原有日志傳送功能。程序代碼列表1顯示該預存程序如何把 Pubscopy 日志傳送數據庫從讀/寫模式更改成只讀備援模式，準備隨時接受交易日志之備份資料。該預存程序經由數個步驟后會在日志傳送計劃內刪除主要服務器數據庫。傳入的參數將告之預存程序需執行以下工作：備份最近一次的交易日志、結束數據庫內所有使用者聯機、將數據庫設定在備援狀態與多使用者存取層級。預存程序的回傳代碼將標示 BACKUP LOG 敘述句是否成功執行。

    程序代碼列表1：將日志傳送數據庫從讀/寫模式降級成只讀模式之預存程序。
USE master
GO
EXEC msdb.dbo.sp_change_primary_role
       @db_name = 'Pubscopy',
       @backup_log = 1,
       @terminate = 1,
       @final_state = 3,
       @access_level = 1

    步驟 3: 升級次要服務器 下一個步驟是把目前次要服務器升級成復原狀態(recovered state)，這樣它才能取代原先的線上數據庫，且變成潛在日志傳送主要服務器數據庫。在次要服務器上，如果您已確認無任何使用者繼續存取數據庫，就可以執行 sp_change_secondary_role 預存程序，如程序代碼列表2所示：

    程序代碼列表 2：將次要服務器數據庫升級成主要服務器數據庫之預存程序。
USE master
GO
EXEC msdb.dbo.sp_change_secondary_role
       @db_name = 'Pubscopy',
       @do_load = 1,
       @force_load = 1,
       @final_state = 1,
       @access_level = 1,
       @terminate = 1,
       @keep_replication = 0,
       @stopat = null

    這些參數將促使該預存程序嘗試將所有剩余的交易日志文件從原先主要服務器復制到次要服務器，并將這些日志文件加載次要服務器數據庫。參數 @do_load=1 會進行最近一次備份，并加載所有交易日志文件；參數 @force_load=1 是在執行 sqlmaint.exe 時指定尚未文件化的 Forceload 選項；參數 @final_state=1 將新主要服務器數據庫設定為復原模式；參數 @access_level 將存取方式設回先前多使用者狀態。參數 @terminate=1 則促使該預存程序中斷所有使用者的數據庫存取動作 — 方式是執行 ALTER DATABASE 配合 IMMEDIATE 選項。然而，如果執行此預存程序時，您自己的 Enterprise Manager 與數據庫間聯機處于開啟狀態，ALTER DATABASE 動作將會失敗。所以您必須以手動方式確認是否已將所有數據庫聯機予以中斷。最后，如果該數據庫被設定為數據庫復寫(replication)之出版者數據庫(publisher)，那么 @keep_replication=0 參數將依舊維持服務器上所有復寫設定。

    假如您曾選擇讓次要服務器成為未來潛在的主要服務器，則數據庫維護計劃會在次要服務器上建置一個交易日志備份工作(SQL Server Agent 的transaction-log backup job)。該工作激活之后，交易日志備份文件就會開始出現在新主要服務器。您需要這些檔案去重新設定將日志傳送回新次要服務器。

    Step 4: 通知監控服務器角色已變更 SQL Server 2000 的日志傳送會在監控服務器上安裝監控工具程序；最好是在第三臺服務器。為了通知監控服務器日志傳送的角色已經過變更，您必須在監控服務器上執行 sp_change_monitor_role 預存程序，如程序代碼列表3所示。盡管名稱內含有 change 字眼，但它并不會變更監控服務器的角色。相反地，此預存程序會變更主要/次要服務器內檔案分享所參照(reference)的位置。意思是說：監控服務器 log_shipping_secondaries 資料表內原先參照舊次要服務器的資料會被刪除。而在 log_shipping_primaries 資料表內則是將舊主要服務器名稱更改為新主要服務器名稱。此預存程序并不會將資料新增到 log_shipping_secondaries 資料表，因為新的配對服務器目前尚未建置。
 
       程序代碼列表 3： 將角色互換結果通知監控服務器之預存程序。
USE master
GO
EXEC msdb.dbo.sp_change_monitor_role
      @primary_server = 'oahu\sql2k_1' ,
      @secondary_server = 'oahu\sql2k_2',
      @database = 'Pubscopy',
      @new_source = 'oahu\sql2k_2'
 
       步驟 5: 在次要服務器上解析登入帳號 您必須先在新主要服務器上解析舊主要服務器登入帳號，使用者才可以存取新主要服務器；方式是使用步驟1所匯出之登入帳號檔案。此匯出檔案可被 sp_resolve_logins 預存程序所讀取，然后解析各服務器間 SID 的差異。舉例來說，程序代碼列表4示范如何在新復原的 Pubscopy 數據庫上執行 sp_resolve_logins 預存程序，去解析原來的登入帳號。BOL文章曾教導您必須在目的數據庫內才能執行該預存程序。事實上，sp_resolve_logins 使用了非完整式參照(unqualified reference)指向 syslogins 視觀表，所以您必須在 master 數據庫內才能執行此預存程序！
 
        程序代碼列表4： 在次要服務器上解析登入帳號的預存程序。
USE master
GO
EXEC sp_resolve_logins
      @dest_db = 'Pubscopy',
      @dest_path = 'd:\',
      @filename = 'syslogins.dat'
 
        步驟 6: 連結數據庫存取與權限 BOL 對于角色變更的相關討論僅止于步驟5，但是它忽略一個重要步驟：在 "數據庫存取權限" 與 "轉移后登入帳號" 之間進行協調動作。為了在新主要服務器內線上數據庫，將移轉后已解析的登入帳號連結至相對應的數據庫使用者及其權限，您必須執行針對每個登入帳號執行一次 sp_change_users_login 預存程序。
 
USE pubscopy
GO
EXEC sp_change_users_login 'Update_One', 'UserName', 'LoginName'
 
        執行該預存程序可確保 SQL Server 登入帳號能夠正確地連結相對應的數據庫使用者名稱。
 
        到此為止，您已經成功地將次要服務器升級為新的角色，而舊主要服務器也早已變成次要服務器。然而，您仍然尚未建置新的日志傳送關系。您完成的只是角色變更，而不是角色互換。
 
角色互換

        為了達成完整的日志傳送角色互換，您只需在新主要服務器與新次要服務器之間重新設定一次日志傳送即可。因為新主要服務器已內含嶄新的數據庫維護計劃，您將會傾向在維護計劃內直接加入新次要服務器，做為目的服務器。然而經過多次嘗試之后，我發現新主要服務器的 "交易日志備份工作" 總是會失敗，并且日志也不會從新主要服務器傳送到新次要服務器。
 
        所以，您需要另外一種方法。您在執行過日志傳送角色變更的預存程序，以及先前我詳細說明的步驟后，就可以直接達成完整的角色互換 - 在新主要服務器與新次要服務器之間建置一份新的日志傳送計劃。為了建置該計劃，您需遵循下列步驟：
1.        在新主要服務器的數據庫維護計劃內移除日志傳送功能。
2.        在主要服務器上刪除數據庫維護計劃。
3.        在次要服務器上刪除數據庫維護計劃。
4.        維持所有交易日志文件。
5.        在新主要服務器上建立一個新的數據庫維護計劃，指定新次要服務器所在、目的數據庫位置、以及交易日志文件之適當存放位置，如同我在 Part 1所介紹的內容。
6.        重新開始新主要服務器的所有活動。
 
        在您成功設定角色互換且建置新日志傳送配對服務器之后，Enterprise Manager 的日志傳送監視器可能會告知您新次要服務器數據庫并未與新主要服務器數據庫取得同步(out of sync)。如果 "最近一次加載的交易日志" 與 "最近一次備份的交易日志" 之間的時間差超過了 out-of-sync 設定值，您就會收到此報告。直到最近一次的備份資料被加載之后，日志傳送監視器就會回到平常無錯誤狀態。
 
日志傳送監視器所在位置

      Microsoft 強烈建議將日志傳送監視器置放于獨立服務器上。如此一來，無論主要服務器或是次要服務器執行工作失敗時，該監視器都會送出警示(alert)。如果監視器位于主要或次要服務器其中之一，報告結果將取決于監視器所在服務器。如果監視器所在服務器因故停擺，它將無法繼續回報可能的錯誤情況。所以，要讓監視器獨立回報日志傳送系統內主要或次要服務器上可能發生的問題，給予監視器一臺獨立服務器是較佳的實作方式。此外，也可以使用這臺獨立的監控服務器去監控其它日志傳送配對服務器。
 
        如果沒有其它服務器可安裝監控程序，而需要放在主要或次要服務器其中之一。究竟應該把日志傳送監視器放在哪臺服務器呢？因為重點是想偵測主要服務器上可能發生的日志傳送問題，所以放在次要服務器比較妥當。如果將日志傳送監視器放在主要服務器上，當主要服務器停擺時，您就無法使用該監視器，監視器也無法在日志傳送發生問題時送出警示。所以呢，如果只有兩臺服務器可使用，次要服務器為置放日志傳送監視器較佳的位置。某些時候，為避免災難發生時影響次要服務器，必須將交易日志從某一實體位置傳送到另一個地方(也許有一段距離)。在此情況下，日志傳送監視器最好放在其它地方的獨立服務器，讓災難發生時不至于影響主要與次要服務器。

關鍵字：服務器、SQL Server 2000、日志