关于ORACLE RAC集群打GI补丁的内容补充

前几天写了一篇文章，内容介绍了如何给ORACLE RAC集群打GI补丁。由于平时ORACLE RAC集群打补丁接触的比较少，再加上连MOS账号都没有，补丁都是大佬们免费给我使用的，使得之前的文章有不少错误和遗漏。今天把之前的文章的一些错误和遗漏的细节，单独做一些再补充和纠正。

   1、在我们大多数DBA的通常印象中，打GI补丁通常是要用GRID用户打的。但咨询了大佬，发现我OUT了，贫穷限制了我的想象，以后不能再想当然了。大佬说打GI补丁要用ROOT用户。也就是要用ROOT用户执行opatchauto命令。

  2、根据lucifer三哥踩过的坑，强烈要求各位网友打补丁时，无论是数据库还是GI补丁，最好把opatch命令根据自己的数据库或GI版本升级到最新版本。

  3、当补丁从MOS上下载下来后，好好看一下里面的README文件，里面详细记录了升级的前置条件，仔细检查一下自己的数据库系统是不是符合要求，自己还要做哪些操作系统的设置才能满足打补丁要求。再三强调，一定要好好阅读说明文件，不能够蜻蜓点水。

  4、安装补丁时，要进入解压后的补丁目录进行补丁安装。

如果不进入补丁的解压目录，直接执行补丁安装，可能会报错。

 5、包括笔者我自己都有一个不好的毛病，认为打补丁表面上好像是一个简单的工作。实际上有些补丁是可以滚动升级的，升级时不用关闭实例。有些补丁是不支持滚动升级的，升级时要关闭数据库和监听的。这个还是要仔细看一下README文件，要三思而后行，不能犯经验主义错误。如果在生产环境中，打补丁时要做好数据备份，同时申请一下停机窗口。之前我在自己的实验机一个ORACLE 19C 单机实例上打补丁时，没有忘记了关闭数据库和监听，奇怪的是当时没有影响数据库服务的运行。现在想想有些后怕，如果是生产环境还能这样干吗？

  6、升级补丁时，建议执行一下补丁检查，这次不是让你看README文件，是要你执行命令看一下是否有补丁冲突。比如：

$GI_HOME/opatch/opatchauto  apply  /soft/24396050  -analyze。

或者

opatch prereq    CheckConflictAgainstOHWithDetail -ph ./。

最后做一下总结，在生产环境中，做一些数据库变更操作时，最好要好好考虑一下，要有详细的操作步骤安排，同时要做好数据备份，要牢记“备份高于一切”。一旦操作失败，要有相应的应对方法回溯。避免忙中出错和乱中出错，我看了很多DBA的文章，故障处理通常是在节假日或快下班、后半夜时，在这种情况下处理故障，通常人的思维意识不太清醒，所以DBA们要保持清醒的大脑。