Log-Shipping
日誌傳送以修復意外刪除？
我正在閱讀 Carter 的《Pro SQL Server 2019 Administration》一書：
使用者不小心刪除數據的場景；他提到我們可以（從 DR 伺服器）恢復數據，然後“重新填充生產伺服器”。
然後他補充說“這意味著您不需要恢復備份來恢復數據。”
他所說的“重新填充”是什麼意思？這比備份/恢復有什麼更好/不同？
由於 DR 站點上的數據庫處於
read_only模式，您可以從主伺服器上發生刪除的 DR 表中導出數據，並使用從 DR 站點導出的數據為該表“重新填充”主伺服器。如果數據庫非常大，這將特別有用，因為您不必恢復整個數據庫即可僅恢復一張表。當然，這假設包含 的日誌記錄
deletes尚未應用於 DR 數據庫。
為了便於討論，我們假設將更改應用到 DR 伺服器上的數據庫有30 分鐘的延遲（滯後）。
- 10:00 使用者刪除了他們不應該擁有的東西。
- 10:10 他們打電話給你。
- 10:20 您在備用數據庫上查詢（尚未更改的表）。您找到他們刪除的行並將它們複製到另一個表中，將數據移植回主數據庫並重新插入它們。
- 10:30 日誌傳送“趕上”，行從備用數據庫中刪除。
- 10:50 在您將它們“放回”到主數據庫後的 30 分鐘，這些行被重新添加到備用數據庫。
您所做的只是將一個表查詢到另一個表中，將其移植到另一個數據庫並執行另一個insert..select 以將行重新填充到原始表中。
面對現實吧; 這很容易。
替代方案？
您必須從某個時間點恢復數據庫的副本
$$ just $$在他們刪除行之前。根據數據庫的大小，這可能需要一段時間，當然，您必須手頭有磁碟空間才能進行恢復（您應該將其置於“熱備用”狀態，以備不時之需）。 然後您可以再次執行整個插入..選擇、埠、插入..選擇。
這聽起來“不錯”，但是……快速現實檢查。
三十分鐘是計算時間的永恆。在您的 DR“循環”中有這麼多滯後只是在自找麻煩（儘管您的恢復目標可能會有所不同）。 秒，而不是分鐘，通常是這裡的業務順序。當使用者意識到他們做了一些愚蠢的事情時，您通常會期望備用數據庫與主數據庫處於相同的混亂狀態。