靜默錯誤：Oracle數據庫是如何應對和處理的？

作者：蓋國強 2018-08-09 12:23:31

我們知道硬盤最核心的使命是正確的存入數據、正確的讀出數據，在出錯時及時拋出異常告警。磁盤出現異常的情形可能包括硬件錯誤、固件BUG 或者軟件BUG等，常規的這些問題都能夠正常被捕獲拋出異常，而最可怕的事情是，數據處理都是正常的，直到你使用的時候才發現數據是錯誤的、損壞的。這就是靜默錯誤。

這兩天，關于騰訊云『因為靜默錯誤,把創業公司的數據徹底搞丟了』的事件已經傳遍了整個互聯網，引發了廣泛的熱議和討論。

***故障回放

騰訊云已經于8月7日公布了最近這次事故的根本原因：

故障過程復盤 當天上午11:57，運維人員收到倉庫Ⅰ空間使用率過高告警，準備發起搬遷擴容；在14:05時，從倉庫Ⅰ選擇了一批云盤搬遷至新倉庫Ⅱ，為了加速搬遷，手動關閉了遷移過程中的數據校驗；在20:27 搬遷完成之后，將客戶的云盤訪問切至倉庫Ⅱ，同時為了釋放空間，對倉庫Ⅰ中的源數據發起了回收操作；到20:30 監控發現倉庫Ⅱ部分云盤出現IO異常。

故障原因復盤 本次事故起源自因磁盤靜默錯誤導致的單副本數據錯誤，再由于數據遷移過程中的不規范操作，導致異常數據擴散至三副本，進而導致客戶數據完整性受損。

數據搬遷過程中的違規操作主要如下兩點：

***是正常數據搬遷流程默認開啟數據校驗，開啟之后可以有效發現并規避源端數據異常，保障搬遷數據正確性，但是運維人員為了加速完成搬遷任務，違規關閉了數據校驗；
第二是正常數據搬遷完成之后，源倉庫數據應保留24小時，用于搬遷異常情況下的數據恢復，但是運維人員為了盡快降低倉庫使用率，違規對源倉庫進行了數據回收。

改進措施:經過技術復盤，騰訊云技術團隊深入到每個環節，通過責任到人與流程閉環的雙管齊下，相應作出如下的加強和改進措施：

首先，我們將全面審視所有的數據流程，涉及數據安全的流程自動化閉環，進一步提升我們常規運維自動化和流程化，降低人工干預。同時把全流程的數據安全校驗作為系統的常開功能，不允許被關閉。
其次，針對物理硬盤靜默數據錯誤，在當前用戶訪問路徑數據校驗自愈的基礎上，我們優化現有巡檢機制，通過優先巡檢主副本數據塊、跳過近期用戶訪問過的正確數據塊等方法，加速發現該類錯誤，進行數據修復。

總結一下，故障的原因是：操作人員手工關閉數據校驗，并且刪除了源庫，當發現『靜默錯誤』導致的損壞時悔之晚矣。

無論如何，現在的事故已經發生，我想整個實踐給行業以警示，我們的客戶已經在設置方案將云上的數據庫同步備份回本地。

而騰訊的一條改進建議是：提升自動化運維，降低人工干預。這一方面說明了自動化運維的重要性，另一方面仍然要警惕自動化中的故障傳播。

既然有這樣一個機會讓我們了解了『靜默錯誤』，那么我們可以進一步來看一看，在Oracle數據庫中的靜默錯誤是如何處理的。

首先還是回顧一下在我上一篇文章中描述的：什么是靜默錯誤。

什么是靜默錯誤

靜默錯誤在英文中被稱為：Silent Data Corruption，我們知道硬盤最核心的使命是正確的存入數據、正確的讀出數據，在出錯時及時拋出異常告警。磁盤出現異常的情形可能包括硬件錯誤、固件 BUG 或者軟件 BUG、供電問題、介質損壞等，常規的這些問題都能夠正常被捕獲拋出異常，而最可怕的事情是，數據處理都是正常的，直到你使用的時候才發現數據是錯誤的、損壞的。這就是靜默錯誤。

網上的一篇論文：Silent data corruption in SATA arrays: A solution - Josh Eddy August 2008 對靜默錯誤進行了解釋。這篇文章提到：

