日誌傳送複製作業偶爾失敗
我已經在具有受監控伺服器（單獨的伺服器）的多個數據庫伺服器上配置了日誌傳送，並且它們都執行良好，沒有任何問題。
一台特定的伺服器有 7 個數據庫，並且所有數據庫的日誌傳送複製作業偶爾會失敗，當我檢查錯誤消息時，每次錯誤都保持不變：
*** Error: The network path was not found. (mscorlib) ***此問題不會持續存在，並且會在隨機時間和任何給定日期（不是每天）發生。以下是日誌傳送時間表的詳細資訊：
- 日誌備份作業計劃在主伺服器上每 15 分鐘執行一次（文件在監控伺服器上生成）。
- LS Copy 作業計劃在輔助伺服器上每 15 分鐘執行一次，與日誌備份作業相隔 5 分鐘。
- LS 還原作業計劃在輔助伺服器上執行 15 分鐘，與 LS 複製作業相隔 5 分鐘。
考慮到網路速度和文件大小，上述作業有 5 分鐘的延遲。
任何人都可以請提出什麼可能是潛在的問題。
目前，我已經要求 Infra 管理員在輔助伺服器的 hosts 文件中添加伺服器名稱及其 IP，不知道這是否能解決問題。
注意：主伺服器、監控伺服器和備用伺服器的作業系統和數據庫版本相同。
屬於同一伺服器的所有數據庫的作業再次失敗，並且文件沒有被複製。沒有關於錯誤消息的詳細資訊，並且計劃在 15 分鐘後的下一次執行成功。我對此一無所知。
我認為伺服器設置有問題。任何輸入將不勝感激。
這實際上不是 SQL-Server 錯誤，
當 LS Copy Job 嘗試在目標位置（在共享網路位置）上複製文件時，會發生這種情況，現在，當由於與網路的臨時連接失去或任何原因導致該位置不可用時。（當它通過網際網路和 VPN 連接時，原因可能有多種）
所以這可以概括為網路路徑不可達（當時不可用）
解決方案：在複製之前檢查網路位置是否可用。如果網路位置可達，則僅初始化副本。
我希望這能回答你正在尋找的東西。
在檢查了各種部落格、系統事件、日誌等之後，從數據庫的角度來看，我們沒有發現任何異常情況，因此我將其標記給高級系統管理員以檢查問題，因為它僅發生在此伺服器上，而不發生在任何其他伺服器上。
我們發現僅針對此伺服器的另一個問題是 - 我們無法在不使用非預設埠的情況下從 SSMS 登錄到此數據庫伺服器，而預設埠和一個非預設埠是在伺服器級別配置的。對於其他伺服器，我們沒有任何問題。他們正在使用帶有/不帶有埠的主機名或 IP。為所有伺服器定義了傳入防火牆規則，甚至所有伺服器的 telnet 都按預期工作。我們甚至使用 tracert 檢查從源伺服器到目標伺服器的路徑，並且沒有問題。
最初，伺服器管理員指向網路/數據庫問題，但是由於其他作業在同一子網中沒有失敗並且僅限於該特定伺服器，他開始檢查各種詳細資訊。
經過多層次的探勘，他發現這台伺服器和其他伺服器的區別是SQL Server Service在NetBIOS的Host SPN中註冊了SQL Server名稱和埠1433，其他伺服器只有伺服器名稱，沒有與之關聯的埠。因此，可以隨意使用 SQL 伺服器配置管理器中定義的任何埠。他刪除了這個 SPN 並重新啟動了輔助伺服器，並開始從 SSMS 到此伺服器的連接與其他伺服器類似，即僅使用主機名或 IP 帶/不帶埠號。
現在，在這到位之後——我們假設日誌傳送也將順利進行，並且不應該間歇性地失敗，因為複製作業在 MSSQL 中，所以這可能是失敗的原因之一。我不太確定，這是否會解決潛在問題，但是我將其發佈為答案，我願意就此提出任何建議。我將等待至少一個月才能接受這個答案，這解決了我的問題。
這項工作在上週五晚上以同樣的原因失敗了，再次一無所知。需要再次與 Infra 管理員開會以檢查任何問題。