在Oracle Database 11g之前，ASM的区（Extent）和AU是一一对应的，从11g开始，ASM的另外一个重要变化是区的大小不再是固定等于AU的大小，而是会随着分配的extent数量的变化而发生变化。
要理解上述概念，有一些背景知识需要我们了解：
1、 ASM实例不会去修改Database的内容，ASM实例只会去修改其Metadata block（即ASM Disk Header和ASM extent map）；
2、 Database Instance会在Shared Pool里维护ASM实例传过来的区映射块（Extent map blocks），每个Extent map block都对应一个ASM里的一个extent；
在ASM的世界里，AU（Allocation Units）和Extent都是空间分配的单位，只不过它们代表了两个不同的角度，AU是站在ASM disk的角度，而Extent则是站在文件的角度。
ASM除了支持镜像功能外，还支持条带化（Asm Striping），Stripe设置有两种类型，一种是粗粒度条带（Coarse Striping），Stripe Size等于AU大小，默认为1M，AU大小由隐含参数_asm_ausize定义；另外一种是细粒度条带（Fine Striping），Stripe Size为128K，由隐含参数_asm_stripesize定义。
通过以下查询可以获得数据库的隐含参数初始值：
SQL> SELECT x.ksppinm NAME, y.ksppstvl VALUE, x.ksppdesc describ 2 FROM SYS.x$ksppi x, SYS.x$ksppcv y 3 WHERE x.indx = y.indx AND x.ksppinm LIKE '%&par%'; Enter value for par: _asm NAME VALUE DESCRIB ------------------------------ ---------- --------------------------------------------------- _asm_disk_repair_time 14400 seconds to wait before dropping a failing disk _asm_ausize 1048576 allocation unit size _asm_blksize 4096 metadata block size _asm_acd_chunks 1 initial ACD chunks created _asm_maxio 1048576 Maximum size of individual I/O request _asmsid asm ASM instance id _asm_wait_time 18 Max/imum time to wait before asmb exits _asm_stripewidth 8 ASM file stripe width _asm_stripesize 131072 ASM file stripe size _asm_droptimeout 60 timeout before offlined disks get dropped (in 3s ticks) _asm_emulmax 10000 max number of concurrent disks to emulate I/O errors
ASM Stripe 类型是在Diskgroup Template层面定义的，如下是Oracle Database 10g默认的一些常见Template和Stripe类型的对应关系：
SQL> select * from v$asm_template where group_number=1 order by 4； GROUP_NUMBER ENTRY_NUMBER REDUNDANCY STRIPE SY NAME ------------ ------------ ------------ ------------ -- -------------------- 1 0 UNPROT COARSE Y PARAMETERFILE 1 1 UNPROT COARSE Y DUMPSET 1 6 UNPROT COARSE Y TEMPFILE 1 10 UNPROT COARSE Y CHANGETRACKING 1 9 UNPROT COARSE Y XTRANSPORT 1 3 UNPROT COARSE Y ARCHIVELOG 1 5 UNPROT COARSE Y DATAFILE 1 12 UNPROT COARSE Y DATAGUARDCONFIG 1 7 UNPROT COARSE Y BACKUPSET 1 8 UNPROT COARSE Y AUTOBACKUP 1 4 UNPROT FINE Y ONLINELOG 1 11 UNPROT FINE Y FLASHBACK 1 2 UNPROT FINE Y CONTROLFILE
可见，在默认设置下，保存在ASM中的控制文件、联机重做日志、闪回数据库日志是使用FINE类型的条带化设置，也就是每个条带为128K。而数据文件、归档日志、临时文件等则使用COARSE类型条带化设置，每个条带的大小跟AU大小相等，默认情况下是1M。
这也正是存在两种不同条带化的原因，对于较小的文件，如控制文件、日志文件，其单次IO操作的数据单元较小，所以可以使用细粒度的条带化；对于大文件，如常规的数据文件，其单次IO操作的单元较大（如1M），缺省就使用了粗粒度的条带化。
在默认设置下，当ASM为数据文件分配一个Extent的时候，实际上就是使用了一个AU，我们可以认为在性能考量上这是没有条带化的。
在ASMCA中，在磁盘组位置，右键中有管理模板选项，可以通过该选型查看模板类型，修改自定义模板：
以下是Oracle Database 11g数据库缺省模板的属性，与Oracle 10g不同的是，除了CONTROLFILE的条带化为Fine之外，其余皆为COARSE：
在Oracle 11gR2中，可以通过asmcmd来管理维护模板，使用该特性要求磁盘组的compatible.rdbms属性至少为11.2 ：
ASMCMD> mktmpl -G ORADG --striping coarse --redundancy unprotected --primary hot oradg ORA-15032: not all alterations performed ORA-15283: ASM operation requires compatible.rdbms of 11.2.0.0.0 or higher (DBD ERROR: OCIStmtExecute) ASMCMD> lsattr -l -G ORADG Name Value access_control.enabled FALSE access_control.umask 066 au_size 1048576 cell.smart_scan_capable FALSE compatible.asm 11.2.0.0.0 compatible.rdbms 10.1.0.0.0 disk_repair_time 3.6h sector_size 512
在ASM中修改磁盘组兼容性属性：
[grid@enmou1 ~]$ sqlplus / as sysasm SQL*Plus: Release 11.2.0.2.0 Production on Tue Mar 22 17:49:11 2011 Copyright (c) 1982, 2010, Oracle. All rights reserved. SQL> alter diskgroup ORADG set attribute 'compatible.rdbms'='11.2'; Diskgroup altered.
此后可以在asmcmd中进行相应的模板维护工作：
ASMCMD> lsattr -l -G oradg Name Value access_control.enabled FALSE access_control.umask 066 au_size 1048576 cell.smart_scan_capable FALSE compatible.asm 11.2.0.0.0 compatible.rdbms 11.2 disk_repair_time 3.6h sector_size 512 ASMCMD> mktmpl -G ORADG --striping coarse --redundancy unprotected --primary hot oradg ASMCMD> lstmpl -l oradg Group_Name Group_Num Name Stripe Sys Redund PriReg MirrReg ORADG 3 ORADG COARSE N UNPROT HOT COLD ASMCMD> chtmpl -G ORADG --striping fine oradg ASMCMD> lstmpl -l oradg Group_Name Group_Num Name Stripe Sys Redund PriReg MirrReg ORADG 3 ORADG FINE N UNPROT HOT COLD
注意这里的Primary/Secondary选项是Oracle 11gR2中增加的新特性，称为智能数据摆放（Intelligent Data Placement），该特性允许定义文件的Hot/Cold属性，对于Hot文件，ASM可以将其摆放在磁盘读写性能高的位置，如磁盘边缘。
--primary { hot | cold } - Intelligent Data Placement specification for primary extents, either hot or cold region.
--secondary { hot | cold } - Intelligent Data Placement specification for secondary extents, either hot or cold region.
asmcmd中新增的iostat命令可以帮助我们非常有效的去监控ASM磁盘组的IO响应与性能，包括冷热读写：
ASMCMD> iostat --region -t -G ORADG Group_Name Dsk_Name Reads Writes Cold_Reads Cold_Writes Hot_Reads Hot_Writes Read_Time Write_Time ORADG VOL3 1552384 8183808 0 0 0 0 .716 22.245
可以通过以下SQL来修改模板属性，如条带化类型：
SQL> ALTER DISKGROUP diskgroup_name ALTER TEMPLATE <tmpl> ATTRIBUTES (FINE);
注意，在Oracle11g中，ALTER TEMPLATE关键字被MODIFY TEMPLATE取代，但是两者皆可用
SQL> alter diskgroup ORADG modify template oradg attributes(fine); Diskgroup altered. SQL> alter diskgroup ORADG alter template oradg attributes(coarse); Diskgroup altered.
删除一个模板可以在asmcmd中执行：
ASMCMD> rmtmpl -G ORADG oradg
也可以在ASMCA中删除：
所谓的ASM条带化实际上决定了在ASM Disk上分配的AU和extent的对应关系，比如，如果用上述sql把ASM file templates改为了fine，则Oracle在分配一个1M的Extent的时候，实际上是会分配8个1M的AU，然后上述extent会被打散存储在这8个AU里，每个AU里都分配128K。
条带的分布算法参看下图。（该图摘录自Automatic Storage Management Administrator's Guide 11g Release 2）
也就是该磁盘组有8块磁盘，A,B,C表示不同的Stripe Chunk，每个chunk为128K大小。某ASM file的第一个chunk分配在disk1的第一个ASM file extent中，第二个chunk分配在disk2的第一个extent中，按此规律，一直分配到第八个chunk在disk8的第一个extent中，接下来第九个chunk（也就是上图中的I）又分配在disk1的第一个extent中，依次分配，直到该ASM file被完全条带化。
至于条带分配的宽度（如上例中是8），则由隐含参数_asm_stripewidth来决定，该参数默认值为8，通常我们不会修改该参数值。
由前面所讲述的背景知识我们知道，oracle在database instance的shared pool里存储extent map block，且extent map block和extent是一一对应的关系（在默认AU大小的情况下，一个extent的大小就是1M），如果我现在库的大小是1T，则我们可以计算出现在share pool里需要维护100万个extent map block。
Oracle意识到如果用ASM管理一个1T的库就需要维护100万个extent map block话，那随着所管理的库的容量越来越大，效率问题不容忽视。
MOS文档365468.1中这样写到：
ASM metadata storage requirements for databases greater than 10TB can be very high introducing inefficiencies in opening ASM files and increasing memory used for ASM metadata
于是在11g里，oracle改变了extent的大小，extent的大小将不再永远是1M，而是会随着分配extent数量的递增而改变。
在Oracle Database 11gR1中具体的规则如下：
其示意图如下（引自Oracle Database Storage Administrator's Guide 11g），可以看到自第20000个Extent开始，分配了8个AU单位：
我们可以稍微计算一下在11gR1里相应的extent分配的情况。
1、 AU=1M，库的大小为1T
则按照上述算法，oracle现在仅需分配53572个extent：
SQL> select 20000+20000+(1024*1024-20000-20000*8)/64 Extents from dual; EXTENTS ---------- 53571.5
2、 AU=64M
在11g里在创建disk group的时候可以手工指定AU的大小，库的大小为1T时，则按照上述算法，oracle现在仅需分配16384个extent：
SQL> select (1024*1024/64) extents from dual; EXTENTS -------------- 16384
3、AU=64M（11g里在创建disk group的时候可以手工指定AU的大小），库的大小为100T，则按照上述算法，oracle现在仅需分配62788个extent：
SQL> select 20000 + 20000 + (100*1024*1024-20000*64-20000*64*8)/(64*64) EXTENTS from dual; EXTENTS ------------------------------ 62787.5
在11gR2中规则又有所变化，具体如下：
使用1MB的AU和固定大小区，对于10TB的数据库，大约需要90M来存储Extent Map；而对于16MB的AU，Extent Map仅占用大约5.5MB内存。Oracle在11g里引入了“可变的区大小”技术，可以显著缩短数据库的启动时间、降低Shared Pool的内存消耗，并且一举解决了以前在10g里用ASM来管理海量数据时候的效率问题（因为extent map block的数量再也不会像以前那样动辄上百万了）。
