升級日誌運送至 2014 SQL Server（Transact-SQL）

從 SQL Server 2005、SQL Server 2008、SQL Server 2008 R2 或 SQL Server 2012 升級到 SQL Server 2014 時，可以保留日誌運送設定。 本主題描述升級原木運輸配置的替代情境與最佳實務。

升級前保護你的資料

作為最佳實務，我們建議您在日誌運送升級前先保護好您的資料。

為了保護你的資料

1. 對每個主要資料庫進行完整的資料庫備份。

   如需詳細資訊，請參閱建立完整資料庫備份 (SQL Server)。

2. 對每個主要資料庫執行 DBCC 的 CHECKDB 指令。

升級監控伺服器實例

監控伺服器實例（如有）可隨時升級。

在監控伺服器升級期間，日誌運送設定仍可正常運作，但其狀態不會被記錄在監控器上的表格中。 任何已設定的警報在監控伺服器升級期間都不會被觸發。 升級後，你可以透過執行 sp_refresh_log_shipping_monitor 系統儲存程序來更新監控表中的資訊。

以單一次要伺服器升級日誌運送配置

本節所述的升級流程假設由主伺服器與一台次要伺服器組成的配置。 此配置在下圖中表示，顯示一個主要伺服器實例 A 與一個次要伺服器實例 B。

關於升級多台次級伺服器的資訊，請參見本主題後面 的「升級多個次級伺服器實例」。

升級次要伺服器實例

升級過程涉及先將 SQL Server 2005 或更高版本日誌運送設定的次要伺服器實例升級至 SQL Server 2014，然後再升級主要伺服器實例。 一定要先升級次要伺服器實例。 若主要伺服器在次級伺服器之前升級，日誌運送將失敗，因為在較新版本 SQL Server 上建立的備份無法在舊版 SQL Server 上還原。

日誌的傳送會在整個升級過程中持續進行，因為升級後的次級伺服器會持續還原來自 SQL Server 2005 或更高版本主伺服器的日誌備份。 升級次要伺服器實例的過程部分取決於日誌運送配置是否擁有多個次要伺服器。 欲了解更多資訊，請參閱本主題後面 的「升級多個次級伺服器實例」。

在次要伺服器實例升級期間，日誌的複製與還原工作不會執行，因此未還原的交易日誌備份會累積。 累積的數量取決於主伺服器排程備份的頻率。 此外，若已設定獨立監控伺服器，可能會發出警示，表示還原時間未超過設定間隔。

當次要伺服器升級完成後，日誌運送代理的工作會恢復，並持續從主要伺服器實例 A 複製與還原日誌備份。次級伺服器更新次級資料庫所需的時間會依次級伺服器升級所需時間及主要伺服器備份的頻率而異。

升級主要伺服器實例

在規劃升級時，一個重要考量是資料庫無法使用的時間長短。 最簡單的升級情境是，在你升級主要伺服器期間，資料庫無法使用（情境一，見下文）。

雖然升級過程較複雜，但你可以先將 SQL Server 2005 或更高版本的主伺服器故障轉移到 SQL Server 2014 的次要伺服器，再升級原始主伺服器（下文情境二），以最大化資料庫可用性。 故障轉移情境有兩種變體。 你可以切回原本的主要伺服器，並保留原本的日誌運送設定。 或者，你可以先移除原本的日誌運送設定，再升級原本的主伺服器，之後再用新的主伺服器建立新的設定。 本節描述這兩種情境。

情境一：無故障轉移升級主要伺服器實例

這是較簡單的情況，但會造成比故障轉移更多的停機時間。 主要伺服器實例只是升級，而在升級期間資料庫無法使用。

伺服器升級後，資料庫會自動重新上線，進而進行升級。 資料庫升級後，日誌運送工作會恢復。

情境二：透過故障轉移升級主要伺服器實例

此情境最大化可用性並減少停機時間。 它利用受控的備援切換到次要伺服器實例，讓資料庫在原始主要伺服器實例升級時保持可用。 停機時間僅限於故障轉移所需的相對短時間，而非升級主要伺服器實例所需的時間。

透過故障轉移升級主要伺服器實例包含三個一般程序：對次級伺服器執行受控故障轉移、將原始主要伺服器實例升級至 SQL Server 2014，以及在 SQL Server 2014 主伺服器實例上設定日誌出土。 這些程序在本節中有詳細說明。

