love wife love life —Roger的Oracle/MySQL/PostgreSQL数据恢复博客

Phone:18180207355 提供专业Oracle/MySQL/PostgreSQL数据恢复、性能优化、迁移升级、紧急救援等服务

normal diskgroup情况下的IO读取

本站文章除注明转载外,均为本站原创: 转载自love wife love life —Roger的Oracle/MySQL/PostgreSQL数据恢复博客

本文链接地址: normal diskgroup情况下的IO读取

前段时间,在ML的群中,原厂一个哥们发了图,图中提到oracle 12c之前,asm 的读取默认都是始终从primary extent开始的,然而从12c开始发生变化。
当时的图片我找不到了,在以前的文档中,我找到如下一个图,基本上类似:

normal diskgroup情况下的IO读取插图

 

 

 

 

 

 

 

从上面信息可以看出,测试表有17个extent,前面0~15,是1m大小,后面第16号extent是1m大小。 由于asm默认的au size
也是1m,那么,所以我们可以肯定的讲,我们所要查询的这条数据和前面这16个extent,都在一个au里面。

oracle里面,最小的分配单元是extent,而asm中最小的分配单元是AU.

从上面可以看到,我们的datafile 6大小是10m,而我创建的测试表占据2m(未建其他表),所以,我们的test_asm_read表
应该就在最前面的2个au当中。从上面的查询结果我们也可以看到,au分别存了2份,一份是primary extent,一份是
mirror extent, 我们来验证下:

从上面的信息,似乎还看不太出来,我直接通过dump 这个block,来看下它的具体offset,如下:

可以看到这里,实际上就是操作的offset 54632448,转换一下,就知道这个位置是第53个AU的第26个block(4096来计算).
如何换成8192计算,那么正好是我们的数据库block file 6,block 13.

这里需要补充点知识,asm的mirror 是以extent为单位进行,我这里的diskgroup data2中有2个disk,分别是/dev/sdb,/dev/sde,
换句话讲,我的测试表test_asm_read大小2m,实际上消耗了4m的asm空间,其中分别在2个disk中各站2m. 从前面我们的查询可以
看出,我们这个测试表一共分配了0~16个,也就是17个extent,这就是说着17个extent分别存在2个disk中,各一份。

我们知道这个block在第53个au中,一个1m/8k=128,那说明我们的13号block就在一个unit单元里面。

从这么dd内容来看,我们定位的位置是正确的。

我们再回到前面的问题来,上面的一连串block号,我们除以2,用db block_size来计算,那么就是如下数据:
/dev/sde   au (53) 11,12,17,26,33,42,49,58,65,79,81,90,97,106,113    au(54) 129 ,au 54的129-128=1,即是第1个block.
/dev/sdb   au (53) 128,122    au(54)139,au 54的139-128=11,即是第11个block.

注意,我这里是为8192个单位进行计算的。

这里我们可以发现一个意思的事情:所读取的/dev/sdb盘操作offset,如果是以4096单位计算的话,分别对应第53个au的如下block:

256 258 278,也就是第53个au的最后一个block,和第54个au的第2个block,第11个block。

同样通过上面dd的方式去查看,我发现这几个block中并没有我们查询的那条数据。

这里还有个问题要说明,那么就是我仅仅查询了一条数据,为什么strace的结果来看,server process读取了上述多个block呢?
这个很容易解释,因为我的测试表没有索引,该sql必须走全表扫描。会扫描读取高水位线以下所有的block。

最后一列代表的是读取的大小,简单计算一下,可以得出如下信息:
1: 一共读取了126个block。
2: 该条数据所在的block offset为54632448,介于54624256和54665216之间,然而我们可以看到oracle进程在下面还读取了file 14,也就是/dev/sdb上面的信息.
3: 如果说primary extent是位于/dev/sde上,那么也就同时读取了/dev/sdb盘,也就是说即使磁盘组是normal形式,仍然会读取mirror extent的。
4:从上面信息,我们还可以得出一点,oracle虽然会读取mirror extent,但是并不是去读取我们实际的block数据。

最终我们可以通过上述实验跟踪得出一个结论,该文档描述不准确,针对normal或high的diskgroup,不是说oracle就不读去mirror extent,只是说
当我们执行查询sql时,查询所返回的数据是从primary extent中读取的,但是同时也会读取mirror extent中的一些block,虽然不多。 不过目前不清楚
该操作的含义,我猜测可能是oracle通过这个读取操作来看mirror extent中的数据至少是完好可以读取的。这样可以保证当我们的primary extent不可用
时,可以从mirror extent中读取数据,而应用端是无所察觉的。

补充:
1) 在11gR2版本中,提供了一个新的特性Intelligent Data Placement(IDP),智能数据分布,该特性的用意是可以将我们asm实例中的较热diskgroup或较热的
datafile启用IDP特性,其意义实际上是将其数据分布至于disk的外圈,那样可以降低访问的延迟。如下几种情况适用于IDP:

1. 当磁盘组的使用率超过25%时;
2. database中数据文件的访问频率差异较大时,通俗的理解就是某些datafile io很高,其他相对较低,那么这时就可以诊断该datafile使用IDP特性;
3. 当diskgroup中disk数量越多时,效果将更加明显。

另外,要使用IDP,必须设置2个diskgroup 属性,至少要11.2,如下:

alter diskgroup DATA set attribute ‘compatible.asm’=’11.2’;
alter diskgroup DATA set attribute‘compatible.rdbms’=’11.2’;

可以通过如下2种方式去使用IDP特性,分别是diskgroup 级别和datafile文件级别:

ALTER DISKGROUP data ADD TEMPLATE datafile_hot ATTRIBUTE ( HOT MIRRORHOT);

ALTER DISKGROUP data MODIFY FILE ‘+DATA2/test/datafile/test.256.804807701’ ATTRIBUTE (HOT MIRRORHOT);

2)从11gR2开始,asm还提供了一个remap命令,当出现读取时发现corrupted sector时,asm尝试去进行block remap,当然我们也可以进行手工remap。
如果asm在remap时,默认仍然是写相同的位置,如果写入失败,会写到新的new allocation unit 中,如果仍然写入失败,会将该disk offline掉。
如果一个diskgroup中的多个盘都offline了,那么asm会强制将该diskgroup offline掉。
需要注意一点的是:remap命令是针对block级别,不过是一个范围操作,其操作本身并不是去修复错误的block,而且进行relocate操作。可以理解
为从mirror extent中去copy 正常的block过来进行覆盖。

Leave a Reply

You must be logged in to post a comment.