適用於：
Azure SQL 受控實例
Microsoft 負責管理 Azure SQL 受控執行個體 中的資料完整性。 雖然傳統技術可讓 DBA 監控資料完整性並從 SQL Server 的資料庫損壞中恢復，但 Microsoft SQL 工程團隊開發了新技術，能自動處理某些類型的損壞且不會遺失資料。 該服務利用這些技術，在可避免的情況下避免資料遺失與停機。
本文將說明其中一些技術、運作方式，以及它們如何影響關心如何保護 Azure SQL 受控執行個體 資料的客戶。
Microsoft 如何管理資料完整性
保護 Azure SQL 受控執行個體 的資料完整性涉及多種技術與不斷演進的方法：
廣泛的資料完整性錯誤警示監控。 SQL 資料庫引擎 會針對所有顯示資料完整性疑慮的錯誤與未處理異常發出警示。 工程團隊負責處理並調查這些警示。
I/O 系統「遺失寫入」偵測。 資料庫引擎具備額外功能，可偵測最常見的物理損毀原因：I/O 系統「遺失寫入」。 此功能追蹤頁面寫入及其相關的 LSN（日誌序號）。 從磁碟讀取資料頁的後續資料會與該頁面預期的 LSN 進行比較。 如果 LSN 的磁碟內容與預期內容不符，頁面就會變得過時，工程團隊會立即收到警報。
自動頁面修復。 部分服務層級提供資料庫副本以維持業務連續性。 該服務接著利用自動頁面修復，類似於可用性群組中使用的技術。 若副本因資料完整性問題無法讀取頁面，服務會從另一個副本取得該頁面的全新副本，替換無法讀取的頁面，避免資料遺失或客戶停機。
資料在靜態與傳輸中的完整性。 服務中的所有資料庫皆透過設定
CHECKSUM來驗證頁面，該設定計算整個頁面的校驗和，並將其儲存在頁面標頭中，以便讀取時驗證。 除了 TCP/IP 提供的基礎傳輸層級檢查碼之外，所有通訊也都使用傳輸層安全性（TLS）。備份與還原完整性檢查。 Azure SQL 受控執行個體 會在每次服務管理的備份與還原操作中執行頁面驗證。 對於由客戶起始的還原作業，如果來源資料庫已將
PAGE_VERIFY選項設為CHECKSUM，則會執行頁面驗證。 Azure SQL 受控執行個體 服務中的所有資料庫都已CHECKSUM啟用。 任何發現問題都會立即通知工程團隊。
Microsoft 如何處理資料完整性事件
Microsoft 將錯誤結果或資料損毀事件視為最嚴重等級。 公司提供全天候24×7的支援，涵蓋所有Azure工程團隊。 處理完整性事件時，目標是盡量減少無法使用並減少資料遺失。
系統資料完整性問題
Microsoft 在不通知客戶的情況下，修正不影響客戶資料或資料庫可用性的問題。 例如自動頁面修復能解決的問題，或內部資料庫元資料或遙測資料的損毀，但不影響客戶資料或查詢結果。
客戶資料完整性問題
當 Microsoft 偵測到錯誤結果或客戶資料損壞問題時，Microsoft 會採取以下行動：
- 在確認偵測後，依隱私法規盡力盡快聯繫客戶。
- 若建立聯繫，直接與客戶說明損壞範圍，說明復原選項，並讓客戶選擇最適合其應用與情境的方案。
- 在可能的情況下，協助客戶了解對其應用程式的影響範圍，例如辨識資料損毀是否導致應用程式以意外方式更改其他資料。
Microsoft 透過與客戶協調採取多種方法與步驟來修復資料損壞。 它不會嘗試在未經客戶同意下進行可能導致資料遺失的修復。 客戶無法在 Azure SQL 受控執行個體 中執行DBCC CHECKDB修復選項，因為無法將資料庫置入SINGLE_USER模式。 然而，Microsoft SQL 團隊可以採取包括但不限於以下修復步驟：
- 重建指數。 例如，重建一個非叢集索引，且基表沒有被損壞。
- 以
DBCC CHECKDB執行REPAIR_REBUILD，在修復不會造成資料遺失的情況下。 - 在修復可能造成部分資料遺失的情況下，使用
DBCC CHECKDB執行REPAIR_ALLOW_DATA_LOSS。 - 對於無法使用
DBCC CHECKDB修復資料完整性問題的情況，工程師可能會先將資料還原到資料完整性問題發生前的時間點，然後再手動重播交易記錄中的相關交易。 此技術應用的例子是交易日誌被損壞，導致無法自動重播所有交易，但不會破壞客戶資料。
工程團隊會對導致錯誤結果或資料損毀的問題進行詳細的事後檢討。 團隊會密切追蹤因問題而產生的相關維修項目。 這些事後檢討帶來了許多重大改進，包括前述的「遺失寫入」功能。
客戶發起的完整性檢查
Microsoft 管理的資料完整性保護能及早偵測新的資料完整性問題，並在可能的情況下修復。 客戶使用 DBCC CHECKDB 主動執行的完整性檢查可提供額外的一層保護，因為 DBCC CHECKDB 是一種可全面偵測整個資料庫損毀的機制。
DBCC CHECKDB補充 Microsoft 管理的資料完整性保護功能。
這種廣泛且深度的偵測需要大量時間，並在執行過程中 DBCC CHECKDB 消耗額外的運算與輸入輸出資源。 因此，DBCC CHECKDB 可能會因資源競爭而影響您的工作負載。
除了服務提供的監控與保護外，您還可以依照自己選擇的頻率與時間運行 DBCC CHECKDB ，平衡額外的資料完整性保護與額外的資源消耗。
客戶回饋與不斷演進的方法論
Azure SQL 工程團隊定期檢視並強化服務的資料完整性問題偵測能力。 雖然資料完整性錯誤罕見，但如果您在收到 Azure 支援通知前遇到錯誤，請提出支援案件。
如果你對 Microsoft 的資料完整性策略有任何回饋，工程團隊很樂意聽取你的意見。 如需聯繫工程團隊，提供相關回饋或意見，請參閱 https://aka.ms/sqlfeedback。 您的回饋有助於 Microsoft 改進現有並開發新的資料完整性保護功能。