« 《深入浅出Oracle》一书的电子版下载 | Blog首页 | ORA-00600 4000 及 4194 错误小记 »
DBA警示录：补丁升级需谨慎
链接：https://www.eygle.com/archives/2010/02/dba.html
前几天，在ITPUB上看到一则网友的经验分享，纪录了一次Patch应用过程的曲折。
在这样曲折的过程中，我们可以注意到，对于一个关键的操作，无论采取怎样认真、细致、繁琐的测试、验证与规划都是值得的。
我们在很多工作中，要求都非常严格，一般都要进行工作步骤列表，制定可执行的回退方案等，有时候大家也觉得繁琐，但是繁琐的结果是可控，在穷举了可能的异常之后，我们才能胸有成竹的进行变更。
转引一下网友的经验之路：
由于种种原因，需要给数据库打patch，并且把db_cache_size和shared_pool_size改小。
先在备库打patch，期间，有一个lib文件提示无法覆盖；去metalink搜，发现note 739963.1,在aix下，升级和打patch过程中，即使所有服务都停止了，也会出现无法覆盖lib文件。
需要用root，执行/usr/sbin/slibclean，然后在重新运行patch apply。
这个步骤不算有太大的问题，不过一般slibclean文件应该是熟悉的，在安装手册里是有明确记录的步骤。
修改参数，原来的db_cache_size=6G,shared_pool_size=4G,需要修改为4G和3G。
然后切换HA，再在主机继续打patch。
谁知道，在切换到备机后，修改过参数的数据库无法启动，直接报错：ora-00064 object is too large to allocate on this o/s.
看来问题是出在修改过的参数上。没办法，创建pfile，将参数修改过来吧......
这个步骤除了参数文件修改引起了一些不应该出现的麻烦，我们认为在备机应用完补丁之后，可以尝试一下在备机启动实例，确认没有问题再切换主机。在备机100%确认验证无误之前，主机的数据库应当不动，至少保证数据库在一台主机可以正常运行。
在发生问题的过程中，为了减少对业务影响，启动应急数据库和另外两台数据库。
应急数据库启动没问题，帐务数据库启动没问题；计费数据库启动失败，提示无法lock控制文件，查看vg状态，都正常，最后查lv的个数，主库26，bcv上有34......
很多经验表明，启用应急数据库是一件极其重大的决定，在没有100%的把握时，尽量不要采取这个措施。当然，如果应急只是作为只读环境，那要简单得多。
bcv问题处理完，暂时业务不用中断，继续打patch。
局方的人将数据库切换到备机，我在主机打patch，又提示文件无法覆盖；执行/usr/sbin/slibclean也不管用！
ps -ef|grep ora发现很多oracle进程存在，ps -ef | grep pmon，没看到有记录；刚开始怀疑是局方没有切换HA，但是登录到备库，发现数据库已经在备库启动。
HA切换脚本是，先停listener，然后再停数据库，umount盘阵。但是不知道为什么还有进程在备库存在。
确认应用都已切换到应急数据库，杀掉主库所有oracle进程。
ps -ef|grep $ORACLE_SID|grep -v ora_|grep LOCAL=NO|awk '{print $2}'|xargs kill
重新打patch，一切正常。
颇为曲折。
后来在bcv验证，数据库启动不了，主要是share pool改小引起；本来以为100%没有事情的事情，最后还是出事了！
墨菲定律，没有100%的安全，所以事前的完善规划是极为重要的。
在这次补丁应用过程中，如果在各个步骤的操作之后，加上一些测试验证步骤，就可以避免异常出现时的忙乱，也就可以多一份从容。
-The End-
历史上的今天...
>> 2018-02-02文章:
>> 2011-02-02文章:
>> 2009-02-02文章:
>> 2008-02-02文章:
>> 2006-02-02文章:
>> 2005-02-02文章:
By eygle on 2010-02-02 08:10 | Comments (6) | Case | FAQ | 2502 |
呵呵，原来他在itpub上面说的ocm是大师你啊！
it's not me,i'm just reading that thread.
:)
自动当年，我们用tnsping干掉了4台P595以后
我就一直相信，oracle上没有什么操作时他妈的安全的。
我说的ocm不是大师；给我的感觉那个ocm不过是有证书的dba；打patch的主要原因是，那个ocm感觉生产库存在内存泄漏（后来才知道他判断的依据是，他一直认为，sga是一次全部分配的），然后他建议更改share pool；但是打patch当天，和客户商议好，先不改参数；但是在我打完patch的时候，客户dba认为没有什么问题，就把share pool的值改小了；在切换ha，数据库起不来，询问客户才知道他更改了参数……
我说的ocm不是大师；给我的感觉那个ocm不过是有证书的dba；打patch的主要原因是，那个ocm感觉生产库存在内存泄漏（后来才知道他判断的依据是，他一直认为，sga是一次全部分配的）。
我说的ocm不是大师；给我的感觉那个ocm不过是有证书的dba；打patch的主要原因是，那个ocm感觉生产库存在内存泄漏（后来才知道他判断的依据是，他一直认为，sga是一次全部分配的）。