上一篇讲了ASM fast mirror resync。此外在12.1这个版本的ASM中，引入了一个新的特性叫做ASM Disk Scrubbing。借用黄老的一句话“scrub对的是corruption，resync对的是stale，两者都是保证一个所谓的data integrity”。本篇主要介绍ASM Disk Scrubbing。

https://docs.oracle.com/database/121/OSTMG/GUID-ECCAE4F3-CFC5-4B55-81D2-FFB6953C035C.htm#OSTMG95351

来自官方文档的介绍

本次要测试3个场景：

• dd破坏数据块，手工触发scrub看是否可以修复
• dd破坏数据块，select看是否会有概率报错，以及ASM是否会尝试修复
• bbed修改其中一个mirror的某行数据，dbv确保不报错，ASM是否修此讹误

创建测试用的磁盘组，为了保证简单，只用2个盘做一个Normal的磁盘组。

之后创建一个1M的表空间，并且在这个表空间里创建一个表并插入数据。

确认文件编号：

确认文件在ASM中的AU分布：

这个数据文件只分配了一个AU，大小是4M，存在两个副本，分别位于两个磁盘上。

把这个文件弄出来。

确认这个就是数据文件。然后我们dd一个4M的空文件写回去。

首先这里插入一个概念，就是Normal冗余下，每个AU都有一个Primary copy和一个Secondary copy，ASM无论在何种情况下都会去读Primary的copy，当primary不可读时，就去读Secondary的copy，并且将这个copy写回Primary。

A) Block Corruption in Primary Extent
Block reads from disk is affected. Corruption will be found during read from primary extent, we report an ORA-1578 in the ASM alert.log and do a re-read of the same block (primary extent). If the second read fails as well, we read the block from the secondary extent (on a different physical disk) next. This failover to reading from secondary extent happens automatically and transparent for the user/session. If the secondary extent is not corrupt the user will get the results without any error indication other than ORA-1578 about the failed primary extent read in alert.log. Finally ASM will overwrite the corrupt block in the primary extent with the good copy from the secondary. This happens even when the block is unaffected by any transaction. ASM FINDS corrupt blocks in primary extent. That triggers automatically repair at next read.
B) Block Corruption in Secondary Extent
Because block reads always goes to the primary extent first, a corruption in the secondary extent does not have any effect on a read operation. At the next write the block becomes dirty and the new block image will overwrite the old corrupt block on disk. In case of block corruption in the secondary extent there is no diagnostics information available. A corruption in the secondary extent will normally only be seen if the block in the primary extent is also corrupt. ASM fixes corrupt blocks in secondary extent automatically at next write of the block.

所以，我们要破坏Primary的copy，不然看不到坏块触发。

所以，1号磁盘的26AU是primary，要拿NULL文件去覆盖它：

随后，我们读表：

第一次读，会卡顿一下，并且在后台刷出大量日志：

这里触发的就是ASM Normal冗余情况下，ASM利用另外一个mirror来修复坏块的情况，可以看到它读到错的块，就去读好块，然后repaired。但是注意，这里只修复了10到15号，一共6个坏块。事实上，这个表有8个块，看起来ASM只修复了data block，段头没有修复。

随后，我们利用ASM Disk Scrubbing来修复一下：

注意下面的日志很重要，它表示scrub特性发现了很多坏块，但是，但是，但是，10到15号块是没有，这也证明，ASM的mirror修好了这6个坏块。

下面开始实际修复这个文件，可以很清晰的看到Scrubbing用slave方式修复了刚刚报告的那些块。

继续把这个文件拿出来，做dbv校验：

bbed打开这个文件看：

而如果文件正常的话，打开应该是下面这个样子的：

但是Scrubbing有三种方式，基于文件，基于磁盘，基于磁盘组，据测试，三种方式都不可以完成头部块的修复。

到此，前面两个场景的测试就完成了。效果是有，但是并不是太好。

最后一个场景，用bbed手工修改其中一个AU的某行数据。让两个AU里某行数据不一样，但是确保dbv测试通过的情况下，ASM Disk Scrubbing会工作吗？

上面这段，确认了primary copy的位置。我们一会儿就要改这个copy。

可以得出该表TB_SCRUB的数据分布在第26个AU中(DISK_KFFXP=1/AU_KFFXP=26/XNUM_KFFXP=0)

是块8，9，10，11，12，13，14，15这些块。一共64kb。

验证如下：

dd if=/dev/mapper/data05 bs=8k count=8 skip=13320|strings| more

能看到表中的数据MINOR和MINOR。

然后我们用bbed修改这个minor.tab文件，这里要感谢翔宇解惑，他有很方便的方式来修改。

然后把这个minor.tab文件写回磁盘上。

在数据库上flush buffer_cache之后，查询数据。

如果，把这个磁盘offline呢？因为它是primary copy，它offline了，ASM会去读secondary copy，会看到之前的数据吗？

下面是全文的重点，这两份mirror是不一致的，但是都是合法的，从dbv等等一切block check方式上都看不出来它们的逻辑错。这个时候用ASM Disk Scrubbing手工运行一下会发生什么？

这两个互相矛盾的镜像会共存。offline 掉primary，读的secondary copy跟primary还是依然不一样的。所以Scrubbing对这种场景下的讹误是不会操作的。

— END