点击上方“IT那活儿”公众号，关注后了解更多内容，不管IT什么活儿，干就完了！！！
之前周末加班对一套x86系统上的12.2版本的数据库更打最新的RU补丁，更打到第3个GI节点时报错，报错如下：
日志中看可以看到执行/u01/app/12.2.0/grid/bin/patchgen recover -pi 33116894命令时报：shell-init: error retrieving current directory: getcwd:
cannot access parent directories:No such file or directory。
随后日志中提到需要到"/u01/app/12.2.0/grid/.patch_storage/NApply/2022-08-13_17-52-43PM"这个目录下，执行restore脚本来修复这个报错的影响（即还原GI_HOME）。首先要确认报错的原因，其次需要将该节点环境恢复好，以便重新应用补丁。关于报错原因，mos文档中《error retrieving current directory: getcwd: cannot access parent directories: No such file or directory (Doc ID 1475219.1)》描述与此次报错匹配，如下图：==》发生这种情况是因为执行命令的 shell 的当前目录已被删除或被重新创建。为了避免再次报错的方式就是换个目录再发起命令。另外，该节点因报错，导致节点无法正常拉起，而且软件也有更新，如下图：报错日志中提到需要执restore.sh脚本来还原GI_HOME。关于restore.sh在mos文档《Can You Delete $ORACLE_HOME/.patch_storage Directory ? (Doc ID 403218.1)》中有描述，如下图：==》大致意思是restore.sh可以移除当前inventory的变更。因在文档中未找restore.sh可以还原GI_HOME的字样，笔者考虑到打补丁时间以及执行restore.sh会不会有其它影响，所以就未采用日志中提到的执行restore.sh脚本。而是采用打补丁之前软件的冷备，进行解tar来恢复整个oracle目录。整个oracle目录压缩备份下来有20G,解tar还原过程也就20分钟。随后，换个目录重新调用opatchauto命令，这次补丁更打成功了。总结：
使用自动打补丁方式可能会遇到各种想不到的问题，但只要我们做好备份，给自己留好退路，那我们在打补丁遇到问题时才能从容面对。
