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
本文原创，转载请注明出处、作者
如有错误，欢迎指正
邮箱:[email protected]