当前位置:首页 > 开发 > 数据库 > 正文

ASM内部原理(原创)

发表于: 2012-12-24   作者:czmmiao   来源:转载   浏览次数:
ASM
摘要: ASM的SGA组成 ASM实例的SGA包括Buffer Cache,Share Pool,Large Pool等。 需要注意的是Share Pool,因为Extent Map要放在这部分的内存中,需要根据数据量来估计Extent Map的大小做相应的调整。 Extent Map的大小可以根据所有文件大小的和来估算,使用下面的语句来计算所有文件和: Select sum(bytes)/(102

ASM的SGA组成
ASM实例的SGA包括Buffer Cache,Share Pool,Large Pool等。 需要注意的是Share Pool,因为Extent Map要放在这部分的内存中,需要根据数据量来估计Extent Map的大小做相应的调整。
Extent Map的大小可以根据所有文件大小的和来估算,使用下面的语句来计算所有文件和:
Select sum(bytes)/(1024*1024*1024) from v$datafile;
Select sum(bytes)/(1024*1024*1024) from v$logfile a, v$log b where a.Group#=b.Group#;
Select sum(bytes)/(1024*1024*1024) from v$tempfile where status='online';
这3个sum 的总和对应着数据库存放ASM中所有文件大小总和,对于使用External Redundancy 的磁盘组,每100G 需要1MB的Extent Map,根据这个比例计算Extent Map 所需要的空间,在加上额外的2MB就可以了。在实际工作中一般不需要考虑ASM SGA的配置,使用Oracle提供的缺省值就可以了。
ASM的后台进程
ASM 实例比RDBMS 实例多2个进程:RBAL和ABRn。
RBAL:这个进程也叫Rebalancer进程,负责规划ASM 磁盘组的Reblance活动。
ABRn:是RBAL进程的子进程,这个进程在数量上可以有多个,n从1~9,这组进程负责真正完成Reblance活动。
使用ASM 作为存储的RDBMS 实例也会多出2个进程:RBAL和ASMB
RBAL:这个进程的主要功能是打开每个磁盘的所有磁盘和数据的Rebalance。
ASMB:这个进程作为ASM 实例和数据库实例之间的信息通道。这个进程负责与ASM 实例的通信,它先利用Diskgroup Name从CSS 获得管理该Diskgroup的ASM实例的连接串,然后建立到ASM的持久连接,两个实例之间通过这条连接定期交换信息,同时也是一种心跳机制。
RDBMS实例要想使用ASM作为存储,RDBMS实例必须在启动时从ASM实例获得Extent Map,以后发生磁盘组的维护操作, ASM实例还要把Extent Map的更新信息通知给RDBMS 实例,这2个实例间的信息交换就是通过ASMB 进程完成的。这也就为什么: ASM 实例必须要先于数据库实例启动,和数据库实例同步运行,迟于数据库实例关闭。
注意:ASM 实例和数据库实例的关系可以是1:1,也可以是1:n。如果是1:n,最好为ASM 安装单独的ASM_HOME。

Disk Discovery

Disk Discovery是指Oracle确定磁盘能够被ASM实例使用的全过程。这个过程包括权限检查,内容检查,后者更为重要。在RAC环境下,存储设备是节点间共享使用的,同一个设备在不同节点的设备名称可能不一样,比如磁盘在节点1被标识为/dev/sdb1,而在节点2被标识为/dev/sdb2,而Oracle的数据文件只有一个路径名称,这样可能破坏数据。必须使用其他机制来解决这种不一致。

ASM的Disk Discovery就是用来避免这种不一致造成的危害。ASM的每个磁盘都是自描述的,由于ASM具有丰富的元数据,因此ASM并不是根据路径名称或者设备名称来判断磁盘的归属,而是根据这些自描述信息来确认的。因此ASM允许系统重启后的路径变化,也允许RAC节点间的ASM Disk的路径名称不同。但是作为良好的工作习惯,还是要保持路径信息的一致。

被ASM实例检查的所有磁盘构成一个Diskcovery Set,这些磁盘有参数ASM_DISKSTRING定义。ASM会在下列情况下进行Disk Recovery:

Mount diskgroup
Create diskgroup
Add disk
Online disk
Select from V$ASM_DISKGROUP or  V$ASM_DISK

ASM Striping

在介绍ASM条带之前先介绍下条带深度和条带宽度

条带深度
为了提高 I/O 效率,一次逻辑 I/O请求转化成物理 I/O 请求后,应该让这些物理 I/O 分布到最多的物理磁盘上去,也就是每个物理磁盘处理的物理I/O最少,最好只有一次 , 因而影响条带的一个重要因素就是一次逻辑 I/O请求的大小。
此外,系统中I/O的并发度不同我们对条带的配置要求也不同。例如,在高并发度且逻辑 I/O请求的大小都比较小的情况下,我们希望一块磁盘能同时响应多个I/O 请求;而在那些存在大的逻辑 I/O 请求的低并发度系统中,我们可能就需要多块磁盘同时响应一个 I/O 请求。无论是一个磁盘还是多个磁盘响应 I/O 请求,我们的一个原则是让一次逻辑 I/O 能被物理设备一次处理完成。
条带宽度
正如我们前面所述,无论是一个还是多个磁盘响应一个逻辑 I/O,我们都希望物理设备只处理一次 I/O 。因而在确定了条带深度的基础上,我们需要保证条带宽度 >= I/O 请求的大小/ 条带深度。这样就能最大程度的保证 I/O 请求的并发处理能力了。

block size为rdbms的逻辑存储单位,Extent为rdbms的逻辑扩展单位,AU为ASM的物理存储单位,ASM的条带深度为物理IO单位,决定了每次向磁盘发出IO请求的大小,ASM的条带宽度为一个条带分布的ASM磁盘数。

在ASM中的条带化是在ASM File级别配置的,可选的条带粒度有Fine和Coarse两种,由_asm_stripesize控制条带深度,由_asm_stripewidth控制条带宽度。对于Oracle来讲,db_block_size即设定的逻辑 I/O。db_file_multiblock_read_count就一次读取时最多并行的数据块的个数。在8i或者以上的版本之后,Oracle的每次实际最大IO大小为1MB由SSTIOMAX这个内部常数。在ASM环境下,单次最大物理IO大小由_asm_maxio决定。单次最大逻辑IO由 db_block_size*db_file_multiblock_read_count决定。 db_block_size*db_file_multiblock_read_count _asm_maxio无法超过 SSTIOMAX指定的1MB, 超过时配置无法生效,低于1MB时配置能够生效。 理论上条带宽度*条带深度>=2*db_block_size*db_file_multiblock_read_count是最优的IO配置。因为假如设置成与Oracle数据块相同大小,无法保证Oracle数据块的边界正好与条带单元的边界对应,如果不对应的话,就会出现大量的一个I/O由两个条带单元,来处理的情况。

粗粒度条带(Coarse Striping)

这种条带化条带粒度是在AU级别上实现的,每个条带粒度对应1个AU。及AU为1MB条带深度就为1MB,AU为16MB条带深度就为16MB。条带宽度将一直是1。宽度和条带深度不受_asm_stripewidth和_asm_stripesize控制。假设磁盘组由4个磁盘组成,则数据文件的第一个Extent写到磁盘1的AU2中,第二2Extent会被写到磁盘2的AU2中,第3个Extent会被写到磁盘3的AU2中,第4个Extent会被写到磁盘4的AU2中,第5个Extent会被写到磁盘3的AU3中,依次循环。

细粒度条带(Fine Striping)

这个条带化的条带粒度默认为128KB,也就是数据被以128KB为单位按照上文所述的方式进行条带读写。该条带化的情况条带宽度和条带深度分别受_asm_stripewidth和_asm_stripesize控制,其中在细粒度条带下,条带深度最大为1MB。

具体的实验过程可以参考
http://www.itpub.net/thread-1705245-1-1.html

两种条带的比较

之所以有两种条带化方法,主要是因为Oracle文件的区别。对于大部分Oracle文件(包括数据文件,归档日志,备份集),文件本身很大,每次IO操作的数据量也很大。对于这些文件操作时,真正的磁盘数据读写时间远大于磁盘头的寻址时间,因此这种模式下,使用个较大的条带策略(Coarse Striping)可以提供吞吐量。

而联机日志文件和控制文件,由于文件本身较小,每次IO操作数据量很小且对读写的延时性要求较高,采用Fine-Striping将数据分布到多个disk上。如果采用AU为单位分散文件内容,则磁头寻址在整个等待的时延中相当可观,故通过把数据分布到多个磁盘的AU上,通过并行的方式可以减少时延。同时,由于io粒度较小,数据同步到磁盘到磁盘的时间较短。

ASM和RDBMS交互

当ASM实例挂载一个磁盘组之后,ASM会把Disk Group Name、ASM Instance、Oracle Home Path等信息注册到CSS,这些信息会被RDBMS用来构造Connect String。当RDBMS启动过程中需要访问某个ASM File时,RDBMS会和CSS联系,从CSS获得Connect String,然后发起一个到ASM实例的连接,这条ASM和RDBMS实例之间的出事连接叫Umbilicus,只有RDBMS打开ASM File,这个连接就会保持活动。直到所有ASM FILE都被RDBMS关闭之后,这个连接才会关闭。在RDBMS一端,这个连接是ASMB后台进程,而在ASM方面,叫做Umbilicus Forground(UFG)。ASM和RDBMS通过这个连接发送互动信息。如果检查listener中ASM实例的注册信息,可以看到ASM不少OPEN状态,而是以BLOCKED状态注册的。BLOCKED状态禁止了通常方式的数据库连接,从而确保所有连接都是通过ASMB后台进程的路由完成,保证了ASM操作的安全性。

$lsnrctl status
LSNRCTL for Linux: Version 10.2.0.1.0 - Production on 24-DEC-2012 20:29:38
Copyright (c) 1991, 2005, Oracle.  All rights reserved.
Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521))
STATUS of the LISTENER
------------------------
Alias                     LISTENER_CZMMIAO2
Version                   TNSLSNR for Linux: Version 10.2.0.1.0 - Production
Start Date                24-DEC-2012 19:52:25
Uptime                    0 days 0 hr. 37 min. 12 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Parameter File   /u01/app/oracle/product/10.2.0/crs/network/admin/listener.ora
Listener Log File         /u01/app/oracle/product/10.2.0/crs/network/log/listener_czmmiao2.log
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=192.168.2.112)(PORT=1521)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=192.168.2.102)(PORT=1521)))
Services Summary...
Service "+ASM" has 1 instance(s).
  Instance "+ASM1", status BLOCKED, has 1 handler(s) for this service...
