原标题：静默错误：Oracle 数据库是如何应对和处理的 ？

说明：关于本文提到的所有参考文档，一律上传分享，关注本公众号回复 122arch获得。

这两天，关于腾讯云『因为静默错误,把创业公司的数据彻底搞丢了』的事件已经传遍了整个互联网，引发了广泛的热议和讨论。

腾讯云已经于8月7日公布了最近这次事故的根本原因：

故障过程复盘 当天上午11:57，运维人员收到仓库Ⅰ空间使用率过高告警，准备发起搬迁扩容；在14:05时，从仓库Ⅰ选择了一批云盘搬迁至新仓库Ⅱ，为了加速搬迁，手动关闭了迁移过程中的数据校验；在20:27 搬迁完成之后，将客户的云盘访问切至仓库Ⅱ，同时为了释放空间，对仓库Ⅰ中的源数据发起了回收操作；到20:30 监控发现仓库Ⅱ部分云盘出现IO异常。

故障原因复盘 本次事故起源自因磁盘静默错误导致的单副本数据错误，再由于数据迁移过程中的不规范操作，导致异常数据扩散至三副本，进而导致客户数据完整性受损。

数据搬迁过程中的违规操作主要如下两点：

o第一是正常数据搬迁流程默认开启数据校验，开启之后可以有效发现并规避源端数据异常，保障搬迁数据正确性，但是运维人员为了加速完成搬迁任务，违规关闭了数据校验；

o第二是正常数据搬迁完成之后，源仓库数据应保留24小时，用于搬迁异常情况下的数据恢复，但是运维人员为了尽快降低仓库使用率，违规对源仓库进行了数据回收。

改进措施:经过技术复盘，腾讯云技术团队深入到每个环节，通过责任到人与流程闭环的双管齐下，相应作出如下的加强和改进措施：

o首先，我们将全面审视所有的数据流程，涉及数据安全的流程自动化闭环，进一步提升我们常规运维自动化和流程化，降低人工干预。同时把全流程的数据安全校验作为系统的常开功能，不允许被关闭。

o其次，针对物理硬盘静默数据错误，在当前用户访问路径数据校验自愈的基础上，我们优化现有巡检机制，通过优先巡检主副本数据块、跳过近期用户访问过的正确数据块等方法，加速发现该类错误，进行数据修复。

总结一下，故障的原因是：操作人员手工关闭数据校验，并且删除了源库，当发现『静默错误』导致的损坏时悔之晚矣。

无论如何，现在的事故已经发生，我想整个实践给行业以警示，我们的客户已经在设置方案将云上的数据库同步备份回本地。

而腾讯的一条改进建议是：提升自动化运维，降低人工干预。这一方面说明了自动化运维的重要性，另一方面仍然要警惕自动化中的故障传播。

既然有这样一个机会让我们了解了『静默错误』，那么我们可以进一步来看一看，在Oracle数据库中的静默错误是如何处理的。

首先还是回顾一下在我上一篇文章中描述的：什么是静默错误。

静默错误在英文中被称为：Silent Data Corruption，我们知道硬盘最核心的使命是正确的存入数据、正确的读出数据，在出错时及时抛出异常告警。磁盘出现异常的情形可能包括硬件错误、固件 BUG 或者软件 BUG、供电问题、介质损坏等，常规的这些问题都能够正常被捕获抛出异常，而最可怕的事情是，数据处理都是正常的，直到你使用的时候才发现数据是错误的、损坏的。这就是静默错误。

有些类型的存储错误在一些存储系统中完全未报告和未检测到。 它们会导致向应用程序提供损坏的数据，而不会发出警告，记录，错误消息或任何类型的通知。 虽然问题经常被识别为静默读取失败，但根本原因可能是写入失败，因此我们将此类错误称为“静默数据损坏”。这些错误很难检测和诊断，更糟糕的是 它们实际上在没有扩展数据完整性检测功能的系统中相当普遍。

在某些情况下，当写入硬盘时，应该写入一个位置的数据实际上最终写入另一个位置。 因为某些故障，磁盘不会将此识别为错误，并将返回成功代码。 结果，RAID系统未检测到“错误写入”，因为它仅在硬盘发出错误信号时才采取措施。

因此，不仅发生了未检测到的错误，而且还存在数据丢失。 在图2中，数据块C应该覆盖数据块A，而是覆盖数据块/archives/2010/11/recover_archivelog_

Oracle 售前工程师（广州、深圳、上海、武汉、北京、石家庄）

Oracle 高级工程师（上海、深圳、北京、成都、昆明、贵州、西宁）

MySQL 技术经理（上海、南京、成都）

超高待遇：丰厚的年终奖，五险一金，高额学习基金，团建旅游，法定节假日，福利假期等。

推荐他人成功入职有好礼（iPhone X）相送 。