logshipping 14421問題該如何解決

今天就跟大家聊聊有關logshipping 14421問題該如何解決，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。

1、錯誤信息描述 Error: 14421:Server :The log shipping secondary database BOOK01\sk.newshu  has restore threshold of 45 minutes and is out of sync. No restore was performed for 48 minutes. Restored latency is 0 minutes. Check agent log and logshipping monitor information.

2、現象說明：

此消息指出日志傳送在超出還原閾值的情況下不同步。還原閾值是生成消息之前在還原操作之間允許等待的分鐘數。

3、可能原因：

此消息并不一定表示日志傳送存在問題。這個消息可能表示存在以下問題：

• 還原作業未運行。
  導致作業未運行的可能原因包括：輔助服務器實例上的 SQL Server 代理服務未運行、作業被禁用或作業計劃已更改。
  

• 還原作業失敗。
  導致作業失敗的可能原因包括：還原文件夾路徑無效、磁盤已滿、監控服務器的信息與輔助或者主庫的信息不匹配或可能導致 RESTORE 語句失敗的其他任何原因。

4、問題解決：

先查詢相關視圖來驗證

在主庫上查詢  select * from log_shipping_monitor_primary

在輔庫上查詢 select * from log_shipping_monitor_secondary

可以查看last_copy_date和last_restored_date的信息，如果發現未更新，則說明確實是由于信息不同步導致的。

另外有個存儲過程可以同步監控服務器和輔助服務器（主服務）的信息，既sp_refresh_log_shipping_monitor 不過我沒有運行成功。

最后通過重新配置該庫的日志重送及監視服務器后，該問題得以解決。

5、思考：

若要配置監視日志傳送，在啟用日志傳送時必須添加監視服務器。如果之后添加監視服務器，則必須首先刪除日志傳送配置，然后將其替換為包含監視服務器的新配 置。

其他分析資料：

• 確保輔助服務器實例的 SQL Server 代理服務處于運行狀態，同時啟用了該輔助數據庫的還原作業并安排它以適當的頻率運行。
  

• 輔助服務器上的還原作業可能失敗。在這種情況下，請查看還原作業的作業歷史記錄以尋找原因。
  

• 在輔助服務器實例上運行的日志傳送還原作業可能無法連接到監視服務器實例以更新 log_shipping_monitor_secondary 表。這可能是由于監視服務器實例和輔助服務器實例之間的身份驗證問題引起的。
  

• 備份警報閾值可能包含錯誤的值。理想情況下，至少將該值設置為還原作業頻率的三倍。如果在配置了日志傳送并使之起作用之后更改了還原作業的頻率，則必須相應地更新備份警報閾值的值。
  

• 當監視服務器實例離線并重新在線時，在警報消息作業運行之前不會使用當前值更新 log_shipping_monitor_secondary 表。還原作業雖然成功但顯示消息“找不到可以應用到輔助數據庫的日志備份文件”時，可能引發錯誤 14421。出現這種情況時，將不更新還原時間。在這種情況下，錯誤原因可能是復制作業存在問題。
  若要使用輔助數據庫的最新數據更新監視表，請在輔助服務器實例上運行 sp_refresh_log_shipping_monitor。
  

• 在輔助服務器實例或監視服務器實例上，日期或時間不正確。這也可能生成警報消息。可能在其中一個服務器實例上修改了系統日期或時間。
  

• 注：兩個服務器實例的時區不同不會引發問題。

看完上述內容，你們對logshipping 14421問題該如何解決有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注億速云行業資訊頻道，感謝大家的支持。