有些類型的存儲錯誤在一些存儲系統中完全未報告和未檢測到。它們會導致向應用程序提供損壞的數據，而不會發出警告，記錄，錯誤消息或任何類型的通知。雖然問題經常被識別為靜默讀取失敗，但根本原因可能是寫入失敗，因此我們將此類錯誤稱為“靜默數據損壞”。這些錯誤很難檢測和診斷，更糟糕的是它們實際上在沒有擴展數據完整性檢測功能的系統中相當普遍。

在某些情況下，當寫入硬盤時，應該寫入一個位置的數據實際上最終寫入另一個位置。因為某些故障，磁盤不會將此識別為錯誤，并將返回成功代碼。結果，RAID系統未檢測到“錯誤寫入”，因為它僅在硬盤發出錯誤信號時才采取措施。

因此，不僅發生了未檢測到的錯誤，而且還存在數據丟失。在圖2中，數據塊C應該覆蓋數據塊A，而是覆蓋數據塊B.因此數據塊B丟失，數據塊A仍然包含錯誤的數據！

結果，數據被寫入錯誤的位置; 一個區域有舊的，錯誤的數據; 另一個區域丟失了數據，RAID系統和HDD都未檢測到此錯誤。檢索B或C的訪問將導致返回不正確的數據而不發出任何警告。

撕裂寫入

在其他情況下，只有一些應該一起寫入的扇區最終會出現在磁盤上。這稱為“撕裂寫入”，其導致包含部分原始數據和部分新數據的數據塊。一些新數據已丟失，一些讀取將返回舊數據。同樣，硬盤不知道此錯誤并返回成功代碼，因此RAID無法檢測到它。訪問檢索B將返回部分不正確的數據，這是完全不可接受的。

上文提到的“撕裂寫入”，如果在 Oracle 數據庫中發生，那么就是分裂塊，當然 Oracle 數據庫會自動檢測這種情況。

那么“靜默損壞”發生的概率有多少呢？該文提供了一組數據：

...一項針對NetApp數據庫中150萬個硬盤驅動器的學術研究在32個月內發現，8.5％的SATA磁盤會產生靜默損壞。某些磁盤陣列運行后臺進程，以驗證數據和RAID奇偶校驗是否匹配，并且可以捕獲這些類型的錯誤。然而，該研究還發現，后臺驗證過程中錯過了13％的錯誤。

那些未被發現的錯誤，就會成為企業的災難。

即便沒有任何錯誤，數據也需要定期進行讀取，以確保數據無誤，在幾年前，我遇到過一起案例，Oracle 數據庫莫名的發生了一定批量的數據損壞，存儲上沒有任何錯誤，但是數據庫端大量的分裂塊，存儲沒有檢測到錯誤，并且復制到災備站點，***導致了數據丟失。

Oracle的靜默錯誤

如果存儲上出現了靜默錯誤，在Oracle數據庫中會是什么樣的表現？

毫無疑問，在Oracle中經常出現的『壞塊』就是靜默錯誤的受害者之一。幾乎所有的資深DBA都經歷過壞塊問題，當壞塊出現在索引時，通過重建往往就修復了，而一旦壞塊出現在數據或者元數據上，修復過程可能就比較復雜，甚至需要通過備份介質恢復，影響業務運行，更有甚者，會出現數據丟失，無法恢復的情況。

而壞塊出現的原因，很少能夠被明確定位，除了極少數的存儲介質物理故障，其他多數都是說不清楚原因的邏輯損壞，通常我們都期望這是一次偶然意外，期望以后不會發生，當然，的確這是一個小概率事件。

在 Google 上，能夠找到一些與『靜默錯誤』相關的文獻，由于這里不能鏈接，我統一放在下載中，大家可以自行下載學習：

Carnegie Mellon University – Disk failures in the real world: What does an MTTF of 1,000,000 hours mean to you? (2007)
CERN – Data integrity study (2007)
University of Wisconsin-Madison & Network Appliance – An Analysis of Data Corruption in the Storage Stack(2008)
Google – Failure Trends in a Large Disk Drive Population (2007)

經過很多研究表明，『靜默錯誤』真實存在，并且不僅僅是磁盤驅動器的原因，在某些情況下，電源電纜、HBA卡、有BUG的驅動程序或微碼也會導致靜默損壞。

在 Oracle 官網上有一篇 2013 年的文章：How to Prevent Silent Data Corruption，這篇文章的兩位作者一個是 Oracle Enterprise Linux 的內核開發者，另外一位來自 Emulex - 光纖卡廠商。

文章這樣描述靜默損壞：

