一、現象
1、2臺sqlserver使用事物日誌傳送的方式做的災備，具體配置如下：
資料庫數量：1
資料庫大小：85g
主庫備份作業頻率：每5分鐘備份一次
備庫cop也作業頻率：每5分鐘執行一次
備庫還原作業頻率：每5分鐘執行一次
備庫的模式是：備用模式（在還原備份時斷開資料庫使用者的連線）
2、主庫的備份作業正常，備庫的copy作業正常，備庫的restore作業也沒有報錯，但是作業裡面的步驟有錯誤，如下：
2020-05-12 09:25:05.95 the restore operation was successful. secondary id: 'f89cf291-924f-4dc2-adce-bd6e4cfb636d'
2020-05-12 09:25:05.95 *** error: could not log history/error message.(microsoft.sqlserver.management.logshipping) ***
2020-05-12 09:25:05.95 *** error: executenonquery 要求已開啟且可用的連線。連線的當前狀態為已關閉。(system.data) ***
2020-05-12 09:25:05.95 *** error: could not cleanup history.(microsoft.sqlserver.management.logshipping) ***
2020-05-12 09:25:05.95 *** error: executenonquery 要求已開啟且可用的連線。連線的當前狀態為已關閉。(system.data) ***
2020-05-12 09:25:05.95 ----- end of transaction log restore -----
二、問題分析
1、備庫的狀態應該是「備用/唯讀」，但是有一天突然變成了「正在還原」，檢視主庫上的備份作業執行正常，檢視備庫上copy和restore作業執行正常，沒有報錯；
2、檢視存放日誌備份的共享資料夾，發現2邊檔案保持一致，並且還在不斷備份和copy新的檔案過來，所以備份和copy的作業應該沒有問題；
3、檢視restore的作業，雖然作業執行成功了，但是裡面有error錯誤，發現還在還原幾天前的日誌檔案，問題應該出現這個restore作業；
4、根據系統檢視restorehistory檢視還原歷史，發現最後一次還原是4月25號，找到這個日誌備份，手動還原，能還原成功，lsn號能銜接上，如下：
命令： select * from msdb.dbo.restorehistory order by restore_date desc
5、檢視事物日誌傳送的狀態，發現最後乙個檔案的滯後時間達到8234min；
三、處理方法
1、把主庫的完整備份重新備份一次，在備庫上還原即可，下次restore作業就會接著最新的備份lsn繼續還原了。
2、或者重新搭建事物日誌同步。
四、總結
1、出現這種問題，就是某一次日誌接不上了，restore作業在日誌備份的資料夾，一直在找對應的備份找不到，導致滯後了，加上我們的頻率是5分鐘，太頻繁，所以每次執行restore作業的時候，大部分的時間用在skipping log backup file了，還沒找到正確的備份，就得開始下一次作業了，導致出現了這種死迴圈，一直找不到正確的日誌備份。
2、至於為什麼日誌會接不上了? 為什麼每次restore作業會skipping log，遍歷的方式來找正確的日誌？還沒找到原因。
事物的併發問題
事物的併發問題 髒讀 例如事物沒有執行完，就讀。比如 轉賬一半，讀，rollback 最可怕 重複讀 兩次讀取的不一致。即讀取第二次，事物更新 幻讀 虛讀 對同一張表兩次查詢不一致，因為另一事物插入記錄 四大隔離級別 serializable 序列化 不會出現任何併發問題，因為就是序列。效能最差 r...
郵件傳送與接收失敗的原因
傳送電子郵件在我們平時辦公資訊交流等方面起著不可磨滅的作用，可是我們在使用的同時也會遇到一些郵件傳送不出，接收不了的問題。那麼是什麼原因引起這樣的問題呢。下面我們來具體學習和了解。首先傳送失敗的原因 1 收件人位址有錯誤 這是很容易出現的錯誤，特別是在收件人名稱中含有數字 字元的情況下，比如將下劃線...
Django傳送多封郵件失敗的原因
2.django中，傳送郵件的案例如下 fromdjango.core.mailimportsend mail send mail subject here here is the message.from example.com to example.com fail silently false...