Service "+ASM_XPT" has 1 instance(s).
  Instance "+ASM1", status BLOCKED, has 1 handler(s) for this service...

Service "PLSExtProc" has 1 instance(s).
  Instance "PLSExtProc", status UNKNOWN, has 1 handler(s) for this service...
Service "czmmiao" has 2 instance(s).
  Instance "czmmiao1", status READY, has 2 handler(s) for this service...
  Instance "czmmiao2", status READY, has 1 handler(s) for this service...
Service "czmmiaoXDB" has 2 instance(s).
  Instance "czmmiao1", status READY, has 1 handler(s) for this service...
  Instance "czmmiao2", status READY, has 1 handler(s) for this service...
Service "czmmiao_XPT" has 2 instance(s).
  Instance "czmmiao1", status READY, has 2 handler(s) for this service...
  Instance "czmmiao2", status READY, has 1 handler(s) for this service...
The command completed successfully

创建ASM File的过程

1、RDBMS产生一个前台进程去连接ASM实例的进程,创建指令通过这个连接交给ASM实例

2、ASM实例根据创建指令创建文件,从磁盘分配AU;ASM会根据指令中指定的template或Diskgroup默认的template来决定文件的冗余、条带策略;

3、AU分配完成后,ASM就吧这个文件的Extent Map发送给RDBMS;ASM创建一个COD记录以跟踪目前这个挂起操作;

