深入解析：ASM Normal Redundancy谁完成数据镜像IO？

张大朋（Lunar）Oracle 资深技术专家

Lunar 拥有超过十年的 ORACLE SUPPORT 从业经验，曾经服务于ORACLE ACS部门，现就职于 ORACLE Sales Consultant 部门，负责的产品主要是 Exadata，Golden Gate，Database 等。

编辑手记：我们不仅要学习一个知识点，还要从作者的验证过程，学习如何动手实战，从实践中得到真知。

前几天，一些朋友讨论ASM中提出一个问题：

如果是NORMAL redundancy磁盘组，数据的镜像是由oracle rdbms进程完成，还是由ASM的进程完成？

我们知道，ASM NORMAL REDUNDANCY磁盘组类似于RAID 10的操作，也就是镜像+条带化。

在传统架构中，Oracle只负责写入一份数据，数据保护（镜像）是由存储或者RAID卡来完成的，那么在ASM中是否也是DB完成一次写入，ASM进行同步呢？

根据下面的测试，结论是：

DB的进程完成数据库中所有应用数据的IO操作，包括镜像数据的IO。而ASM进程只负责元数据（metadata extent）的维护和IO。

具体测试如下：

首先，我们创建一个normal redundancy的磁盘组，用来存放数据库的redo，比如 +REDODG：

这个两个磁盘的failure group的信息如下：

磁盘信息和权限如下：

[oracle@lunardb1 ~]$ ll /dev/mapper/redolun* brw-rw---- 1 oracle oinstall 253, 8 Jun 16 10:39 /dev/mapper/redolun1 brw-rw---- 1 oracle oinstall 253, 9 Jun 16 10:39 /dev/mapper/redolun2

然后，我们使用REDODG创建了9组redo log group（这套10204的RAC的redo都放在上面了）:

这个数据库实例的LGWR进程号为 11159：

[oracle@lunardb1 ~]$ ps -ef|grep lgwr|grep lunar oracle 11159 1 0 Mar03 ? 08:01:25 ora_lgwr_lunar1 [oracle@lunardb1 ~]$ sys@lunar>select spid from v$process where PROGRAM like '%LGWR%'; SPID ------------ 11159

现在我们使用strace跟踪一下这个进程在数据库切换日志时的动作，如果lgwr进程只写了一个设备，比如/dev/mapper/redolun1或者/dev/mapper/redolun2，那么可以再跟踪一下ASMB进程。

如果LGWR进程写了两个设备，即/dev/mapper/redolun2和/dev/mapper/redolun1都写入了相应的IO，那么我们可以认为，数据库的LGWR自己完成了primary extent和mirror extent的全部操作。

这也是Oracle 文档中一直说明的一点“ASM负责ASM实例的metadata的IO，而DB完成应用实际数据的IO”。

具体跟踪文件如下:

上面的跟踪文件可以很清晰的看到，LGWR进程连续写了2分相同的数据到fd为16和17的设备上。

那么16和17是什么呢：

[oracle@lunardb1 fd]$ cd /proc/11159/fd [oracle@lunardb1 fd]$ ls -lrt total 0 lr-x------ 1 oracle oinstall 64 Jun 13 17:04 0 -> /dev/null lrwx------ 1 oracle oinstall 64 Jun 13 17:04 9 -> /u01/oracle/app/product/10.2/db_1/dbs/lkinstlunar1 (deleted) l-wx------ 1 oracle oinstall 64 Jun 13 17:04 8 -> /u01/oracle/app/admin/lunar/bdump/alert_lunar1.log lrwx------ 1 oracle oinstall 64 Jun 13 17:04 7 -> /u01/oracle/app/product/10.2/db_1/dbs/hc_lunar1.dat l-wx------ 1 oracle oinstall 64 Jun 13 17:04 6 -> /u01/oracle/app/admin/lunar/bdump/alert_lunar1.log l-wx------ 1 oracle oinstall 64 Jun 13 17:04 5 -> /u01/oracle/app/admin/lunar/udump/lunar1_ora_11099.trc lr-x------ 1 oracle oinstall 64 Jun 13 17:04 4 -> /dev/null lr-x------ 1 oracle oinstall 64 Jun 13 17:04 3 -> /dev/null l-wx------ 1 oracle oinstall 64 Jun 13 17:04 2 -> /u01/oracle/app/admin/lunar/bdump/lunar1_lgwr_11159.trc lr-x------ 1 oracle oinstall 64 Jun 13 17:04 18 -> /u01/oracle/app/product/10.2/db_1/rdbms/mesg/oraus.msb lrwx------ 1 oracle oinstall 64 Jun 13 17:04 17 -> /dev/mapper/redolun2 lrwx------ 1 oracle oinstall 64 Jun 13 17:04 16 -> /dev/mapper/redolun1 lrwx------ 1 oracle oinstall 64 Jun 13 17:04 15 -> socket:[32662] lrwx------ 1 oracle oinstall 64 Jun 13 17:04 14 -> /u01/oracle/app/product/10.2/db_1/dbs/hc_lunar1.dat lr-x------ 1 oracle oinstall 64 Jun 13 17:04 13 -> /u01/oracle/app/product/10.2/db_1/rdbms/mesg/oraus.msb lr-x------ 1 oracle oinstall 64 Jun 13 17:04 12 -> /dev/zero lr-x------ 1 oracle oinstall 64 Jun 13 17:04 11 -> /dev/zero lrwx------ 1 oracle oinstall 64 Jun 13 17:04 10 -> socket:[32659] lr-x------ 1 oracle oinstall 64 Jun 13 17:04 1 -> /dev/null [oracle@lunardb1 fd]$ [oracle@lunardb1 fd]$ ll 17 lrwx------ 1 oracle oinstall 64 Jun 13 17:04 17 -> /dev/mapper/redolun2 [oracle@lunardb1 fd]$ ll 16 lrwx------ 1 oracle oinstall 64 Jun 13 17:04 16 -> /dev/mapper/redolun1

这里看到，16和17就是redodg所使用的两个磁盘。也就是说，LGWR自己完成了primary extent和mirror extent的IO操作。

至此已经很清楚了，那么可以我们可以推断，DBWR等数据库操作也是有DB自己的进程完成了，而ASM只负责元数据的IO操作和维护。具体的测试，有兴趣的可以自己跟踪。

上面的跟踪信息还可以看到，实际上oracle使用AIO的方式（使用io_submit，io_getevents等），定期同步控制文件的信息，仍然是写16和17两个设备。

并且通知ARCH进程进行归档操作，并在完成后，写入alert.log的过程：

至此，已经完全可以得出结论，ASM的冗余操作分为两部分：

1，数据库中实际应用数据的冗余，primary extent和mirror extent都由数据库自己完成 2，ASM的元数据的镜像操作由ASM进程自己完成。

技术之道，求而索之，其乐无穷。