静默错误：Oracle数据库是如何应对和处理的 ？
|
在 Google 上，能够找到一些与『静默错误』相关的文献，由于这里不能链接，我统一放在下载中，大家可以自行下载学习：
经过很多研究表明，『静默错误』真实存在，并且不仅仅是磁盘驱动器的原因，在某些情况下，电源电缆、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 中可以观察到相关信息：
进一步的展开一下，看看Oracle的增强一致性检查实现。在复杂的数据流转过程中，每一个步骤都可能产生数据分歧：
在典型的 I/O 处理栈中，最后在存储和驱动器层， 8 Byte 的 PI 校验位才被增加进去，而存储出现静默错误问题时，顶层是无法感知的。
T10 的保护信息模型，就是增加额外 8 字节的校验位，从应用到HBA再到底层存储，层层校验保护：
在最高的 T10 PI 保护级别上，校验位从应用层就开始被添加，实现了端到端的校验：
在 Oracle 10g年代，Oracle 曾经推出 H.A.R.D. 计划，全程是 - Hardware Assisted Resilient Data ，被翻译为 硬件辅助弹性数据（HARD）计划，用于防止数据损坏。 （编辑：衡阳站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
