自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

靜默錯誤：Oracle數(shù)據(jù)庫是如何應(yīng)對和處理的 ？

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

這兩天，關(guān)于騰訊云『因為靜默錯誤,把創(chuàng)業(yè)公司的數(shù)據(jù)徹底搞丟了』的事件已經(jīng)傳遍了整個互聯(lián)網(wǎng)，引發(fā)了廣泛的熱議和討論。

***故障回放

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

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

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

數(shù)據(jù)搬遷過程中的違規(guī)操作主要如下兩點：

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

改進措施:經(jīng)過技術(shù)復(fù)盤，騰訊云技術(shù)團隊深入到每個環(huán)節(jié)，通過責任到人與流程閉環(huán)的雙管齊下，相應(yīng)作出如下的加強和改進措施：

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

總結(jié)一下，故障的原因是：操作人員手工關(guān)閉數(shù)據(jù)校驗，并且刪除了源庫，當發(fā)現(xiàn)『靜默錯誤』導(dǎo)致的損壞時悔之晚矣。

無論如何，現(xiàn)在的事故已經(jīng)發(fā)生，我想整個實踐給行業(yè)以警示，我們的客戶已經(jīng)在設(shè)置方案將云上的數(shù)據(jù)庫同步備份回本地。

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

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

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

什么是靜默錯誤

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

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

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

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

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

結(jié)果，數(shù)據(jù)被寫入錯誤的位置; 一個區(qū)域有舊的，錯誤的數(shù)據(jù); 另一個區(qū)域丟失了數(shù)據(jù)，RAID系統(tǒng)和HDD都未檢測到此錯誤。 檢索B或C的訪問將導(dǎo)致返回不正確的數(shù)據(jù)而不發(fā)出任何警告。

撕裂寫入

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

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

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

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

那些未被發(fā)現(xiàn)的錯誤，就會成為企業(yè)的災(zāi)難。

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

Oracle的靜默錯誤

如果存儲上出現(xiàn)了靜默錯誤，在Oracle數(shù)據(jù)庫中會是什么樣的表現(xiàn)？

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

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

在 Google 上，能夠找到一些與『靜默錯誤』相關(guān)的文獻，由于這里不能鏈接，我統(tǒng)一放在下載中，大家可以自行下載學(xué)習(xí)：

  • 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)

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

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

文章這樣描述靜默損壞：

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

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

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

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

寫入數(shù)據(jù)時會發(fā)生以下步驟：

***：Oracle自動存儲管理庫在寫入內(nèi)存時為每個512字節(jié)扇區(qū)添加保護信息。

第二：保護信息附加到 I / O請求，并通過Oracle Linux操作系統(tǒng)內(nèi)核中的層傳遞給Emulex驅(qū)動程序。

第三：Emulex LightPulse Lpe16000B光纖通道HBA從內(nèi)存緩沖區(qū)收集信息，驗證數(shù)據(jù)完整性，合并數(shù)據(jù)和保護信息，然后根據(jù)T10 PI模型發(fā)送520字節(jié)扇區(qū)。

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

第五：磁盤驅(qū)動器固件在將數(shù)據(jù)提交到物理介質(zhì)之前驗證保護信息。

讀取數(shù)據(jù)時，步驟反向完成。

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

這是多方努力的結(jié)果，在 oracleasm-discover 中可以觀察到相關(guān)信息： 

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

進一步的展開一下，看看Oracle的增強一致性檢查實現(xiàn)。在復(fù)雜的數(shù)據(jù)流轉(zhuǎn)過程中，每一個步驟都可能產(chǎn)生數(shù)據(jù)分歧：

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

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

在***的 T10 PI 保護級別上，校驗位從應(yīng)用層就開始被添加，實現(xiàn)了端到端的校驗：

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

在HARD 倡議下，Oracle與選定的系統(tǒng)和存儲供應(yīng)商合作，構(gòu)建可以及早發(fā)現(xiàn)損壞并防止損壞的數(shù)據(jù)寫入磁盤的操作系統(tǒng)和存儲組件，并且此功能的實施對最終用戶或DBA都是透明的。

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

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