4、RDBMS发起IO操作,初始化这个ASM File,这时候不需要ASM介入

5、初始化完成后,RDBMS向ASM发生commit请求

6、ASM接到commit请求后,ASM的LGWR进程吧ACD Change Record写入到ACD Directory;然后ASM的DBWR进程吧Allocation Table、File Directory、Alias Directory异步写回磁盘;

7、如果RDBMS放弃创建,ASM会使用COD混滚文件操作。回滚操作会把Allocation Entries标志位Free,释放File Directory中的条目

ASM File的打开和IO过程

1、RDBMS向ASM Instacne发生file-open请求

2、ASM查看ASM SGA中是否存在相应的Extent Map,如果有则直接通过ASMB把Extent Map发生给RDBMS,如果没有则从File Directory,再通过ASMB把Extent Map发生给RDBMS

3、在10g中ASM会把整个ASM FILE的extent map都发生给RDBMS,在11g中只会返回前60个Direct Extent,Indirect Extent会在需要时载入。

4、ASM FILE的整个IO过程由RDBMS直接操作ASM FILE不需要ASM实例介入

删除ASM File的过程

1、RDBMS实例想ASM实例发出删除请求

2、ASM创建COD记录用于回滚操作,接着标记allocation table中的条目为free,释放File directory记录,删除alias direcotry中的别名记录。

3、如果此时ASM实例崩溃,则利用COD记录进行回滚

关于ASM的元数据读者可以参考
http://czmmiao.iteye.com/admin/blogs/1749971

ASM实例恢复

