為什麼 SAN 複製會導致隨機數據庫損壞？
我們正在嘗試實施的災難恢復技術有一個奇怪的問題。兩個數據中心的環境相同，具有相同版本的 VMWare 和 Dell Equallogic SAN。
當我們從一個數據中心複製到另一個數據中心時，隨機數據庫會以某種方式損壞並最終處於可疑模式。每次我們嘗試這種方法時，都會損壞不同的數據庫。這是導致此問題的 SQL 行為嗎？這是 SAN 中用於複製的軟體導致這些錯誤嗎？
我已經能夠將數據庫的狀態更改為 EMERGENCY 模式並執行 DBCC CHECKDB，但每次都是不同的問題和數據庫。我發現的一些錯誤是索引問題和數據不匹配問題。我仍在檢查其他數據庫以查看是否可以找到模式。如果發現其他東西，如果有幫助，我一定會發布。
我聽說有人成功地實施了這個程序，這是項目中在我們關閉項目章程之前要弄清楚的最後一項任務。
我真的希望我們可以只使用 SQL Server 的內置功能，如鏡像或 AO-AG。
SQL 的版本是 2008 R2 和 2012。我們正在安裝一些全新的 SQL 2014 伺服器。此外，它們都是標準的，而不是企業的。
我可以嘗試的任何輸入或事情都會有很大幫助，在此先感謝！
Edit#1 8/6/15 12:50 PM CST - 以下是我在 Windows 事件查看器中發現的一些錯誤消息，這或多或少是 DBCC CHECKDB 產生的。
- EventID 605 - 嘗試在數據庫 26 中獲取邏輯頁 (1:22620) 失敗。屬於分配單位 72057594239385600 不屬於 72057594249412608
- EventID 824 - SQL Server 檢測到基於邏輯一致性的 I/O 錯誤：分頁不正確（預期為 1:1230；實際為 0:0）。它發生在讀取文件“D:\Mydatabase.mdf”中偏移量 0x0000000099c000 的數據庫 ID 58 中的頁面 (1:1230) 期間。SQL Server 錯誤日誌或系統事件日誌中的其他消息可能會提供更多詳細資訊。這是威脅數據庫完整性的嚴重錯誤情況，必須立即糾正。完成完整的數據庫一致性檢查 (DBCC CHECKDB)。
- EventID 7886 - 向客戶端發送數據時，對大對象的讀取操作失敗。造成這種情況的一個常見原因是應用程序是否在 READ UNCOMMITTED 隔離級別下執行。此連接將被終止。
- EventID 608 - 在數據庫 23 中找不到分區 ID 72057594383564800 的目錄條目。元數據不一致。執行 DBCC CHECKDB 以檢查元數據損壞。
Edit#2 8/6/15 2:24 PM CST - 收到的資訊表明，在 SUSPECT 模式下恢復數據庫的 .bak 文件可以解決問題。
關於您的評論，我懷疑這裡是與操作相關的問題，而不是 SQL Server 引擎問題。這些 SAN 設備通常在塊層上工作，有些設備比其他設備更好地管理事務日誌/數據文件同步，以及其他領域。
您可以向操作團隊表明，不，SQL Server 不會像這樣隨機損壞數據。您可以將備份恢復到另一台伺服器，設置鏡像，所有這些都不會損壞。我們進行 san 級別複製的那一刻，它就會發生。如果 SQL Server 造成這樣的損壞，它就不會存在。SQL Server 有幾乎數百萬行程式碼來處理損壞、修復損壞和減少損壞的可能性。您在任何其他環境中都不會遇到此問題，它只會出現 SAN 複製，對嗎？
韌體通常是這些類型問題的主要原因。讓您的戴爾支持代表線上，他們將獲得更多資訊和故障排除。不要滿足於一個懶惰的代表，您的企業的數據和時間是線上的。他們有很多工具可以在後台檢查是什麼導致了這種情況，而 DPAC 等其他工具可能會有所幫助。這不是 SQL Server 引擎問題，我們需要 Ops 的全面支持。
編輯：如果您的韌體已過期或不匹配，請從管理 SAN 的 Ops 團隊獲取政策，該政策聲明他們將在他們管理的機器堆棧中保持韌體為最新。如果此 SLA 不存在，您應該將其記錄給您的經理，因為除此之外您還面臨許多其他問題。
我假設您正在使用 SAN 塊級複製。
它通常也可能在設置中不匹配。也許不同的塊大小等，但 san os 通常應該能夠檢測到這些問題。