程序 1：執行受控故障轉移至次要伺服器

受控備援轉移至次要伺服器：

1. 手動對主要資料庫執行交易日誌 的尾部備份 ，並指定「WITH NORECOVERY」。 此日誌備份會擷取尚未備份的日誌紀錄，並讓資料庫離線。 請注意，當資料庫離線時，日誌備份工作會失敗。

   以下範例在主伺服器上建立資料庫的尾部日誌備份 AdventureWorks 。 備份檔案命名 Failover_AW_20080315.trn為：

   BACKUP LOG AdventureWorks 
     TO DISK = N'\\FileServer\LogShipping\AdventureWorks\Failover_AW_20080315.trn' 
      WITH NORECOVERY;
   GO
   

   我們建議您使用不同的檔案命名規則，以區分手動建立的備份檔案與日誌運送備份工作所建立的備份檔案。

2. 在次要伺服器上：

   1. 確保所有由日誌運送備份工作自動執行的備份都已套用。 要檢查已套用哪些備份工作，請使用監控伺服器或主、次伺服器上的 sp_help_log_shipping_monitor 系統儲存程序。 同一個檔案應該列在 last_backup_file、 last_copied_file和 last_restored_file 欄。 如果任何備份檔案尚未被複製並還原，請手動呼叫代理複製與還原工作，以進行日誌運送設定。

      關於開始工作相關的資訊，請參見 「開始一份工作」。

   2. 複製你在第一步建立的最終日誌備份檔案，從檔案分享到次級伺服器日誌傳送所使用的本地位置。

   3. 還原最終的日誌備份，並指定 WITH RECOVERY，以讓資料庫上線。 作為上線的一部分，資料庫將升級至 SQL Server 2014。

      以下範例將資料庫的尾部日誌備份 AdventureWorks 存放於次級資料庫。 範例中使用了 WITH RECOVERY 選項，能讓資料庫上線：

      RESTORE LOG AdventureWorks 
        FROM DISK = N'c:\logshipping\Failover_AW_20080315.trn' 
         WITH RECOVERY;
      GO
      

      Note

      對於包含多於一台次要伺服器的配置，還有其他考量。 欲了解更多資訊，請參閱本主題後面 的「升級多個次級伺服器實例」。

   4. 透過將用戶端從原始主伺服器（伺服器 A）重新導向至線上的次要伺服器（伺服器 B）來進行故障轉移。

   5. 請注意，當資料庫上線時，次級資料庫的交易記錄不會被填滿。 為了防止交易記錄被填滿，你可能需要備份。 如果是的話，我們建議你把備份備份到一個共用位置，也就是 備份共享，這樣備份就能在另一個伺服器實例上還原。

步驟二：將原始主要伺服器實例升級至 SQL Server 2014

當你將原始主要伺服器實例升級到 SQL Server 2014 後，資料庫仍會離線且格式不變。

步驟三：在 SQL Server 2014 上設定日誌運送

升級流程的其餘部分取決於原木運送是否仍設定，具體如下：

• 如果你保留了 SQL Server 2005 或更高版本的日誌運送設定，請切回原本的主要伺服器實例。 更多資訊請參閱本節後面的 「切回原始主要伺服器實例」。

• 如果你在失敗轉移前移除了日誌運送設定，請建立一個新的日誌運送設定，讓原本的次要伺服器實例成為新的主要伺服器實例。 欲了解更多資訊，請參閱本節後面的「 如何將舊的次要伺服器實例保留為新的主伺服器實例」。

切換回原始主要伺服器實例

1. 在臨時主伺服器（伺服器 B）上，使用 WITH NORECOVERY 備份日誌尾部，建立尾部日誌備份，並將資料庫離線。 尾部日誌備份稱為 Switchback_AW_20080315.trn。例如：

   BACKUP LOG AdventureWorks 
     TO DISK = N'\\FileServer\LogShipping\AdventureWorks\Switchback_AW_20080315.trn' 
      WITH NORECOVERY;
   GO
   

2. 如果除了你在第一步建立的尾部備份外，還有在臨時主資料庫上備份過任何交易日誌，請用 NORECOVERY 還原這些日誌備份到原本主伺服器（伺服器 A）上的離線資料庫。 當第一次日誌備份恢復時，資料庫會升級為 SQL Server 2014 格式。

3. 在原始主資料庫（伺服器 A）上還原尾日誌備份， Switchback_AW_20080315.trn使用 WITH RECOVERY 來讓資料庫上線。

