在滚动升级开始后，可以任意一个宕掉ASM实例来进行软件升级，升级完的ASM实例在启动后会自动重新加入ASM集群。当集群中的所有实例都完成升级到最新的软件版本后，你就可以结束滚动升级模式了。
如果一块磁盘在ASM实例进行滚动升级时是脱机的，那么直到升级结速这块磁盘都会保持脱机的状态，而且直到ASM集群回到正常模式触发删除磁盘的记时器也是停止的。
如果升级过级出现问题，可以用同样的过程回滚结点的软件到之前的版本。集群的任一地方有数据重整操作，升级会失败，所以必须等数据重整操作完成才可以开始滚动升级。另外，只要集群中有一个结点是活动的，滚动升级状态是保留的。
如果一个集群正在进行滚动升级时一个新的ASM实例加进来，新的实例会被告知集群正处在滚动升级模式，你可以用如下的SQL语句查询ASM集群环境的状态:
SELECTSYS_CONTEXT('sys_cluster_properties'， 'cluster_state') FROM DUAL;
如果ASM集群所有的实例都停了，那么当任何一个ASM实例重新启动，这个实例都会脱离滚动升级模式。如要实例都重新启动后 还要进行升级，必须重新开始滚动升级操作。
当滚动升级完成后，运行如下的SQL:
ALTER SYSTEMSTOP ROLLING MIGRATION;
发出这条语句后，ORACLE做了如下的一些操作：
l 校验ASM集群的所有成员的软件版本是不是相同，如果一个或几个实例运行在不同的软件版本，这条语句会报错，集群继续处在滚动升级模式.
l 使集群的所有实例都脱离滚动升级模式，集群开始全功能工作
l 如果设定ASM_POWER_LIMIT参数允许数据重整理，因滚动升级而被阻塞的数据重整理操作会重新开始。
1.1.3 为ASM管理员新增SYSASM权限和OSASM操作系统用户组
在ORACLE10g这个版本，ORACLE没有为ASM管理员定制相应的角色，ASM管理员以SYSDBA角色进行管理工作，在实际工作中ASM管理员与数据库管理员可能是不同的两个或几个人完成的，相对来说权限界定不清晰.11g这一新特征引入SYSASM这一新权限目的就是为了清晰ASM管理员与数据库管理员的界面，防止越权操作的发生，使ASM管理员更好的进行ASM管理工作.
这一新特征同时在操作系统中也为ASM新增了OSASM用户组，OSASM这个组是专门为ASM设计的，可以通过操作系统授权，被授权的这个组成员本地连接具有SYSASM权限，能够以SYSASM角色进行全权限的ASM管理工作。最初，只有ASM的安装用户是这个组的成员，在后继的工作，你可以添加新的用户到OSASM这个用户组，使新用户有ASM管理的全部权限。
需要注意的是，在ORACLE11gRelease 1的这个版本，系统OSDBA组的成员，连入数据库据有SYSDBA的权限，这样的用户仍然可以连接并管理ASM的实例，但相信在后续的版本中有SYSDBA权限的用户不会被授权有ASM实例的管理权限。
1.1.4 新的ASM 命令行(ASMCMD)命令和选项
ASMCMD有下列的四个新的命令: lsdsk、md_backup、md_restore 和remap。除此之外，你还能使用带有新选项的ls和lsdg命令。下面描述一下这四个新的ASM命令:
lsdsk -不论是否有一个ASM的实列正在运行，这个命令都能列出ASM磁盘的信息。当系统管理员或存储管理员想查看一下ASM实例都用了哪些磁盘时这个命令是非常有用的。
md_backup和md_restore- 这两个命令使能能够用相同的磁盘路径、磁盘名、失败组、属性、模板及目录结构别名来重新建立已经存在的磁盘组。你可以使用md_backup备份磁盘组的环境，在出现问题的时侯用mk_restore来恢复相应的磁盘组。
Remap-你可以使用这个命令重映射或者回复normal及high redundancy模式ASM磁盘组中的坏块，ASM读取ASM映像好的拷贝中相应的块，并且把这些块重新写回到磁盘组中一个替代的位置