eygle.com   eygle.com
eygle.com eygle
eygle.com  
 

« 《深入浅出Oracle》一书的电子版下载 | Blog首页 | ORA-00600 4000 及 4194 错误小记 »

DBA警示录:补丁升级需谨慎

前几天,在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-

 


历史上的今天...
    >> 2011-02-02文章:
    >> 2009-02-02文章:
    >> 2008-02-02文章:
           新年记喜事 好事有多多
    >> 2006-02-02文章:
           这世界说大就大
    >> 2005-02-02文章:
           华友的IPO历程-之二

无觅

By eygle on 2010-02-02 08:10 | Comments (6) | Case | FAQ | 2502 |

6 Comments

呵呵,原来他在itpub上面说的ocm是大师你啊!

自动当年,我们用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是一次全部分配的)。


CopyRight © 2004~2020 云和恩墨,成就未来!, All rights reserved.
数据恢复·紧急救援·性能优化 云和恩墨 24x7 热线电话:400-600-8755 业务咨询:010-59007017-7040 or 7037 业务合作: marketing@enmotech.com