什么是ASM
ASM全称为Automated
Storage Management，即自动
存储管理，它是自Oracle10g这个版本Oracle推出的新功能。这是Oracle提供的一个卷管理器，用于替代操作操作系统所提供的LVM，它不仅支持单实例配置，也支持RAC这样的多实例配置。将给Oracle
数据库管理员带来极大的方便，ASM可以自动管理
磁盘组，并提供
数据冗余和优化。特别是对于企业极的大型数据库管理员来说，可以使管理员可以从管理成百上千个数据文件这些琐碎的日常事务中解脱开来，以便处理其它更为重要的事务上去。
在Oracle 10g这个版本之前，管理一个大型数据库成百上千个的数据文件对数据库管理员来说是一个既无技术含量又十分枯燥的工作，这要求数据库管理员要熟悉一些系统的LVM的相关知识，做好磁盘规化，LV的条带等相关的系统方面的相关操作。而使用自动
存储管理将大大减轻这方面的工作量，数据库管理员只需要管理少数几个磁盘组即可。一个磁盘组是ASM管理的一个逻辑单元，由一组磁盘设备组成。我们可以定义一个磁盘组作为数据库的默认磁盘组，Oracle会自动管理存储，包括创建、
删除数据文件等。Oracle会自动将这些文件与一个合适的数据库对象做关联，这样我们在管理这些对象时只需要提供对象的名称，而无需像以前那样提供详细的文件名。
ASM提供了很多有用的存储技术，如
RAID和LVM（逻辑卷管理）等。像这些技术一样，ASM允许你在一组独立的磁盘上创建一个单独的磁盘组。这样就实现了单个磁盘组的I/O均衡。同时ASM还实现了条带化(Striping)和磁盘镜像(Mirroring)以提高I/O的
性能和数据可靠性。与 RAID或LVM不同的是，ASM是在文件级实现的条带化和镜像，这样的实现方式给用户带了很大选择自由度，我们可以在同一个磁盘组中对不同的文件配置不同的存储属性，实现不同的存储方式。
2 11g中ASM都有哪些新特征
2.1 快速重新同步(ASM Fast Mirror Resync)
短暂的磁盘路径发生
问题时，
恢复ASM磁盘组(DISK GROUP)的允余性是很费时间的，特别是这种恢复操作需要重新布局整个磁盘组的情况下。ASM快速磁盘重新同步这个新特征能显著减少重新同步一块坏磁盘时这种情况的时间，当你更换了坏磁盘，ASM能够快速的同步ASM磁盘的extent。
任何使磁盘组临时不可用的问题被认为是暂时的失效，这是ASM快速重新同步新特征可以恢复的。磁盘路径失效，例如接口线问题，主机适配器问题，磁盘控制器问题，或者是磁盘电源问题这些都能引起瞬时失效。缺省的情况下，当一块磁盘脱机时，ASM会立刻移出该磁盘。ASM快速再同步功能够记录脱机磁盘在脱机期间该磁盘上区的所有的变化，当磁盘被修复或再次联机时，这期间更改的extent能够被快速的重新同步到刚才失效的这些磁盘中。
你可以设定DISK_REPAIR_TIME这个属性使失效磁盘在被修复和再次联机这段时间内重新整理这样的操作不发生。这个时间可以以分钟(m或M)或者小时(h或H)为单位，如果你不指定时间单位，缺省的时间单位为小时。如果DISK_REPAIR_TIME这个属性没有设定，其缺省值为3.6小时。需要注意的是，这个缺省值适用于磁盘被设定为脱机模式而操作语句没有DROP AFTER子句这样的情况。大部分来说环境，3.6个小时这个DISK_REPAIR_TIME缺省属性数值应该都是合适的。
注意：
使用这项新功能，ASM磁盘组的兼容性需要设定至11.1或更高。
例：
CREATE DISKGROUP asmdskgrp1 DISK '/dev/raw/*'
SET ATTRIBUTE 'compatible.rdbms' = '11.1'， 'compatible.asm' = '11.1';
只有当包含脱机磁盘的磁盘组再次被挂上，消逝时间(自磁盘被设定成脱机模式后)都是增加的，V$ASM_DISK的REPAIR_TIME这列显示的是脱机磁盘在被删除之前所剩余的时间(单位：秒)，当指定的时间到达后，ASM删除磁盘，可以用带有DROP AFTER的ALTER DISKGROUP DISK OFFLINE语句来覆盖这个属性。
注意：
DROP AFTER也是11g的新特征。
如果一条ALTER DISKGROUP SET ATTRIBUTE DISK_REPAIR_TIME操作的磁盘组含有脱机的磁盘，这个属性只对当前那些非脱机模式的磁盘是生效的。
当一块脱机磁盘被第二次执行脱机操作，消逝时间会被重置并重新开始计算。如果另一个时间这块磁盘又被执行了DROP AFTER操作，上一个值会被覆盖并且新值生效。不能用ALTER DISKGROUP DROP DISK语句删除处于脱机状态的磁盘，这样操作时会报错。如果在某时情况，例如磁盘不能够被修复，需要在DISK_REPAIR_TIME到达前把磁盘删除时，可以再次执行带有DROP AFTER子句的OFFLINE语句，DROP AFTER指定0H或0M，表示立刻删除。
你可以用ALTER DISKGROUP来设定磁盘组的DISK_REPAIR_TIME属性，可以是分钟，也可以是小时，例如4.5小时或270分钟，例如：
ALTER DISKGROUP dg01 SET ATTRIBUTE 'disk_repair_time' = '4.5h'
ALTER DISKGROUP dg01 SET ATTRIBUTE 'disk_repair_time' = '270m'
在你修复磁盘后，运行ALTER DISKGROUP DISK ONLINE这条SQL语句可以使磁盘组恢复到联机状态，新的读写操作都可以正常进行了，这条语句也触发把磁盘维修期间内更改的extent从磁盘组冗余的数据重新同步到刚才失效的这些磁盘中。
2.2 ASM滚动升级
在
ORACLE11g及之后的版本，你可以把ASM的集群置为"滚动升级"模式，充许不同版本的ASM结点共同工作。滚动升级"模式中的每个结点能够独立的升级或打补丁，而不会影响到数据库的使用，因些其很大的提升数据库的正常运行时间。需要注意的是你只可以对ORACLE11g及之后的版本进行"滚动升级"，换句话说，你不能用这种功能把ORACLE10g的数据库升级到11G的。
在进行滚动升级前，你的环境也一定要做一定的准备的。举例来说，如果你使用了ORACLE Clusterware软件，在你开如做滚动升级前，Clusterware也一定要完整的升级到下一个满足要求的版本。当然，做Clusterware 升级时也应当用滚动的方式，更大的确保高稳定性和最大的正常运行时间。
在对一个结点的ASM软件打补丁或进行升级之前，必须把ASM集群置为滚动升级模式，这允许开始升级和操作你的环境在多个软件版本的模式，语句如下：
ALTER SYSTEM START ROLLING MIGRATION TO number;
number是由版本号、发行号、更新号、端口发行号和端口更新号这几部分组成的，中间以逗号分开，例如11.2.0.0.0。
实例在运行这条语句时会检查你指定的number与当前已安装的软件版本是不是兼容。当升级开始后，ASM实例只有如下的一些操作才是充许的：
磁盘组挂载和卸载
数据库文件打开，关闭，重新设定尺寸和删除
限制访问ORACLE自带的视图和包，所有的全局视图都是失效的
在滚动升级开始后，可以任意一个宕掉ASM实例来进行软件升级，升级完的ASM实例在启动后会自动重新加入ASM集群。当集群中的所有实例都完成升级到最新的软件版本后，你就可以结束滚动升级模式了。
如果一块磁盘在ASM实例进行滚动升级时是脱机的，那么直到升级结速这块磁盘都会保持脱机的状态，而且直到ASM集群回到正常模式触发删除磁盘的记时器也是停止的。
如果升级过级出现问题，可以用同样的过程回滚结点的软件到之前的版本。集群的任一地方有数据重整操作，升级会失败，所以必须等数据重整操作完成才可以开始滚动升级。另外，只要集群中有一个结点是活动的，滚动升级状态是保留的。
如果一个集群正在进行滚动升级时一个新的ASM实例加进来，新的实例会被告知集群正处在滚动升级模式，你可以用如下的SQL语句查询ASM集群环境的状态:
SELECT SYS_CONTEXT('sys_cluster_properties'， 'cluster_state') FROM DUAL;
如果ASM集群所有的实例都停了，那么当任何一个ASM实例重新启动，这个实例都会脱离滚动升级模式。如要实例都重新启动后 还要进行升级，必须重新开始滚动升级操作。
当滚动升级完成后，运行如下的SQL:
ALTER SYSTEM STOP ROLLING MIGRATION;
发出这条语句后，ORACLE做了如下的一些操作：
校验ASM集群的所有成员的软件版本是不是相同，如果一个或几个实例运行在不同的软件版本，这条语句会报错，集群继续处在滚动升级模式.
使集群的所有实例都脱离滚动升级模式，集群开始全功能工作
如果设定ASM_POWER_LIMIT参数允许数据重整理，因滚动升级而被阻塞的数据重整理操作会重新开始。
2.3 为ASM管理员新增了SY
SASM权限和OSASM操作系统用户组
在ORACLE10g这个版本，ORACLE没有为ASM管理员定制相应的角色，ASM管理员以SYSDBA角色进行管理工作，在实际工作中ASM管理员与数据库管理员可能是不同的两个或几个人完成的，相对来说权限界定不清晰.11g这一新特征引入SYSASM这一新权限目的就是为了清晰ASM管理员与数据库管理员的界面，防止越权操作的发生，使ASM管理员更好的进行ASM管理工作.
这一新特征同时在操作系统中也为ASM新增了OSASM用户组，OSASM这个组是专门为ASM
设计的，可以通过操作系统授权，被授权的这个组成员本地连接具有SYSASM权限，能够以SYSASM角色进行全权限的ASM管理工作。最初，只有ASM的安装用户是这个组的成员，在后继的工作，你可以添加新的用户到OSASM这个用户组，使新用户有ASM管理的全部权限。
需要注意的是，在ORACLE11g Release1的这个版本，系统OSDBA组的成员，连入数据库据有SYSDBA的权限，这样的用户仍然可以连接并管理ASM的实例，但相信在后续的版本中有SYSDBA权限的用户不会被授权有ASM实例的管理权限。
2.4 ASM 可扩展性和性能的增强
ASM文件区管理在11g都有改进，体现在性能的提升和显著的减少用于存储文件区的SGA内存方面。当ASM的文件在大小上增加时，每一个区的大小也会自动的增加，因此，会有需要很少的指向区指针描述文件。当访问20GB至128TB大小的ASM文件时11g的这个新特征会提升性能。当然，这样的文件通常是非常大的数据库(VLDBs)所用的。
除此之外，当你创建新的磁盘组时，你现在有多个分配单位大小选项，例如1， 2， 4， 8，16， 32， 和64(MB)。依据数据库的负载和
存储系统的类型，选择大的分配单位可能会获得明显的性能提升。
磁盘组存储的ASM文件的内容是由N个数据区组成的，数据区存储在独立的磁盘上。区包含一个或多个分配单位(AU).为适应逐渐增大的大文件，ASM使用变化大小的区。
变化大小的区能够支持更大的ASM文件，减少大数据库对SGA内存的使用，并且提升文件创建和打开操作的性能。一个ASM文件开始的一个区是由一个分配单位组成的。当文件大小增加时，如果大小超出预先定义的值，新的区大小也会增加到8分配单位，然后新的区大小增加到64个分配单位。对于新创建的文件，这一特征自动生效的。
分配单位的大小为多少在磁盘组建立的时侯确定，可以为1，2，4，8，16，32及64MB，当ASM文件的大小范围在1到20，000个区这个量级时，每个区的大小与分配单位的大小相等；ASM当文件大小超出20，000个区，到20，001到40，000个区这个范围，新的区的大小分自动增至8个分配单位大小；再有当ASM当文件大小超出40，000个区，，新的区的大小分自动增至64个分配单位大小。
图一表示的是含自块磁盘的磁盘组，文件由每个区1AU增至8AU的变化状况，在这个配置中，ASM没有做文件镜像的。
![]()
图一 磁盘组中ASM文件区分配图
(51 KB)