深入解析: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进程自己完成。

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

原文发布于微信公众号 - 数据和云(OraNews)

原文发表时间:2016-05-27

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏EAWorld

对没有监控的微服务Say No!

目录: 一、监控简介 二、监控策略 三、总结 一、监控简介 微服务的特点决定了功能模块的部署是分布式的,大部分功能模块都是运行在不同的机器上,彼此通过服务调用...

3815
来自专栏沃趣科技

ASM 翻译系列第二十五弹:ASM 高级知识 When will my rebalance complete

原作者:Bane Radulovic 译者: 魏兴华 审核: 魏兴华 DBGeeK社群联合出品 When will my rebalance com...

3584
来自专栏腾讯云容器服务团队的专栏

Kubernetes 中 Pod 弹性伸缩详解与使用

本文将详细讲解HPA的核心设计原理和基于Hepaster的使用方法。此功能可以能对服务的容器数量做自动伸缩,对于服务的稳定性是一个很好的提升。

3.4K1
来自专栏沃趣科技

ASM 翻译系列第一弹:基础知识 ASM AU,Extents,Mirroring 和 Failgroups

原作者:Bane Radulovic 译者: 魏兴华 审核: 魏兴华 ASM Allocation Units 在ASM磁盘组中,最基本空间分配单位...

3277
来自专栏微服务生态

由多线程内存溢出产生的实战分析

一日凌晨,手机疯狂报警,短信以摧枯拉朽之势瞬间以百条的速度到达,我在睡梦中被惊醒,看到短信的部分内容如下:

776
来自专栏编程

高级运维工程师学习路线

信息安全公益宣传,信息安全知识启蒙。 ? 运维工程师在前期是一个很苦逼的工作,在这期间可能干着修电脑、掐网线、搬机器的活,显得没地位!时间也很碎片化,各种零碎...

2247
来自专栏磨磨谈

The Dos and Don'ts for Ceph for OpenStack

Ceph和OpenStack是一个非常有用和非常受欢迎的组合。 不过,部署Ceph / OpenStack经常会有一些容易避免的缺点 - 我们将帮助你解决它们

795
来自专栏数据和云

Oracle并发(CONCURREMT)收集统计信息

编辑手记:从11.2开始,可以通过CONCURRENT参数,启用表或分区的并行扫描,加快统计信息的收集速度。 作者简介:何剑敏 Oracle ACS华南区售后...

3145
来自专栏数据库新发现

Oracle数据恢复:格式化、ASM及字典损坏案例三则

链接:http://www.eygle.com/archives/2010/06/asm_format_dictionary.html

742
来自专栏杨建荣的学习笔记

一次ORA-00600问题的排查和分析(r5笔记第64、65天)

昨天处理了一起ora-00600的错误,其中也经历了各种曲折,真是雾里看花,看透了之后发现很多问题都是有原因的。 起初是开发说有一个job运行的时候报错了,数据...

3639

扫描关注云+社区