Patchmgr工具升级Exadata计算节点
0. 前言
patchmgr工具升级Exadata的计算节点，必须要求计算节点升级前的存储软件版本大于11.2.2.4.2，同时升级之后的存储软件版本大于或等于12.1.2.2.0。如果升级前或升级后的版本介于两者之外，则不能使用patchmgr工具来升级计算节点。
patchmgr升级工具，可以对计算节点进行滚动升级，也可以进行非滚动升级。滚动升级是每次只升级一个计算节点，升级成功之后，再升级下一个计算节点。非滚动升级是并行地升级所有的计算节点，如果其中的一个计算节点在先决条件检查阶段就失败，则整个升级进程将中止，而如果其中的一个计算节点是在安装补丁阶段或重启阶段失败，则patchgmr工具会跳过该失败的计算节点，其他的计算节点仍然正常升级。
1. 升级前准备工作
（1）下载最新的patchmgr工具，计算节点的patchmgr升级工具与存储节点或Infiniband交换机的patchmgr升级工具完全不同，计算节点的patchmgr升级工具对应补丁号：21634633，需要从MOS网站下载，patchmgr升级工具说明文档参数MOS文档dbnodeupdate.sh and dbserver.patch.zip: Updating Exadata Database Server Software using the DBNodeUpdate Utility and patchmgr【文档 ID 1553103.1】。强烈建议使用最新版本的patchmgr升级工具来进行计算节点的升级工作。而存储节点和Infiniband交换的patchmgr升级工具则是随着存储节点的升级包一起发布。
（2）检查/boot文件系统的剩余空间是否足够。
| # dcli -g /root/dbs_group -l root 'df -h /boot' |
（3）检查/etc/fstab文件是否存在NFS挂载条目，如果/etc/fstab中存在NFS挂载点，则需要将NFS挂载条目删除或注释掉，防止操作系统在启动过程中，自动挂载这些NFS文件系统。
（4）卸载所有的NFS文件系统，检查当前系统中是否有NFS文件系统，如果存在NFS文件系统，则在升级之前将这些文件系统卸载掉。
（5）停止所有用户的crontab任务，检查操作系统的root、grid、oracle用户下是否存在crontab定时任务，如果存在，则暂时注释掉，防止在计算节点的image升级过程中crontab定时任务自动运行。
（6）检查硬件类型：
| [root@dm01db01 ~]# dcli -g /root/dbs_group -l root "dmidecode -s system-product-name" |
（7）检查计算节点存储软件版本：
|
# imageinfo |
（8）备份计算节点操作系统。
（9）检查硬件与Firmware版本是否匹配：
| # dcli -g /root/dbs_group -l root '/opt/oracle.SupportTools/CheckHWnFWProfile' |
如果硬件与Firmware版本不匹配，则会升级失败。同时，存储软件的状态变成failure。
2. 升级先决条件检查
在正式的计算节点升级之前，务必先执行先决条件检查，先决条件检查工作不需要停机，对业务无任何影响，先决条件检查执行如下一些重要的检查：
- 验证当前Exadata的存储软件版本。Patchmgr升级工具要求升级前的存储软件版本至少为11.2.2.4.2，并且操作系统版本至少为OEL5.5。
- 验证升级包介质是否正常。
- 验证YUM配置是否正常。
- 检查已知的问题和最佳实践。
升级工具执行的先决条件检查中最重要的一步就是执行了YUM依赖关系检查，YUM依赖关系检查不是做真正的YUM 升级操作，而是做了YUM升级时的软件包依赖关系检查工作。因为计算节点升级出现故障绝大部分是由于客户个性定制的软件包存在依赖关系，所以在正式升级之前，务必先解决掉这些软件依赖问题，如下。
| #./patchmgr -dbnodes dbs_group -iso_repo ./p24669306_121233_Linux-x86-64.zip -target_version 12.1.2.3.3.161109 -precheck |
说明：在极少数环境中，patchmgr升级工具在做先决条件检查阶段，有可能需要删除某些软件包。如果发生这种情况，可以在先决条件检查阶段，加上nomodify_at_prereq参数，此时，patchmgr升级工具不会删除某些软件包，而只是会生成一个文件列表，列出正式做先决条件检查阶段，会删除的软件包名称，同样，加上nomodify_at_prereq参数后，先决条件检查也会失败。之后，我们可以再次运行先决条件检查而不带nomodify_at_prereq参数。
3. 管理已过旧的软件包
存储软件在11.2.3.3.0之前版本，相应的操作系统为OEL5，但之后的版本，操作系统也随着进行了升级，变成了OEL6，计算节点上的一些软件包也可能已经过旧，当进行计算节点升级时，patchmgr升级工具会将这些过旧的软件包罗列出来写进一个名为obsolete.lst的日志文件中。
如果想知道升级会导致哪些软件包过旧，在升级先决条件检查阶段，会将这些写入到/etc/exadata/yum/obsolete.lst文件中，可以直接查看obsolete.lst文件。如果没有额外的人工干预，这些被标记为过旧的软件包，在计算节点升级的过程中，会被删除掉。如果在升级的过程中，想阻止升级进程删除掉这些过旧的软件包，可以在每个计算节点中创建一个名为/etc/exadata/yum/exclusion.lst的文本文件，然后将你需要保留的那些过旧的软件包名称写入exclusion.lst文件中。例如：
|
[root@dm01 ]# cat /etc/exadata/yum/exclusion.lst |
此时，进行正式升级时，patchmgr升级工具会调用该文件，则不会删除java-*-openjdk软件包，而删除obsolete.lst文件中的其他软件包。
4. 正式升级过程
patchmgr工具升级过程分成两个阶段，第1阶段从计算节点（db01）上发起patchmgr工具，升级除了db01之外的所有计算节点，这些计算节点可以并行升级，也可以串行升级。第2阶段是在计算节点（db02）上单独升级计算节点（db01）。因为在计算节点(db01)上发起patchmgr升级工具时，它不能升级自己，所以需要分两次完成计算节点升级。
（1）进入patchmgr升级工具目录，并在升级工具目录下创建dbs_group配置文件：
|
(root)# cd /u01/12.1.2.3.3/DB/dbserver_patch_5.170123 |
该配置文件中记录了将进行升级的计算节点名或IP。
（2）正式升级计算节点。例如，在计算节点db01上发起patchmgr升级工具，正式升级除了db01之外的所有计算节点。
| [root@dm01db01 dbserver_patch_5.170123]# ./patchmgr -dbnodes dbs_group -iso_repo ./p25093501_121234_Linux-x86-64.zip -target_version 12.1.2.3.4.170111 -upgrade |
在升级过程中，计算节点需要重启多次，但这次升级时，计算节点hang住，无法正常关机。导致patchmgr升级脚本中断，后续的工作无法正常进行，其实在日志中也已经提到，只要服务器重新启动后，先检查存储软件的状态，如果状态为success，表示升级已经成功，后续只需要手动地执行dbnodeupdate.sh -c命令即可，dbnodeupdate.sh -c命令其实就是修复一些小的BUG，同时重新将GI集群和数据库relink成RDS协议。
5. 升级后工作
计算节点的image升级完成后，执行以下验证工作。
（1）如果/etc/fstab文件和crontab前期进行了注释，则需要去掉注释，还原至原来状态。
（2）升级完成后，使用imageinfo和imagehistory命令检查升级是否成功。
（3）查看GI集群中所有资源的状态是否正常。
（4）查看GI集群和RAC数据库的心跳协议是否为RDS。
浙公网安备 33010602011771号