这两天，关于腾讯云“因无提示错误导致创业公司数据完全丢失”的事件传遍了全网，引发了广泛的热议和讨论。***故障回放腾讯云已于8月7日公布了最新一次事故的根源：故障过程回放当天上午1??1点57分，运维人员收到告警，空间使用率为I号仓库太高，即将启动搬迁扩容；14:05，从一号仓库中挑选出一批云盘，移至新二号仓库。为了加快迁移速度，手动关闭了迁移过程中的数据校验；20:27搬迁完成后，客户的云盘访问切换到二号仓库，同时为了释放空间，对一号仓库的源数据发起回收操作；20:30监控发现二号仓库部分云盘出现IO异常。故障原因回顾事故起源于磁盘静默错误导致的单份数据错误，由于数据迁移过程中操作不规范，异常数据扩散为三份，导致客户数据完整性受损。数据迁移过程中的违规操作主要有：***是正常数据迁移过程中默认开启数据校验。启用后，可以有效地从源头检测和避免数据异常，保证迁移数据的正确性。但为加快完成搬迁任务，违规关闭数据校验；二是正常数据搬迁完成后，源仓库数据要保留24小时，以备异常搬迁时进行数据恢复。在源仓库上进行了数据恢复。改进措施：经过技术审核，腾讯云技术团队深入到各个环节，通过对人负责和流程闭环双管齐下，相应地做了以下加强和改进措施：检查所有数据流程，涉及到数据的安全闭环流程自动化，进一步提高了我们日常运维的自动化程度和流程化程度，减少了人工干预。同时，将全程数据安全校验视为系统常开功能，不允许关闭。其次，针对物理硬盘静默数据错误，在当前用户访问路径数据校验和自愈的基础上，我们优化现有的检查机制，通过优先检查主副本数据块，跳过正确的用户最近访问过的数据块等方法来加速发现此类错误并进行数据恢复。综上所述，失败的原因是：运营商手动关闭了数据校验，删除了源库。当“无声错误”造成的损害被发现时，再后悔也来不及了。不管怎样，现在事故已经发生了，我觉得整个做法都是对行业的一个警示。我们的客户已经在制定计划，将云上的数据库备份同步回本地。腾讯的改进建议之一是提高自动化运维，减少人工干预。一方面，这说明了自动化运维的重要性。另一方面，我们仍然必须警惕自动化中的故障传播。既然有这样一个机会让我们了解“静默错误”，我们就可以仔细看看Oracle数据库中是如何处理静默错误的。首先，让我们回顾一下我在上一篇文章中描述的内容：什么是静默错误。什么是静默错误？静默错误英文叫做：SilentDataCorruption。我们知道，硬盘的核心使命就是正确存储数据，正确读取数据，并在出现错误时及时抛出异常警报。磁盘异常可能包括硬件错误、固件错误或软件错误、电源问题、介质损坏等，这些常规问题都可以正常捕获并抛出异常，最可怕的是数据处理正常。直到您使用它时，数据才会出错和损坏。这是静默错误。网络上的一篇论文：SATA阵列中的静默数据损坏：解决方案-JoshEddy2008年8月解释了静默错误。本文提到：某些类型的存储错误在某些存储系统中是完全未报告和检测不到的。它们会导致在没有警告、日志、错误消息或任何类型的通知的情况下向应用程序提供损坏的数据。虽然该问题通常被识别为静默读取失败，但根本原因可能是写入失败，因此称为“静默数据损坏”。这些错误很难检测和诊断，更糟糕的是，它们实际上在没有扩展数据完整性检查的系统中很常见。在某些情况下，当写入硬盘驱动器时，本应写入一个位置的数据实际上最终被写入了另一个位置。由于某些故障，磁盘不会将此识别为错误并会返回成功代码。因此，RAID系统不会检测到“坏写”，因为它只会在硬盘驱动器发出错误信号时采取行动。因此，不仅会发生未检测到的错误，还会丢失数据。在图2中，数据块C应该覆盖数据块A，却覆盖了数据块B。所以数据块B丢失了，数据块A仍然包含错误的数据！结果，数据被写入了错误的位置；一个区域有旧的、错误的数据；另一个区域丢失数据，RAID系统和HDD都没有检测到这个错误。检索B或C的访问将导致在没有警告的情况下返回不正确的数据。在撕裂写等情况下，只有一些应该一起写入的扇区最终出现在磁盘上。这称为“撕裂写入”，它会导致包含部分原始数据和部分新数据的数据块。一些新数据已经丢失，一些读取将返回旧数据。同样，硬盘驱动器不知道此错误并返回成功代码，因此RAID无法检测到它。访问RetrieveB会返回部分不正确的数据，这是完全不能接受的。上面说的“撕写”，如果发生在Oracle数据库中，就是一个splitblock，当然Oracle数据库会自动检测到这种情况。那么“无声伤害”发生的概率有多大？这篇文章提供了一组数字：...一项对NetApp数据库中150万个硬盘驱动器的学术研究发现，8.5%的SATA磁盘在32个月的时间内被悄无声息地损坏了。一些磁盘阵列运行一个后台进程来验证数据和RAID奇偶校验是否匹配，并且可以捕获这些类型的错误。然而，该研究还发现，在背景验证过程中遗漏了13%的错误。那些未被发现的错误可能会给企业带来灾难。即使没有错误，也需要定期读取数据，以确保数据正确。几年前，遇到过Oracle数据库中某批数据莫名其妙的损坏的案例。存储没有错误，但是数据库端有大量的分裂块，存储没有检测到错误，复制到灾备站点，最终导致数据丢失。Oracle的静默错误如果存储上出现静默错误，那么它在Oracle数据库中会是什么样子？毫无疑问，Oracle中经常出现的“坏块”就是静默错误的牺牲品之一。几乎所有的高级DBA都遇到过坏块问题。当索引中出现坏块时，往往可以通过重建来修复。一旦坏块出现在数据或元数据上，修复过程可能会更加复杂，甚至需要备份。介质恢复影响业务运营，更有可能发生数据丢失且无法恢复的情况。坏块的原因很少能被明确定位。除了极少数存储介质的物理故障外，大部分都是没有明确原因的逻辑损坏。通常我们都希望这是一个意外，希望以后不要发生，当然，这确实是小概率事件。在Google上，我可以找到一些与“无提示错误”相关的文档。由于我无法在此处链接它们，因此我将它们放在下载中。可以自行下载学习：卡内基梅隆大学——现实世界中的磁盘故障：MTTF1,000,000小时对你来说意味着什么？(2007)CERN–数据完整性研究(2007)威斯康星大学麦迪逊分校和网络设备–存储堆栈中数据损坏的分析(2008)Google–大型磁盘驱动器群体的故障趋势(2007)经过大量研究，已经表明“静默错误”是真实存在的，不仅是由磁盘驱动器引起的，在某些情况下，电源线、HBA卡、有问题的驱动程序或微代码也可能导致静默损坏。Oracle官网上有一篇2013年的文章：HowtoPreventSilentDataCorruption。本文的两位作者一位是OracleEnterpriseLinux的内核开发人员，一位是来自Emulex——一家光纤卡制造商。文章是这样描述静默损坏的：静默损坏是在没有警告的情况下发生的，可以定义为由于组件故障或无意的管理操作而导致的非恶意数据丢失。读取或写入无效数据不会提示I/O问题，最终导致数据损坏。这种类型的损坏是迄今为止最具灾难性的，并且没有有效的方法来检测它。通常，用于确保数据一致性的ECC和CRC技术可用于大多数服务器、存储阵列和HBA。但这些检查只是暂时保护单个组件内的数据，并不能确保写入的数据在从应用程序到HBA、交换机、存储阵列和物理磁盘驱动器的数据路径中不会被破坏。当数据损坏发生时，大多数应用程序并不知道存储在磁盘上的数据不是本应存储的数据。在过去几年中，EMC、Emulex和Oracle共同努力推动和实施T10SBC标准的附件信息保护功能，该功能在数据通过数据路径时对其进行验证，以确保数据免受静默损坏。最终目标是通过创建完整性元数据（也称为保护信息，与数据同时创建）提供从应用程序到磁盘的保护，然后在整个数据路径中验证元数据，并将错误报告回应用程序以进行修复.静默数据损坏保护。下图是这个链路的保护过程：写入数据时会发生以下步骤：***：Oracle自动存储管理库在写入内存时为每个512字节的扇区添加保护信息。第二：保护信息附加到I/O请求，并通过OracleLinuxOS内核中的一个层传递给Emulex驱动程序。第三：EmulexLightPulseLpe16000B光纤通道HBA从内存缓冲区收集信息，验证数据完整性，合并数据和保护信息，然后根据T10PI模型发送520字节的扇区。第四：EMCVMAX阵列固件验证保护信息并将数据写入磁盘。第五：磁盘驱动器固件在将数据提交到物理介质之前验证保护信息。读取数据时，步骤相反。正如这篇2013年的文章所述，在基于OEL和Emulex的配置中，可以启用增强功能以??防止数据丢失：这是多方努力的结果，可以在oracleasm-discover中观察到：#oracleasm-discoverUsingASMLibfrom/opt/oracle/extapi/64/asm/orcl/1/libasm.so[ASMLibrary-GenericLinux,version2.0.8(KABI_V2)]Discovereddisk:ORCL:P00[20971520blocks(10737418240bytes),maxio512,integrityDIX1-512/512-IP]Discovereddisk:ORCL:P01[20971520blocks(10737418240bytes),maxio512,integrityDIX1-512/512-IP][...]进一步展开看Oracle增强的一致性检查实现。在复杂的数据流转过程中，每一步都可能造成数据发散：在典型的I/O处理栈中，8BytePI校验位只在存储层和驱动层添加，而存储层最上层并不知道静默错误问题。T10的保护信息模型是额外增加一个8字节的校验位，从应用程序到HBA再到底层存储，逐层校验保护：在最高的T10PI保护级别，校验位从应用层开始开始加入实现端到端验证：在Oracle10g时代，Oracle曾经推出过H.A.R.D.plan，整个流程就是——HardwareAssistedResilientData，翻译成硬件辅助弹性数据（HARD）计划，防止数据损坏。在HARD倡议下，Oracle与选定的系统和存储供应商合作构建操作系统和存储组件，这些组件可以及早检测到损坏并防止将损坏的数据写入磁盘，并且此功能的实现对最终用户或DBA是透明的.使用HARD认证时，所有的数据文件和日志文件都放在符合HARD标准的存储中，同时开启HARD认证功能。当Oracle将数据写入存储时，存储系统会验证数据。如果它看起来已损坏，则写入将被错误拒绝。HARD是为了防止可能出现的静默错误而设计的，下面的描述是典型的问题：writecorruptedblockdata是Oracle写入的，在到达磁盘之前被操作系统或硬件组件干预损坏。这些组件可能包括操作系统、文件系统、卷管理器、设备驱动程序、主机总线适配器和SAN交换结构。虽然Oracle可以在读取数据时检测到损坏，但Oracle可能要到几天或几个月后才能读取数据。届时，用于恢复数据的良好备份可能不再可用。将块写入不正确的位置Oracle向磁盘上的特定位置发出写入。不知何故，操作系统或存储系统正在将块写入错误的位置。这可能导致两种损坏：破坏磁盘上的有效数据和丢失已提交事务中的数据。非Oracle应用程序可能会覆盖Oracle以外的程序对Oracle数据文件的错误写入。非Oracle进程或程序可能会意外覆盖Oracle数据文件的内容。这可能是由于应用程序软件、操作系统中的错误或人为错误（例如，意外地将正常操作系统文件复制到Oracle数据文件）。损坏的第三方备份将备份复制到磁带时可能会发生数据损坏。这种类型的损坏特别有害，因为备份用于修复损坏的数据。因此，如果备份也已损坏，则无法恢复任何丢失的数据。对于第三方备份尤其如此（其中磁盘存储单元直接将数据复制到备份设备，而无需通过Oracle。）可能的HARD检查在实现了OracleHARD特性的存储系统中，Oracle服务器可以验证Oracle块结构通过一些检查，块完整性和块位置。如果一个块在写入时验证失败，内存将拒绝写入，从而保护数据的完整性。HARD验证检查也可以在系统管理操作期间有选择地禁用，这可能会暂时使数据处于不一致状态。关于这里描述的一个情况，让我想起了我在2010年帮助用户恢复的一个案例，当时记录在一个博客上，原文：http://www.eygle.com/archives/2010/11/recover_archivelog_corruption.html引用一下，目前的定义应该属于“静默错误”的范畴：最近在处理紧急故障，帮助用户恢复数据库时，遇到了罕见的归档日志损坏案例。在这里分享给大家，看看有没有人遇到过类似的问题。执行归档恢复时，数据库报错，提示归档日志损坏：***Corruptblockseq:37288blocknum=1.BadheaderfoundduringdeletingarchivedlogDatainbadblock-seq:810559520.bno:170473264.time:707406346beg:21280cks:21061lock2q3qRereadof1,92=rereadvalue28/ARCH/arch_1_37288_632509987.dbf,foundsamecorruptdataRereadofseq=37288,blocknum=1,file=/ARCH/arch_1_37288_632509987.dbf,foundsamecorruptdataRereadofseq=37288,blocknum=1,file=/ARCH/arch_1_37288_632509987.dbf,foundsamecorruptdataRereadofseq=37288,blocknum=1,file=/ARCH/arch_1_37288_632509987.dbf,foundsamecorruptdataRereadofseq=37288,blocknum=1,file=/ARCH/arch_1_37288_632509987.dbf,foundsamecorruptdata***资料比较详细，说37288号归档日志Header损坏，数据无法读取读。只是一个简单的问题：如果你遇到这样的错误怎么办？你会怎么想？如果归档日志损坏，我们还有办法跳过它，继续尝试恢复其他日志，但客户数据很重要，不能容忍不一致。这时我们只能舍弃部分数据，重新从前台提交数据。这在业务上是可以实现的，所以问题不大。好吧，问题是为什么日志损坏了？是怎么损坏的？我要做的第一件事就是查看日志文件的内容，通过最简单的命令输出日志文件的内容：stringsarch_1_37288_632509987.dbf>log.txt然后查看生成的日志文件，我们发现了问题所在。在这个归档日志文件中，写入了大量的trace文件内容，开头部分是一个trace文件的所有信息。这是我以前从未遇到过的现象，也就是说，操作系统在写出trace文件时，误覆盖了已有的归档文件，***导致归档日志损坏。这是非常美妙的，从没见过。***我的判断是这个失败应该是操作系统写的有问题，文件所在的空间仍然被认为是可写的，从而导致写冲突。如果出现此类问题，应立即检查硬件，看是否是硬件问题导致了如此严重的异常（日志已屏蔽脱敏）。Dumpfile/ADMIN/bdump/erp_p007_19216.trcOracleDatabase10gEnterpriseEditionRelease10.2.0.3.0-ProductionWiththePartitioning,OLAPandDataMiningoptionsORACLE_HOME=/DBMS/erp/erpdb/10gLinuxeygle.com2.6.9-34.ELhugemem#1SMPFriFeb2417:04:34EST2006i686Instancename:erpRedothreadmountedbythisinstance:1Oracleprocessnumber:22Unixprocesspid:19216,image:oracle@eygle.com(P007)***服务名称:()2010-11-1010:37:26.247***SESSIONID:(2184.1)2010-11-1010:37:26.247***2010-11-1010:37:26.247KCRP:blocksclaimed=61,eliminated=0-----RecoveryHashTableStatistics----------Hashtablebuckets=32768Longesthashchain=1Averagehashchain=61/61=1.0Maxcomparesperlookup=0Avgcomparesperlookup=0/61=0.0------------------------------------------------RecoveryHashTableStatistics----------Hashtablebuckets=32768Longesthashchain=1Averagehashchain=61/61=1.0Maxcomparesperlookup=1Avgcomparesperlookup=1426/1426=1.0------------------------------------------\GPAYMENTdxnAP_CHECKSQ(xn.1=N\Gxn.1=N^0e^0e!^0e"^0e#^0e$^0e%^0e&^0e'^0e(^0e)^0e*^0e+^0e+^0e&^ij1R0:bQ(xnPaymentsNa'VNDUserxnAP_INVOICE_PAYMENTS1052735406105305-20101020-0033001CASHCLEARINGCREATEDdumpfile/62erdumpfile/62trcOracleDatabase10gEnterpriseEditionRelease10.2.0.3.0-ProductionWiththePartitioning,OLAPandDataMiningoptionsORACLE_HOME=/DBMS/erp/erpdb/10gLinuxeygle.com2.6.9-34.ELhugemem#1SMPFriFeb2417:04:34EST2006i686Instancename:erpRedothreadmountedbythisinstance:1Oracleprocessnumber:17Unixprocesspid:19206,image:oracle@eygle.com(P002)***服务名称:()2010-11-1010:37:26.263***SESSIONID:(2187.1)2010-11-1010:37:26.263***2010-11-1010:37:26.263KCRP:blocksclaimed=84,eliminated=0-----RecoveryHashTableStatistics--------Hashtablebuckets=32768Longesthashchain=1Averagehashchain=84/84=1.0Maxcomparesperlookup=0Avgcomparesperlookup=0/84=0.0----------------------------------------------RecoveryHashTableStatistics--------Hashtablebuckets=32768Longesthashchain=1Averagehashchain=84/84=1.0Maxcomparesperlookup=1Avgcomparesperlookup=880/880=1.0------------------------------------------^A&A^1b#^1b!^1b"^0e'^Mj8^;&32010PS_LegalEntity^6&LEoi_VNDQuickPayment:ID=47708如此罕见的案例，在此分享给大家关于《SilentError》近年来的进展如何？事实上，甲骨文与存储厂商之间的进一步合作很少见，因为甲骨文通过ASM技术的革新和对Linux的增强，逐渐加强和解决了这些问题，尤其是在其独立的Exadata一体机中。针对上述“Oracle以外的程序写入Oracle数据出错”的情况，在Oracle12c中，通过ASM实现的ASMFD特性，Oracle完全可以写入外部错误。隔离。参考文章：Oracle12cASM防火防盗新特性揭晓。参考资料：http://www.oracle.com/technetwork/articles/servers-storage-dev/silent-data-corruption-1911480.htmlhttps://www.oracle.com/technetwork/articles/servers-storage-dev/silent-data-corruption-1911480.htmldocs.oracle.com/cd/B12037_01/server.101/b10726/apphard.htmhttps://bartsjerps.wordpress.com/2011/12/14/oracle-data-integrity/