寫入損壞的塊

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

將塊寫入不正確的位置

Oracle向磁盤上的特定位置發(fā)出寫入。不知何故，操作系統(tǒng)或存儲系統(tǒng)將塊寫入錯誤的位置。這可能導(dǎo)致兩個損壞：破壞磁盤上的有效數(shù)據(jù)并丟失已提交事務(wù)中的數(shù)據(jù)。

Oracle以外的程序?qū)racle數(shù)據(jù)的錯誤寫入

Oracle數(shù)據(jù)文件可能被非Oracle應(yīng)用程序覆蓋。非Oracle進程或程序可能會意外覆蓋Oracle數(shù)據(jù)文件的內(nèi)容。這可能是由于應(yīng)用程序軟件，操作系統(tǒng)中的錯誤或人為錯誤（例如，意外地將正常操作系統(tǒng)文件復(fù)制到Oracle數(shù)據(jù)文件上）。

損壞的第三方備份

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

可能的HARD檢查

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

關(guān)于這里描述的一種情形，讓我想到在2010年我?guī)椭脩暨M行恢復(fù)的一個案例，當時記錄在博客上，原文:

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

引用一下，用現(xiàn)在的定義就應(yīng)該屬于『靜默錯誤』的范疇：

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

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

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

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

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

如果這個歸檔日志損壞了，其實我們?nèi)匀挥修k法跳過去，繼續(xù)嘗試恢復(fù)其他日志，但是客戶數(shù)據(jù)重要，不能容忍不一致性，這時候就只能放棄部分數(shù)據(jù)，由前臺重新提交數(shù)據(jù)了。這在業(yè)務(wù)上可以實現(xiàn)，也就不是大問題了。

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

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

  1. strings arch_1_37288_632509987.dbf > log.txt 

