SQL Server Log Shipping學習總結
SQL Server的日誌傳送（log shipping）技術一直比較雞肋，尤其當SQL Server 推出了Always On技術以後，估計使用日誌傳送（log shipping）這種技術方案的企業越來越少，但是日誌傳送也有自己的一些優點，有些特殊場景或業務背景下也有其存在的價值。最近由於特殊業務場景可能需要用到這個技術，所以做了一些測試和驗證，比對一些知識做了一下總結、歸納。下面有部分內容從官方文件摘抄。此篇是總結性內容。如有不足，敬請指點！
日誌傳送 （ Log Shipping ）介紹
SQL Server 使用日誌傳送，可以自動將 “ 主伺服器 ” 例項上 “ 主資料庫 ” 上的事務日誌備份傳送到 “ 輔助伺服器 ” 例項上的一個或多個 “ 輔助資料庫 ” 。
事務日誌備份分別應用於每個輔助資料庫。 可選第三個伺服器例項（稱為 “ 監視伺服器 ” ）記錄備份和還原操作的歷史記錄及狀態，還可以在無法按計劃
執行這些操作時引發警報。
事務日誌傳送提供了資料庫級別的高可用性保護。日誌傳送可用來維護相應生產資料庫（稱為 “ 主資料庫 ” ）的一個或多個備用資料庫（稱為 “ 輔助資料庫 ” ）。發生故障轉移之前，必須通過手動應用全部未還原的日誌備份來完全更新輔助資料庫。日誌傳送具有支援多個備用資料庫的靈活性。如果需要多個備用資料庫，可以單獨使用日誌傳送或將其作為資料庫映象的補充。當這些解決方案一起使用時，當前資料庫映象配置的主體資料庫同時也是當前日誌傳送配置的主資料庫。
日誌傳送的拓撲結構圖如下所示：
優點：
可以為單個主資料庫配置一個或多個輔助資料庫（每個資料庫都位於單獨的 SQL Server 例項上），提供災難恢復解決方案。
支援對輔助資料庫的受限的只讀訪問許可權（在還原作業之間的間隔期間）。可做簡單的讀寫分離。
允許使用者將延遲時間定義為：從主伺服器備份主資料庫日誌到輔助伺服器必須還原（應用）日誌備份之間的時間。 例如，如果主資料庫上的資料被意外更改，則較長的延遲會很有用。 如果很快發現意外更改，則通過延遲，您可以在輔助資料庫反映此更改之前從其中檢索仍未更改的資料
缺點：
容易出現異常，導致資料不一致。而且出現異常後基本無法補救，需要重新初始化。
日誌傳送配置不會自動從主伺服器故障轉移到輔助伺服器。 如果主資料庫變為不可用，需要手動將輔助資料庫聯機。
沒有自我糾錯、自我驗證的處理機制。
資料同步有延遲。
相關術語（摘自官方文件）
主伺服器 ( primary server )
位於生產伺服器上的 SQL Server 例項。
主資料庫 ( primary database )
希望備份到其他伺服器的主伺服器上的資料庫。 通過 SQL Server Management Studio 進行的所有日誌傳送配置管理都是在主資料庫中執行的。
輔助伺服器 ( secondary server )
想要在其上保留主資料庫的熱備副本的 SQL Server 例項。
輔助資料庫 ( secondary database )
主資料庫的熱備用副本。 輔助資料庫可以處於 RECOVERING 狀態或 STANDBY 狀態，這將使資料庫可用於受限的只讀訪問。
監視伺服器 ( monitor server )
跟蹤日誌傳送的所有詳細資訊的 SQL Server 的可選例項，包括：
主資料庫中事務日誌最近一次備份的時間。
輔助伺服器最近一次複製和還原備份檔案的時間。
有關任何備份失敗警報的資訊。
備份作業
一種 SQL Server 代理作業，它執行備份操作，將歷史記錄資訊記錄到本地伺服器和監視伺服器上，並刪除舊的備份檔案和歷史記錄資訊。
啟用日誌傳送後，將在主伺服器例項上建立作業類別 “ 日誌傳送備份 ” 。
複製作業
一種 SQL Server 代理作業，它將備份檔案從主伺服器複製到輔助伺服器中的可配置目標，並在輔助伺服器和監視伺服器中記錄歷史記錄。
在資料庫上啟用日誌傳送後，將在日誌傳送配置中在各輔助伺服器上建立作業類別 “ 日誌傳送複製 ” 。
還原作業
一種 SQL Server 代理作業，它將複製的備份檔案還原到輔助資料庫。它將歷史記錄資訊記錄在本地伺服器和監視伺服器上，並刪除舊檔案和舊歷史記錄資訊。 在資料庫上啟用日誌傳送後，在輔助伺服器例項上會建立作業類別 “ 日誌傳送還原 ” 。
警報作業
一種 SQL Server 代理作業，它在備份或還原操作在指定閾值內未成功完成時為主資料庫和輔助資料庫引發警報。 在資料庫上啟用日誌傳送後，在監視伺服器例項上會建立作業類別 “ 日誌傳送警報 ” 。
配置日誌傳送 （ Log Shipping ） 的先決條件
· 主資料庫必須使用完整恢復模式或大容量日誌恢復模式，將資料庫切換為簡單恢復模式會導致日誌傳送停止工作。
· 在配置日誌傳送之前，您必須建立共享，以便輔助伺服器可以訪問事務日誌備份。 這是對生成事務日誌備份的目錄的共享。
例如，如果將事務日誌備份到目錄 C:\data\tlogs\ ，則可以對該目錄建立 \\primaryserver\tlogs 共享
配置日誌傳送 （ Log Shipping ） 的許可權要求
日誌傳送的相關儲存過程要求有 sysadmin 伺服器角色的許可權。
配置日誌傳送 （ Log Shipping ） 的步驟操作
注意：日誌傳送配置比較簡單，下面很多簡單介紹，不做詳細介紹。
1: 在主伺服器（ primary server ） 上，選擇要配置日誌傳送的主資料庫 （ primary database ） ，然後右鍵單擊資料庫，在選項 ” 事務日誌傳送 “
裡面選擇勾選下圖選項
2 ：配置事務日誌備份
這裡的選項都很簡單，但是必須根據實際情況配置修改。需要注意的是共享路徑的配置。注意事項，請注意認證讀一遍。
思考：如果勾選 “ 禁用這個作業 ” 是否可行？ 是否可以用其它的備份呢？
2 ：配置輔助資料庫
配置輔助資料庫，在輔助資料庫選項中點選新增來新增輔助資料庫，可以新增多個輔助資料庫。
注意：有時候可能會遇到許可權問題 “ Operating system error 5(Access is denied.) ” ，遇到這個問題的原因五花八門，例如這個案例當中，就是因為 SQL Server 例項是用內建賬號 Network Service 啟動的，可以使用其它賬號，例如域賬號或者 Local System 賬號就不會遇到這個問題。
Cannot open backup device '\\192.168.27.108\DB_BACKUP\LOG_BACKUP\MyDB......'. Operating system error 5(Access is denied.).
RESTORE FILELIST is terminating abnormally. (Microsoft SQL Server, Error: 3201)
配置日誌傳送 （ Log Shipping ）的 注意事項
1: 如果資料庫是 “ 備用模式 ” （ Standby/Read-Only ），那麼資料庫就是隻讀模式。
關於輔助資料庫（ secondary database ）能否執行儲存過程。可以執行部分儲存過程，但是有限制。
如果 “ 輔助資料庫 ” 是 Standby 模式，那麼如果儲存過程裡面有 DML 操作的話，那麼儲存過程執行報錯。所以做為讀寫分離的時候，還是有一些限制的！這個需要特別注意！
2: 主伺服器上的完整備份是否影響日誌傳送（ Log Shipping ）呢？
實驗測試是不會。
3 ： Log Shipping 的備份作業之外的其它事務日誌備份是否影響、干擾日誌傳送（ Log Shipping ）呢？
實驗測試這個是會導致 log shipping 中斷。
是否可以不用 Log Shipping 的事務日誌備份作業（禁用這個作業），使用其它事務日誌備份作業。
實驗測試是不行。
如果對應目錄有主資料庫的事務日誌備份，是否會被全部 Copy 到輔助伺服器？如果輔助伺服器有之前的舊事務日誌備份，是否會被全部應用還原？
4 ：主伺服器與輔助伺服器的 SQL Server 版本是否可以不一致呢？
答案是主伺服器與輔助伺服器的 SQL Server 版本可以不一致，但是在不一致的情況下，輔助資料庫只能選擇無恢復模式（ No Recovery Module ）而不能使用
備用模式。否則會報類似下面的錯誤：
Msg 3180, Level 16, State 1, Line 2
This backup cannot be restored using WITH STANDBY because a database upgrade is needed. Reissue the RESTORE without WITH STANDBY.
Msg 3013, Level 16, State 1, Line 2
RESTORE DATABASE is terminating abnormally.
注意： 這裡所說的 SQL Server 版本不一致，只能是輔助伺服器的 SQL Server 版本比主伺服器的 SQL Server 版本高。
日誌傳送刪除
SSMS UI 介面操作（當然也可以使用指令碼，不過這裡UI介面操作比較簡單）：
1. 連線到當前日誌傳送主伺服器的 SQL Server 例項並展開該例項。
2. 展開 “ 資料庫 ” ，右鍵單擊日誌傳送主資料庫，再單擊 “ 屬性 ” 。
3. 在 “ 選擇頁 ” 下，單擊 “ 事務日誌傳送 ” 。
4. 取消 “ 將此資料庫啟用為日誌傳送配置中的主資料庫 ” 複選框。
5. 單擊 “ 確定 ” ，從此主資料庫中刪除日誌傳送。
日誌傳送完成後，如果需要將輔助資料庫聯機，那麼就必須使用下面SQL操作：
錯誤做法：
USE [master]
GO
ALTER DATABASE [TEST] SET READ_WRITE WITH NO_WAIT
GO
Msg 5063, Level 16, State 1, Line 3
Database 'TEST' is in warm standby. A warm-standby database is read-only.
Msg 5069, Level 16, State 1, Line 3
ALTER DATABASE statement failed.
正確做法：
USE master ;
GO
ALTER DATABASE [TEST] SET SINGLE_USER WITH ROLLBACK IMMEDIATE ;
GO
RESTORE DATABASE [TEST] WITH RECOVERY
GO
ALTER DATABASE [TEST] SET MULTI_USER
日誌傳送相關表和儲存過程
主伺服器表
| 表 |
描述 |
| log_shipping_monitor_alert |
儲存警報作業 ID。 僅當尚未配置遠端監視伺服器時，主伺服器上才會使用此表。 |
| log_shipping_monitor_error_detail |
儲存與此主伺服器關聯的日誌傳送作業的錯誤詳細資訊。 |
| log_shipping_monitor_history_detail |
儲存與此主伺服器關聯的日誌傳送作業的歷史記錄詳細資訊。 |
| log_shipping_monitor_primary |
儲存一條此主資料庫的監視記錄。 |
| log_shipping_primary_databases |
包含指定伺服器上主資料庫的配置資訊。 每個主資料庫儲存一行。 |
| log_shipping_primary_secondaries |
將主資料庫對映到輔助資料庫。 |
主伺服器儲存過程
| 儲存過程 |
描述 |
| sp_add_log_shipping_primary_database |
設定日誌傳送配置（包括備份作業、本地監視記錄及遠端監視記錄）的主資料庫。 |
| sp_add_log_shipping_primary_secondary |
向現有的主資料庫新增輔助資料庫名稱。 |
| sp_change_log_shipping_primary_database |
更改主資料庫設定，包括本地和遠端監視記錄。 |
| sp_cleanup_log_shipping_history |
根據保持期清除本地歷史記錄及監視器上的歷史記錄。 |
| sp_delete_log_shipping_primary_database |
刪除主資料庫的日誌傳送，包括備份作業以及本地和遠端歷史記錄。 |
| sp_delete_log_shipping_primary_secondary |
從主資料庫中刪除輔助資料庫名稱。 |
| sp_help_log_shipping_primary_database |
檢索主資料庫設定並顯示 log_shipping_primary_databases 和 log_shipping_monitor_primary 表中的值。 |
| sp_help_log_shipping_primary_secondary |
檢索主資料庫的輔助資料庫名稱。 |
| sp_refresh_log_shipping_monitor |
利用指定的日誌傳送代理的最新資訊重新整理監視器。 |
輔助伺服器表
| 表 |
描述 |
| log_shipping_monitor_alert |
儲存警報作業 ID。 僅當尚未配置遠端監視伺服器時，輔助伺服器上才會使用此表。 |
| log_shipping_monitor_error_detail |
儲存與此輔助伺服器關聯的日誌傳送作業的錯誤詳細資訊。 |
| log_shipping_monitor_history_detail |
儲存與此輔助伺服器關聯的日誌傳送作業的歷史記錄詳細資訊。 |
| log_shipping_monitor_secondary |
儲存與此輔助伺服器關聯的輔助資料庫監視記錄。每個輔助資料庫儲存一條監視記錄。 |
| log_shipping_secondary |
包含指定伺服器上輔助資料庫的配置資訊。 每個輔助 ID 儲存一行。 |
| log_shipping_secondary_databases |
儲存指定輔助資料庫的配置資訊。 每個輔助資料庫儲存一行。 |
備註
與指定主資料庫位於同一個輔助伺服器上的輔助資料庫共享 log_shipping_secondary 表中的設定。 如果一個輔助資料庫更改了共享設定，所有輔助資料庫的設定都將更改。
輔助伺服器儲存過程
| 儲存過程 |
描述 |
| sp_add_log_shipping_secondary_database |
設定用於日誌傳送的輔助資料庫。 |
| sp_add_log_shipping_secondary_primary |
為指定的主資料庫設定主伺服器資訊，新增本地和遠端監視器連結，並在輔助伺服器上建立複製作業和還原作業。 |
| sp_change_log_shipping_secondary_database |
更改輔助資料庫設定，包括本地和遠端監視記錄。 |
| sp_change_log_shipping_secondary_primary |
更改輔助資料庫設定，例如源目錄、目標目錄和檔案保持期。 |
| sp_cleanup_log_shipping_history |
根據保持期清除本地歷史記錄及監視器上的歷史記錄。 |
| sp_delete_log_shipping_secondary_database |
刪除輔助資料庫、本地歷史記錄和遠端歷史記錄。 |
| sp_delete_log_shipping_secondary_primary |
從輔助伺服器上刪除有關指定的主伺服器的資訊。 |
| sp_help_log_shipping_secondary_database |
從 log_shipping_secondary 、 log_shipping_secondary_databases 和 log_shipping_monitor_secondary 表中檢索輔助資料庫設定。 |
| sp_help_log_shipping_secondary_primary |
此儲存過程將在輔助伺服器上檢索給定的主資料庫的設定。 |
| sp_refresh_log_shipping_monitor |
利用指定的日誌傳送代理的最新資訊重新整理監視器。 |
監視伺服器表
| 表 |
描述 |
| log_shipping_monitor_alert |
儲存警報作業 ID。 |
| log_shipping_monitor_error_detail |
儲存日誌傳送作業的錯誤詳細資訊。 |
| log_shipping_monitor_history_detail |
儲存日誌傳送作業的歷史記錄詳細資訊。 |
| log_shipping_monitor_primary |
儲存與此監視伺服器關聯的主資料庫的監視記錄。每個主資料庫儲存一條監視記錄。 |
| log_shipping_monitor_secondary |
儲存與此監視伺服器關聯的輔助資料庫的監視記錄。每個輔助資料庫儲存一條監視記錄。 |
監視伺服器儲存過程
| 儲存過程 |
描述 |
| sp_add_log_shipping_alert_job |
如果尚未建立日誌傳送警報作業，則建立它。 |
| sp_delete_log_shipping_alert_job |
如果沒有關聯的主資料庫，則刪除日誌傳送警報作業。 |
| sp_help_log_shipping_alert_job |
返回警報作業的作業 ID。 |
| sp_help_log_shipping_monitor_primary |
從 log_shipping_monitor_primary 表中返回指定的主資料庫的監視記錄。 |
| sp_help_log_shipping_monitor_secondary |
從 log_shipping_monitor_secondary 表中返回指定的輔助資料庫的監視記錄。 |
日誌傳送問題
日誌傳送可能會遇到一些問題，例如， Skipped log backup file
Message
2018-11-08 12:45:01.51Skipped log backup file. Secondary DB: 'TEST', File: '\\XXXXXXXX\DB_BACKUP\TEST_20181108041515.trn'
2018-11-08 12:45:01.53Could not find a log backup file that could be applied to secondary database 'TEST'.
Message
Executed as user: NT AUTHORITY\SYSTEM. The log shipping secondary database xxxxx.TEST has restore threshold of 45 minutes and is out of sync. No restore was performed for 75 minutes. Restored latency is 0 minutes. Check agent log and logshipping monitor information. [SQLSTATE 42000] (Error 14421). The step failed.
如果遇到這個問題，則需要分析主資料庫的事務日誌備份，看看是否因為某些原因導致事務日誌鏈斷開引起。另外，關於錯誤 14421 ， 可以參考官方文 檔 " ofollow,noindex"> Description of error message 14420 and error message 14421 that occur when you use log shipping in SQL Server ", 下面摘錄在此（微軟有些文件，經常會失效）。
Summary
This article discusses the reasons for "out of sync" error messages when you have log shipping configured for SQL Server 2000.
One of the following error messages may be logged in the SQL Server error log:
Error message 14420
Error: 14420, Severity: 16, State: 1
The log shipping destination %s.%s is out of sync by %s minutes.
Error message 14421
Error: 14421, Severity: 16, State: 1
The log shipping destination %s.%s is out of sync by %s minutes.
If you are using SQL Server 2005, the description for these error messages are different:
Error message 14420
Error: 14420, Severity: 16, State: 1
The log shipping primary database %s.%s has backup threshold of %d minutes and has not performed a backup log operation for %d minutes. Check agent log and logshipping monitor information.
Error message 14421
Error: 14421, Severity: 16, State: 1
The log shipping secondary database %s.%s has restore threshold of %d minutes and is out of sync. No restore was performed for %d minutes. Restored latency is %d minutes. Check agent log and logshipping monitor information.
More Information
Log shipping uses Sqlmaint.exe to back up and to restore databases. When SQL Server creates a transaction log backup as part of a log shipping setup, Sqlmaint.exe connects to the monitor server and updates the log_shipping_primaries table with the last_backup_filename information. Similarly, when you run a Copy or a Restore job on a secondary server, Sqlmaint.exe connects to the monitor server and updates the log_shipping_secondaries table.
As part of log shipping, alert messages 14220 and 14221 are generated to track backup and restoration activity. The alert messages are generated depending on the value of Backup Alert threshold and Out of Sync Alert threshold respectively.
The alert message 14220 indicates that the difference between current time and the time indicated by the last_backup_filename value in the log_shipping_primaries table on the monitor server is greater than value that is set for the Backup Alert threshold.
The alert message 14221 indicates that the difference between the time indicated by the last_backup_filename in the log_shipping_primaries table and the last_loaded_filename in the log_shipping_secondaries table is greater than the value set for the Out of Sync Alert threshold.
Troubleshooting Error Message 14420
By definition, message 14420 does not necessarily indicate a problem with log shipping. The message indicates that the difference between the last backed up file and current time on the monitor server is greater than the time that is set for the Backup Alert threshold.
There are serveral reasons why the alert message is generated. The following list includes some of these reasons:
1. The date or time (or both) on the monitor server is different from the date or time on the primary server. It is also possible that the system date or time was modified on the monitor or the primary server. This may also generate alert messages.
2. When the monitor server is offline and then back online, the fields in the log_shipping_primaries table are not updated with the current values before the alert message job runs.
3. The log shipping Copy job that is run on the primary server might not connect to the monitor server msdb database to update the fields in the log_shipping_primaries table. This may be the result of an authentication problem between the monitor server and the primary server.
4. You may have set an incorrect value for the Backup Alert threshold. Ideally, you must set this value to at least three times the frequency of the backup job. If you change the frequency of the backup job after log shipping is configured and functional, you must update the value of the Backup Alert threshold accordingly.
5. The backup job on the primary server is failing. In this case, check the job history for the backup job to see a reason for the failure.
Troubleshooting Error Message 14421
By definition, message 14421 does not necessarily indicate a problem with Log Shipping. This message indicates that the difference between the last backed up file and last restored file is greater than the time selected for the Out of Sync Alert threshold.
There are serveral reasons why the alert message is raised. The following list includes some of these reasons:
1. The date or time (or both) on the primary server is modified such that the date or time on the primary server is significantly ahead between consecutive transaction log backups.
2. The log shipping Restore job that is running on the secondary server cannot connect to the monitor server msdb database to update the log_shipping_secondaries table with the correct value. This may be the result of an authentication problem between the secondary server and the monitor server.
3. You may have set an incorrect value for the Out of Sync Alert threshold. Ideally, you must set this value to at least three times the frequency of the slower of the Copy and Restore jobs. If the frequency of the Copy or Restore jobs is modified after log shipping is set up and functional, you must modify the value of the Out of Sync Alert threshold accordingly.
4. Problems either with the Backup job or Copy job are most likely to result in "out of sync" alert messages. If "out of sync" alert messages are raised and if there are no problems with the Backup or the Restore job, check the Copy job for potential problems. Additionally, network connectivity may cause the Copy job to fail.
5. It is also possible that the Restore job on the secondary server is failing. In this case, check the job history for the Restore job because it may indicate a reason for the failure.
參考資料：
https://docs.microsoft.com/zh-cn/sql/database-engine/log-shipping/about-log-shipping-sql-server?view=sql-server-2017
https://www.mssqltips.com/sqlservertip/2301/step-by-step-sql-server-log-shipping/
https://blogs.technet.microsoft.com/mdegre/2009/08/08/logshipping-secondary-server-is-out-of-sync-and-lsrestore-job-failing/