靜默損壞是在沒有警告的情況下發生，可以定義為由于組件故障或無意的管理操作而導致的非惡意數據丟失。讀取或寫入無效數據時并不提示I/O問題，最終導致數據損壞。這種類型的損壞是迄今為止***災難性的，并且沒有有效的方法來檢測。

通常情況下，保證數據一致性的 ECC 和 CRC 技術可用于大多數服務器，存儲陣列和HBA。但是這些檢查僅在單個組件內臨時保護數據，無法確保寫入的數據在從應用程序傳輸到HBA，交換機，存儲陣列和物理磁盤驅動器的數據路徑中不會損壞。發生數據損壞時，大多數應用程序都不知道存儲在磁盤上的數據不是要存儲的數據。

在過去幾年中，EMC，Emulex和Oracle共同合作推動并實施了T10 SBC標準的附件信息保護功能，該功能可以在數據通過數據路徑時對數據進行驗證，以確保數據阻止靜默損壞的發生。

最終目標是通過創建完整性元數據（也稱為保護信息，與數據同時創建），然后在整個數據路徑中驗證元數據，并將錯誤回饋給應用程序進行修復，從而提供針對從應用程序到磁盤的靜默數據損壞的保護。下圖就是這個鏈路的保護過程：

寫入數據時會發生以下步驟：

***：Oracle自動存儲管理庫在寫入內存時為每個512字節扇區添加保護信息。

第二：保護信息附加到 I / O請求，并通過Oracle Linux操作系統內核中的層傳遞給Emulex驅動程序。

第三：Emulex LightPulse Lpe16000B光纖通道HBA從內存緩沖區收集信息，驗證數據完整性，合并數據和保護信息，然后根據T10 PI模型發送520字節扇區。

第四：EMC VMAX陣列固件驗證保護信息并將數據寫入磁盤。

第五：磁盤驅動器固件在將數據提交到物理介質之前驗證保護信息。

讀取數據時，步驟反向完成。

在2013年這篇文章提到，在基于 OEL 和 Emulex 的配置下，增強可以被啟用以防范數據損失：

這是多方努力的結果，在 oracleasm-discover 中可以觀察到相關信息：

# oracleasm-discover  
Using ASMLib from /opt/oracle/extapi/64/asm/orcl/1/libasm.so  
[ASM Library - Generic Linux, version 2.0.8 (KABI_V2)] Discovered   
disk: ORCL:P00 [20971520 blocks (10737418240 bytes), maxio 512, integrity DIX1-512/512-IP] Discovered disk: ORCL:P01 [20971520 blocks   
(10737418240 bytes),   
maxio 512, integrity DIX1-512/512-IP] [...]

進一步的展開一下，看看Oracle的增強一致性檢查實現。在復雜的數據流轉過程中，每一個步驟都可能產生數據分歧：

在典型的 I/O 處理棧中，***在存儲和驅動器層， 8 Byte 的 PI 校驗位才被增加進去，而存儲出現靜默錯誤問題時，頂層是無法感知的。

T10 的保護信息模型，就是增加額外 8 字節的校驗位，從應用到HBA再到底層存儲，層層校驗保護：

在***的 T10 PI 保護級別上，校驗位從應用層就開始被添加，實現了端到端的校驗：

在 Oracle 10g年代，Oracle 曾經推出 H.A.R.D. 計劃，全程是 - Hardware Assisted Resilient Data ，被翻譯為硬件輔助彈性數據（HARD）計劃，用于防止數據損壞。

在HARD 倡議下，Oracle與選定的系統和存儲供應商合作，構建可以及早發現損壞并防止損壞的數據寫入磁盤的操作系統和存儲組件，并且此功能的實施對最終用戶或DBA都是透明的。

要使用HARD驗證，所有數據文件和日志文件都放在符合HARD標準的存儲上，同時啟用HARD驗證功能。當Oracle將數據寫入存儲時，存儲系統會驗證數據。如果它看起來已損壞，則寫入將被拒絕并顯示錯誤。

HARD 的設計就是用于防范那些可能的靜默錯誤，以下這些描述就是典型的問題：

寫入損壞的塊

數據由Oracle寫入，并在到達磁盤之前被操作系統或硬件組件干預破壞。這些組件可能包括操作系統，文件系統，卷管理器，設備驅動程序，主機總線適配器和SAN交換結構。雖然Oracle可以在讀取數據時檢測到損壞，但Oracle可能會在幾天或幾個月后才讀取數據。到那時，用于恢復數據的良好備份可能不再可用。