然后檢查生成的這個日志文件，我們就發(fā)現(xiàn)了問題。

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

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

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

  1. Dump file /ADMIN/bdump/erp_p007_19216.trc  
  2. Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - Production  
  3. With the Partitioning, OLAP and Data Mining options  
  4. ORACLE_HOME = /DBMS/erp/erpdb/10g  
  5. Linux  
  6. eygle.com  
  7. 2.6.9-34.ELhugemem  
  8. #1 SMP Fri Feb 24 17:04:34 EST 2006  
  9. i686  
  10. Instance name: erp  
  11. Redo thread mounted by this instance: 1  
  12. Oracle process number: 22  
  13. Unix process pid: 19216, image: oracle@eygle.com (P007)  
  14. *** SERVICE NAME:() 2010-11-10 10:37:26.247  
  15. *** SESSION ID:(2184.1) 2010-11-10 10:37:26.247  
  16. *** 2010-11-10 10:37:26.247  
  17. KCRP: blocks claimed = 61, eliminated = 0  
  18. ----- Recovery Hash Table Statistics ---------  
  19. Hash table buckets = 32768  
  20. Longest hash chain = 1  
  21. Average hash chain = 61/61 = 1.0  
  22. Max compares per lookup = 0  
  23. Avg compares per lookup = 0/61 = 0.0  
  24. ----------------------------------------------  
  25. ----- Recovery Hash Table Statistics ---------  
  26. Hash table buckets = 32768  
  27. Longest hash chain = 1  
  28. Average hash chain = 61/61 = 1.0  
  29. Max compares per lookup = 1  
  30. Avg compares per lookup = 1426/1426 = 1.0  
  31. ----------------------------------------------  
  32. \GPAYMENTdxn  
  33. AP_CHECKS  
  34. Q(xn  
  35. .1=N  
  36. \Gxn  
  37. .1=N  
  38. ^0e   
  39. ^0e!  
  40. ^0e"  
  41. ^0e#  
  42. ^0e$  
  43. ^0e%  
  44. ^0e&  
  45. ^0e'  
  46. ^0e(  
  47. ^0e)  
  48. ^0e*  
  49. ^0e+  
  50. ^0e+  
  51. ^0e&  
  52. ^ij1  
  53. R0:b  
  54. Q(xn  
  55. PaymentsN  
  56. a'VND  
  57. Userxn  
  58. AP_INVOICE_PAYMENTS  
  59. 105273  
  60. 5406105305-20101020-003  
  61. 3001CASH CLEARING  
  62. CREATED  
  63. Dump file /ADMIN/bdump/erp_p002_19206.trc  
  64. Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - Production  
  65. With the Partitioning, OLAP and Data Mining options  
  66. ORACLE_HOME = /DBMS/erp/erpdb/10g  
  67. Linux  
  68. eygle.com  
  69. 2.6.9-34.ELhugemem  
  70. #1 SMP Fri Feb 24 17:04:34 EST 2006  
  71. i686  
  72. Instance name: erp  
  73. Redo thread mounted by this instance: 1  
  74. Oracle process number: 17  
  75. Unix process pid: 19206, image: oracle@eygle.com (P002)  
  76. *** SERVICE NAME:() 2010-11-10 10:37:26.263  
  77. *** SESSION ID:(2187.1) 2010-11-10 10:37:26.263  
  78. *** 2010-11-10 10:37:26.263  
  79. KCRP: blocks claimed = 84, eliminated = 0  
  80. ----- Recovery Hash Table Statistics ---------  
  81. Hash table buckets = 32768  
  82. Longest hash chain = 1 
  83. Average hash chain = 84/84 = 1.0  
  84. Max compares per lookup = 0  
  85. Avg compares per lookup = 0/84 = 0.0  
  86. ----------------------------------------------  
  87. ----- Recovery Hash Table Statistics --------  
  88. Hash table buckets = 32768  
  89. Longest hash chain = 1  
  90. Average hash chain = 84/84 = 1.0  
  91. Max compares per lookup = 1  
  92. Avg compares per lookup = 880/880 = 1.0  
  93. ----------------------------------------------  
  94. ^A&A  
  95. ^1b#  
  96. ^1b!  
  97. ^1b"  
  98. ^0e'  
  99. ^Mj8  
  100. ^;&3  
  101. 2010PS_Legal Entity  
  102. ^6&L  
  103. Eoi_VND  
  104. Quick Payment: ID=47708 

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

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

對于以上談到的 『Oracle以外的程序?qū)racle數(shù)據(jù)的錯誤寫入』情形，在 Oracle 12c中，通過 ASM 實現(xiàn)的 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/ 
責任編輯：龐桂玉 來源： 數(shù)據(jù)和云
數(shù)據(jù)庫Oracle靜默錯誤
相關(guān)推薦

2011-05-26 14:43:49

ORACLE數(shù)據(jù)庫異常處理

2022-08-16 14:40:09

SQL數(shù)據(jù)庫內(nèi)存結(jié)構(gòu)

2011-06-03 09:22:04

OracleOracle應(yīng)用服務(wù)器

2011-05-26 13:36:40

Oracle數(shù)據(jù)庫時間處理

2010-04-07 14:22:46

2009-05-18 13:18:54

字符Oracle字符串

2010-04-09 14:37:08

Oracle數(shù)據(jù)庫

2011-04-11 16:50:13

Oracle數(shù)據(jù)庫索引

2011-03-29 10:47:49

ORACLE數(shù)據(jù)庫

2010-04-19 16:01:54

2009-09-02 18:52:38

Oracle數(shù)據(jù)庫并行

2011-05-11 13:25:57

Oracle數(shù)據(jù)庫后備恢復(fù)

2018-01-24 19:59:03

數(shù)據(jù)庫Oracle壞塊

2011-03-23 16:54:38

數(shù)據(jù)庫聯(lián)機處理

2011-03-17 14:09:25

Oracle數(shù)據(jù)庫字符

2010-04-19 13:56:19

Oracle數(shù)據(jù)庫服務(wù)

2022-11-28 09:06:40

Oracle數(shù)據(jù)庫MySQL

2015-07-23 17:02:55

oracle創(chuàng)建數(shù)據(jù)庫

2023-09-05 08:40:57

刪除數(shù)據(jù)庫Oracle

2009-11-20 14:08:39

Oracle數(shù)據(jù)庫備份
點贊
收藏

51CTO技術(shù)棧公眾號