ASM实例和RDBMS实例一样,也可能出现异常,也需要进行实例恢复。在单实例环境下,这种恢复叫做ASM Instance Recovery。在RAC环境下,某个节点上的ASM实例出现故障,会触发其他节点上的ASM实例进行实例恢复,这种恢复叫做ASM Crash Recovery。这两种操作和RDBMS对应的恢复同名。

在ASM实例运行中,CSS起着IO隔离的作用。存储由ASM实例维护,但是RDBMS在运行过程中,并不是所有的读写都要借助ASM实例,RDBMS实例只在打开数据文件时需要从ASM实例获得Extent Map信息,并把这些信息保存在SGA中。而后的数据读写都是直接操作存储的。因此如果ASM实例终止,必须关闭所有使用该ASM的RDBMS实例,以确保这些RDBMS实例不能操作该ASM管理的存储上的数据,也就是IO隔离(IO Fencing)
ASM实例启动时,需要在CSS中注册,而所有使用ASM存储的RDBMS实例启动时,也要向CSS注册,同时从CSS获得ASM的连接串。RDBMS实例和ASM实例是通过由ASM实例端的UFG和RDBMS实例端的ASMB进程组成的通道进行通信的。如果ASM实例Crash,UFG就会终止RDBMS的ASMD进程,对于RDBMS而言,这个进程是个关键进程,起终止会导致RDBMS终止。两个实例除了主动向CSS注册,CSS也要跟踪两个实例中IO的健康状况,如果RDBMS实例终止,CSS通知ASM,ASM实例就替代RDBMS实例执行一些资源回收释放工作。ASM实例仍然正常运行。

在ASM实例恢复时,ASM是在每个磁盘组级别上进行恢复的,每个磁盘组上的ACD和COD两部分内容在ASM实例恢复中起重要作用,其前者相当于RDBMS中的联机日志,后者相当于Undo tablespace。ASM实例的恢复过程中,首先使用ACD内容吧ASM Cache恢复成一致的状态,然后再执行COD恢复,COD记录的都是长时间的操作,这一步就是回滚这些操作,比如回滚文件创建操作。ASM Recovery的技术和RDBMS的技术一致。


参考至:
《Oracle Automatic Storage Management: Under-the-Hood & Practical Deployment Guide》

                 大话Oracle Rac》张晓明著

                 http://www.cnblogs.com/huangjingzhou/articles/2140514.html

                 http://www.ibm.com/developerworks/cn/data/library/techarticles/dm-0812yuancg/

                 http://www.itpub.net/thread-1705245-1-1.html
                 http://www.orafaq.com/papers/tuning_asm.pdf
                 http://www.linuxidc.com/Linux/2012-01/51884.htm
                 http://www.emc.com/collateral/hardware/white-papers/h6015-oracle-data-warehouse-sizing-dmx-4-dell-wp.pdf
                 http://dbanotes.net/database/oracle_mbrc_sstiomax.html
本文原创,转载请注明出处、作者
如有错误,欢迎指正
邮箱:czmcj@163.com

ASM内部原理(原创)

  • 0

    开心

    开心

  • 0

    板砖

    板砖

  • 0

    感动

    感动

  • 0

    有用

    有用

  • 0

    疑问

    疑问

  • 0

    难过

    难过

  • 0

    无聊

    无聊

  • 0

    震惊

    震惊

编辑推荐
概述 ASM Filesystem是建立在ASM Diskgroup上的,并且有元数据描述其内容布局,并且这些元数据也是
前言: 今天继续吧这个系列补齐,这几天公司的项目比较忙,回到家已经非常的累了,所以也没顾得上天
JVM 内部原理 ======== JVM 虚拟机的功能主要是加载 class 文件,并执行其中的字节码。它包
【IT168 技术文档】 tapestry的URL形如/examples/app?service=page/Admin 能够保证有效运行的一个非
JVM内部原理 原文链接:http://blog.jamesdbloom.com/JVMInternals.html 原文作者:James D Bloom
一、下面是说明泛型的基本原理与代码的应用 /** * 利用反射就可以不用把StringBuffer装换成String,
struts2 实现原理解析 (2010-07-27 14:49:36)转载▼标签: filterdispatcherthreadlocalactionproxy
一直以来,总以为CPU内部真是如当年学习《计算机组成原理》时书上所介绍的那样,是各种逻辑门器件的
Directory Services(目录服务) 我们知道,当局域网的规模变的越来越大时,为了方便主机管理,我们使
前言 Entity Framework的全称是ADO.NET Entity Framework,是微软开发的基于ADO.NET的ORM(Object/Re
版权所有 IT知识库 CopyRight © 2009-2015 IT知识库 IT610.com , All Rights Reserved. 京ICP备09083238号