將塊寫入不正確的位置

Oracle向磁盤上的特定位置發出寫入。不知何故，操作系統或存儲系統將塊寫入錯誤的位置。這可能導致兩個損壞：破壞磁盤上的有效數據并丟失已提交事務中的數據。

Oracle以外的程序對Oracle數據的錯誤寫入

Oracle數據文件可能被非Oracle應用程序覆蓋。非Oracle進程或程序可能會意外覆蓋Oracle數據文件的內容。這可能是由于應用程序軟件，操作系統中的錯誤或人為錯誤（例如，意外地將正常操作系統文件復制到Oracle數據文件上）。

損壞的第三方備份

將備份復制到磁帶時可能會發生數據損壞。這種類型的損壞特別有害，因為備份用于修復數據損壞。因此，如果備份也已損壞，則無法恢復任何丟失的數據。對于第三方備份尤其如此（其中磁盤存儲單元直接將數據復制到備份設備而不通過Oracle。）

可能的HARD檢查

在實現Oracle HARD功能的存儲系統中，Oracle服務器可以通過大量檢查來驗證Oracle塊結構，塊完整性和塊位置。如果塊在寫入時未通過驗證，則存儲器拒絕寫入，從而保護數據的完整性。在系統管理操作期間也可以選擇性地禁用HARD驗證檢查，這可能會暫時使數據處于不一致狀態。

關于這里描述的一種情形，讓我想到在2010年我幫助用戶進行恢復的一個案例，當時記錄在博客上，原文:

http://www.eygle.com/archives/2010/11/recover_archivelog_corruption.html

引用一下，用現在的定義就應該屬于『靜默錯誤』的范疇：

最近在緊急故障處理時，幫助用戶恢復數據庫遇到了一則罕見的歸檔日志損壞案例，在這里和大家分享一下，看看是否有人遇到過類似的問題。

在進行歸檔recover時，數據庫報錯，提示歸檔日志損壞：

***  
Corrupt block seq: 37288 blocknum=1.  
Bad header found during deleting archived log  
Data in bad block - seq:810559520. bno:170473264. time:707406346  
beg:21280 cks:21061  
calculated check value: 9226  
Reread of seq=37288, blocknum=1, file=/ARCH/arch_1_37288_632509987.dbf, found same corrupt data  
Reread of seq=37288, blocknum=1, file=/ARCH/arch_1_37288_632509987.dbf, found same corrupt data  
Reread of seq=37288, blocknum=1, file=/ARCH/arch_1_37288_632509987.dbf, found same corrupt data  
Reread of seq=37288, blocknum=1, file=/ARCH/arch_1_37288_632509987.dbf, found same corrupt data  
Reread of seq=37288, blocknum=1, file=/ARCH/arch_1_37288_632509987.dbf, found same corrupt data  
***

信息比較詳細，說37288號歸檔日志Header損壞，無法讀取數據。

提一個小問題：如果你遇到了這樣的錯誤？會怎樣思考？

如果這個歸檔日志損壞了，其實我們仍然有辦法跳過去，繼續嘗試恢復其他日志，但是客戶數據重要，不能容忍不一致性，這時候就只能放棄部分數據，由前臺重新提交數據了。這在業務上可以實現，也就不是大問題了。

好了，問題是為什么日志會損壞？是如何損壞的？

我首先要做的就是，看看日志文件的內容，通過最簡單的命令將日志文件中的內容輸出出來：

strings arch_1_37288_632509987.dbf > log.txt

然后檢查生成的這個日志文件，我們就發現了問題。

在這個歸檔日志文件中，被寫入了大量的跟蹤文件內容，其中開頭部分就是一個跟蹤文件的全部信息。

這是一種我從來沒有遇到過的現象，也就是說，當操作系統在寫出跟蹤文件時，錯誤的覆蓋掉了已經存在的歸檔文件，***導致歸檔日志損壞，非常奇妙，從所未見。

***我的判斷是，這個故障應當是操作系統在寫出時出現了問題，存在文件的空間仍然被認為是可寫的，這樣就導致了寫沖突，出現這類問題，應當立即檢查硬件，看看是否是硬件問題導致了如此嚴重的異常（日志做了掩碼脫敏）。

