在備份大型 SQL Server 數據庫時執行數據更新操作

我有一個大型（數千萬條記錄）數據庫，我將對其執行完整的數據庫備份。

但是，數據庫足夠大，事務可以在備份之前和期間啟動，以及在備份期間和之後送出。

例如：

T0 = Transaction A start
T1 = Full database backup start
T2 = Transaction B start (will not deadlock with A)
T3 = Transaction A commit/rollback (does not matter, does it?)
T4 = Full database backup end
T5 = Transaction B commit/rollback (again, does not matter, does it?)

T0          T1          T2          T3          T4          T6
||----------||----------||----------||----------||----------||---------->

我的理解是在備份期間不使用鎖（儘管由於高 I/O 可能會出現其他性能問題），但我不確定我能保證什麼會被送出。

另外，我擔心的不是數據庫將處於不一致的狀態，而是該狀態將是什麼（即使它不是確定性的，如果有一組可以一致應用的規則）以及它是如何到達那裡的（例如，有多少數據文件與事務日誌一起用於創建備份文件）？

本質上，備份將是數據庫在完成備份的數據讀取部分時的狀態（因此所有數據都將被備份），加上確保事務一致性所需的任何事務日誌量（開始包含日誌的時間是MIN(most recent checkpoint time, oldest active transaction start time))。Paul Randal在這裡介紹了這一點（借助圖表，這使得這一切變得更加容易）。在您的範例中，A將被送出（或如果ROLLBACK TRANSACTION發出 a 而不是 a 則回滾COMMIT）B並將被回滾（無論該事務的最終結果如何）。

（除了 I/O 爭用之外，您嘗試在安靜的時間進行備份的另一個原因是備份期間生成的所有事務日誌通常都必須包含在備份中。）

數據庫還原的恢復階段從備份中包含的日誌中獲取所有已送出的事務並將它們應用於數據庫，並回滾所有未送出的事務。（這就是WITH RECOVERY/WITH NORECOVERY很重要的原因。WITH RECOVERY您可以使用數據庫，但不能應用任何進一步的日誌備份，您需要恢復它WITH NORECOVERY才能滾動日誌備份。恢復通過回滾未送出的事務來破壞日誌鏈。 )

進一步閱讀：

• 30 個 SQL Server 備份神話
• 揭穿關於完全備份的幾個神話
• SQL Server 中的日誌記錄和恢復

引用自：https://dba.stackexchange.com/questions/18024