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.51 Skipped log backup file. Secondary DB: 'TEST', File: '\\XXXXXXXX\DB_BACKUP\TEST_20181108041515.trn'
2018-11-08 12:45:01.53 Could 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， 可以參考官方文檔"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 theBackup Alertthreshold 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/