1、传统方式的存储节点升级流程：

(1).将存储节点升级包下载到数据库服务器，通常是DB01上。

(2).解压缩存储节点升级包。

(3).用升级包中的patchmgr工具滚动或非滚动地升级每个存储节点。 这一步会细化成：patchmgr工具会调用dcli工具将升级包上传到每个存储节点，然后在每个存储节点的inactive partition上安装新的升级包，最后会将原有的active partition和inactive partition进行调换，也即原有的inactive partition会被激活，而原有的active partition会被去激活，从而达到升级的效果。

 

2、传统方式存在的缺陷：

(1).在整个升级过程中，发起patchmgr工具的会话必须一直存活着。

(2).滚动升级时，每次只能正式升级一个存储节点，即便ASM磁盘组是HIGH冗余模式。

(3).对于成百上千个存储节点的云平台，这种传统的升级方式就会显得非常麻烦。

(4).如果补丁更新频繁，每次都需要手动去升级补丁，就没有更多的时间去做其他事情。

 

3、云平台存储节点升级的特点：

(1).将存储节点升级包上传到一个统一的资料库上。

(2).将资料库地址分发给所有的存储节点。

(3).对所有的存储节点设置一个升级时间表（schedule）和升级频率。

(4).当升级时间到达时，存储节点自动进行升级。

云平台存储节点升级时，无法直接指定是滚动升级，还是非滚动升级，ASM的状态就决定了滚动升级还是非滚动升级，例如：整个数据库已经关闭，ASM已经停止运行，或者ASM磁盘组已经全部dismount的情况下，则会自动进行非滚动升级。否则就会进行滚动升级，在进行滚动升级时，不再是像以前那样按照patchmgr指定的顺序来串行滚动升级了，而是相互竞争着，看谁最先执行offline griddisk，谁先成功offline griddisk，谁就开始正式升级，而offline griddisk失败的存储节点，会继续检查griddisk的asmdeactivationoutcome属性，直到能成功offline griddisk。

 

4、云平台存储节点升级的主要步骤：

(1)、设置统一的资料库的位置：

> alter softwareupdate store="<url-of-softwarestore-directory>"

(2)、设置自动升级的时间：

> alter softwareupdate time="<future date and time>"

(3)、设置自动升级的版本：

> alter softwareupdate name=<patch version>

(4)、设置自动升级的频率：

> alter softwareupdate frequency= {daily | weekly | biweekly }