角色變更、角色互換、以及監(jiān)控服務(wù)器所在位置

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

角色變更

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

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

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

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

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

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

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

程序代碼列表 2：將次要服務(wù)器數(shù)據(jù)庫升級成主要服務(wù)器數(shù)據(jù)庫之預(yù)存程序。USE masterGOEXEC 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

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

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

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

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

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

轉(zhuǎn)摘《DigJim的專欄》——實在精典，希望更多的人學(xué)習(xí)，資源共享