SQL Server更改跟蹤與複製與差異備份

Question

好吧，我們有重要的事務數據庫及其在SQL Server 2008中處於完全恢復模式。我們在兩個不同的時區中有兩個不同的數據中心。我試圖設置最好的方式，使數據庫儘可能使用各種選項。數據庫目前只有1.5GB，預計每6個月增長1GB。

我們已經使用了一個簡單的解決方案，使用SMO在凌晨1點創建FULL Backup，然後每隔15分鐘進行一次差異備份。我們將這些數據傳輸給其他作爲從服務器的服務器，並在從服務器上恢復數據。所以所有的奴隸都比現在的數據庫運行了15分鐘，所以如果發生崩潰，我們將有數據直到最後15分鐘。

現在我想比較一下這個解決方案的複製和更改跟蹤。

複製和更改跟蹤都會在數據庫中放入一些額外的元數據，以執行他們所做的一切並且利用CPU使用量。但是，與Diff備份相比，它們不會對CPU造成更多的負擔（據我瞭解）。我假設差異備份將保留一些事務等待或增加一些掛起的隊列，並且可能在用戶使用它時造成信息的延遲或丟失。

我需要知道每隔15分鐘差異備份會在服務器上增加更多負載嗎？或者當交易正在處理時，每隔15分鐘使用差異備份是否真的沒有建議？

注意：事務僅適用於主服務器，並且它們應用於使用備份還原的從服務器。日誌傳送不會提供模式更改，並且在某種程度上，如果它停止工作，我們無法在我們自定義的解決方案中獲取任何錯誤通知我們通過電子郵件發送給我們的日誌可以幫助我們。

Answer 1

我們發現我們自己的解決方案如下，

1. 鏡像和日誌傳送都需要VPN和高安全性所以我們拋棄他們。
2. 鏡像和日誌傳送以及SQL Server的幾乎所有同步方法都不關心網絡帶寬使用情況，它們不會壓縮任何內容。

MSDN說差異文件備份速度更快，我們選擇差異文件備份。是的15分鐘，它看起來沒有什麼矯枉過正，但它們是最快和最可靠的。 24小時內，這些準確的變化只有幾MB。

備份是由自定義Windows服務進行的，它們也被壓縮以節省網絡傳輸。另外，我們會收到適當的電子郵件通知。

加從站數據庫可以在互聯網上的任何地方。備份是安全的並且使用密碼進行壓縮。並且內置Web服務器中的一個小型HTTP將數據從一臺機器傳輸到另一臺機器，因此所需的配置開銷較少。

當我們有很多服務器時，配置它們是非常痛苦的。另外，每個網絡管理員都可能犯了一個錯誤，造成災難

Answer 2

忘記複製或更改數據跟蹤。 那些不會複製架構，並且會增加大量開銷。 也沒有將設計爲高可用性或災難恢復解決方案。他們可以使用，可能會使用，但與日誌傳送，數據庫鏡像或硬件鏡像等專用解決方案相比，它們顯得蒼白無力。

日誌傳送轉讓一切數據庫，包括架構，以及用戶，權限，索引，數據等等等等。您沒有指定您何時傳輸日誌備份。每15分鐘做一次差異備份聽起來像是過度殺毒。差異備份是累積性的，它們包含自從上一次完整備份以來的所有更改，所以它們在一天中的大小會增加。 15分鐘聽起來像是定期日誌備份的時間段，而不是差分日誌備份。

日誌傳送依賴於來自SQL代理作業的文件複製操作。因此它需要訪問文件共享並需要認證。在不同的域中，您需要直接訪問或某種類型的VPN。

數據庫鏡像也正在創建數據庫的相同副本，但其數據丟失窗口高達秒，而不是日誌傳送中的日誌備份間隔。數據庫鏡像可以在兩臺服務器之間保持一個特殊的連接，並且主服務器將每次事務發送到鏡像，實時發生。由於鏡像端點支持certificate based authentication，因此可以輕鬆設置跨域，並且而不是需要VPN。DBM可以是同步的（主體上的每個事務都等待鏡像在提交之前確認它，也就是高安全模式）或異步（主體將在鏡像之前寫入並立即提交，即高性能模式）。如果連接丟失，委託人將開始運行'暴露'，所以你不會失去服務，但是你會暴露自己的數據丟失。一旦連接被重新獲得，委託人將向鏡像反饋待處理的事務隊列（即尚未交付的LDF文件的一部分），直到鏡像恢復爲止。所有這些都是自動的，並且SSMS中有監控工具，可以設置爲在連接失敗時發送通知，當主體運行暴露時，當未發送隊列增長超過預設大小時發送通知。

硬件鏡像：您需要與硬件供應商或您的數據中心操作員交談。這是一筆財富。

總體數據庫鏡像是迄今爲止您的最佳選擇。