Dump file /ADMIN/bdump/erp_p007_19216.trc  
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - Production  
With the Partitioning, OLAP and Data Mining options  
ORACLE_HOME = /DBMS/erp/erpdb/10g  
Linux  
eygle.com  
2.6.9-34.ELhugemem  
#1 SMP Fri Feb 24 17:04:34 EST 2006  
i686  
Instance name: erp  
Redo thread mounted by this instance: 1  
Oracle process number: 22  
Unix process pid: 19216, image: oracle@eygle.com (P007)  
*** SERVICE NAME:() 2010-11-10 10:37:26.247  
*** SESSION ID:(2184.1) 2010-11-10 10:37:26.247  
*** 2010-11-10 10:37:26.247  
KCRP: blocks claimed = 61, eliminated = 0  
----- Recovery Hash Table Statistics ---------  
Hash table buckets = 32768  
Longest hash chain = 1  
Average hash chain = 61/61 = 1.0  
Max compares per lookup = 0  
Avg compares per lookup = 0/61 = 0.0  
----------------------------------------------  
----- Recovery Hash Table Statistics ---------  
Hash table buckets = 32768  
Longest hash chain = 1  
Average hash chain = 61/61 = 1.0  
Max compares per lookup = 1  
Avg compares per lookup = 1426/1426 = 1.0  
----------------------------------------------  
\GPAYMENTdxn  
AP_CHECKS  
Q(xn  
.1=N  
\Gxn  
.1=N  
^0e   
^0e!  
^0e"  
^0e#  
^0e$  
^0e%  
^0e&  
^0e'  
^0e(  
^0e)  
^0e*  
^0e+  
^0e+  
^0e&  
^ij1  
R0:b  
Q(xn  
PaymentsN  
a'VND  
Userxn  
AP_INVOICE_PAYMENTS  
105273  
5406105305-20101020-003  
3001CASH CLEARING  
CREATED  
Dump file /ADMIN/bdump/erp_p002_19206.trc  
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - Production  
With the Partitioning, OLAP and Data Mining options  
ORACLE_HOME = /DBMS/erp/erpdb/10g  
Linux  
eygle.com  
2.6.9-34.ELhugemem  
#1 SMP Fri Feb 24 17:04:34 EST 2006  
i686  
Instance name: erp  
Redo thread mounted by this instance: 1  
Oracle process number: 17  
Unix process pid: 19206, image: oracle@eygle.com (P002)  
*** SERVICE NAME:() 2010-11-10 10:37:26.263  
*** SESSION ID:(2187.1) 2010-11-10 10:37:26.263  
*** 2010-11-10 10:37:26.263  
KCRP: blocks claimed = 84, eliminated = 0  
----- Recovery Hash Table Statistics ---------  
Hash table buckets = 32768  
Longest hash chain = 1 
Average hash chain = 84/84 = 1.0  
Max compares per lookup = 0  
Avg compares per lookup = 0/84 = 0.0  
----------------------------------------------  
----- Recovery Hash Table Statistics --------  
Hash table buckets = 32768  
Longest hash chain = 1  
Average hash chain = 84/84 = 1.0  
Max compares per lookup = 1  
Avg compares per lookup = 880/880 = 1.0  
----------------------------------------------  
^A&A  
^1b#  
^1b!  
^1b"  
^0e'  
^Mj8  
^;&3  
2010PS_Legal Entity  
^6&L  
Eoi_VND  
Quick Payment: ID=47708

如此少見的案例，在此與大家分享。

那么關于『靜默錯誤』近年的進展有哪些呢？其實已經很少能夠看到 Oracle 和存儲廠商的進一步合作了，因為 Oracle 通過 ASM 技術的革新，通過針對 Linux 的增強，Oracle 逐步去強化和解決這些問題，尤其是在其自主的 Exadata 一體機中。

對于以上談到的『Oracle以外的程序對Oracle數據的錯誤寫入』情形，在 Oracle 12c中，通過 ASM 實現的 ASM FD特性，Oracle 可以將外部寫錯完全隔絕。參考文章：Oracle 12c ASM 防火防盜新特性揭秘。

參考文獻：

http://www.oracle.com/technetwork/articles/servers-storage-dev/silent-data-corruption-1911480.html
https://docs.oracle.com/cd/B12037_01/server.101/b10726/apphard.htm
https://bartsjerps.wordpress.com/2011/12/14/oracle-data-integrity/

責任編輯：龐桂玉來源：數據和云

靜默錯誤：Oracle數據庫是如何應對和處理的 ？

***故障回放

什么是靜默錯誤

Oracle的靜默錯誤

參考文獻：

靜默錯誤：Oracle數據庫是如何應對和處理的？