4. 透過將用戶端從原始主伺服器重新導向至線上的次要伺服器，將故障切換回原始的主要資料庫（伺服器 A）。

資料庫上線後，原始日誌運送設定將恢復。

將舊的次要伺服器實例保留為新的主伺服器實例

建立新的日誌運送設定，使用舊的次要伺服器實例 B 作為主要伺服器，舊的主要伺服器實例 A 作為新的次要伺服器，具體如下：

1. 為避免在新的次級伺服器（伺服器 A）上執行完整的備份與還原資料庫，請將新的主資料庫的日誌備份套用到新的次級資料庫。 在範例配置中，這涉及將伺服器 B 上的日誌備份還原到伺服器 A 的資料庫。

2. 從新的主資料庫（伺服器 B 上）備份日誌。

3. 用 NORECOVERY 還原日誌備份到新的次要伺服器實例（伺服器 A）。 第一個還原操作會將資料庫更新到 SQL Server 2014。

4. 設定日誌運送，將原本的次要伺服器（伺服器 B）作為主要伺服器實例。

   Important

   如果你使用 SQL Server Management Studio，請指定次要資料庫已經初始化。

   如需詳細資訊，請參閱設定記錄傳送 (SQL Server)。

5. 透過將用戶端從原始主伺服器（伺服器 A）重新導向至線上的次要伺服器（伺服器 B）來進行故障轉移。

   Important

   當你切換到新的主要資料庫時，應確保其元資料與原始主要資料庫的元資料一致。 如需詳細資訊，請參閱在另一個伺服器執行個體 (SQL Server) 上提供可用的資料庫時，管理中繼資料。

升級多個次要伺服器實例

此配置在下圖中呈現，顯示一個主要伺服器實例 A，以及兩個次要伺服器實例 B 和 C。

本節討論如何透過故障轉移升級，然後切回原本的主要伺服器。 當有多個次要伺服器實例時，透過故障轉移升級主實例的過程會更複雜。 在以下程序中，所有次要伺服器升級完成後，主伺服器會切換到升級後的次要資料庫之一。 原本的主要伺服器會升級，日誌傳送會失敗回傳回去。

要用故障切換升級，再切回原本的主要伺服器

1. 升級所有次要伺服器實例（伺服器 B 和伺服器 C）。

2. 取得主要資料庫（伺服器 A 上）交易日誌的尾端，並透過 WITH NORECOVERY 備份交易日誌，將資料庫離線。

3. 在你計畫故障轉移的次要伺服器（伺服器 B）上，透過 WITH RECOVERY 還原日誌備份，讓次級資料庫上線。

4. 在其他所有次要伺服器（伺服器 C）上，透過使用 WITH NORECOVERY 還原日誌備份，讓次級資料庫離線。

   Note

   日誌的複製與還原工作會在次要伺服器上執行，但這些工作不會做任何事，因為新的日誌備份檔案不會被放到備份共享中。

5. 透過將用戶端從原始主伺服器（伺服器 A）重新導向至線上的次要伺服器（伺服器 B）來進行故障轉移。 線上資料庫成為臨時主伺服器，在原始主伺服器離線（伺服器 A）時保持資料庫可用。

6. 升級原本的主要伺服器（伺服器 A）。

7. 在你失敗的臨時主資料庫（伺服器 B 上）上，手動用 WITH NORECOVERY 備份交易日誌。 這會讓資料庫離線。

8. 用 NORECOVERY 還原你在臨時主資料庫（伺服器 B）建立的所有交易日誌備份到其他所有次要資料庫（伺服器 C）。 這使得日誌傳輸可在原始主要資料庫升級後繼續，無需對每個次要資料庫進行完整資料庫還原。

9. 使用WITH RECOVERY將交易日誌從臨時主伺服器（伺服器B）還原到原始主要資料庫（伺服器A上）。

重新部署原木運輸

如果你不想用上述步驟遷移日誌運送設定，可以透過重新初始化次要資料庫並完整備份並還原，從頭重新部署日誌運送。 如果你的資料庫規模較小，或升級過程中高可用性並非關鍵，這可能是個理想的選擇。

關於啟用日誌運送的資訊，請參閱設定日誌運送（SQL Server）。

另請參閱

交易日誌備份（SQL Server）應用交易日誌備份（SQL Server）日誌運送資料表與儲存程序