oracle----关于PSU与rac中的rolling upgrade

随着Oracle软件越来越庞大,内部结构越来越'精密', 每个版本推出来的新特性,新功能总是有各种各样的缺陷;
而新版本中对上一个版本中遗留问题的修复又会引入新的问题

老DBA总结出来的: 只使用2-3年之前发布的'稳定版本' 对于新装系统的Oracle版本选型虽然仍具有指导意义, 但老汤认为越来越不适用了
比如2001年9i (9.0.1.0)开始推出的RAC, 现在已经进化到了11.2.0, 谁能有足够理由说9iR1, 9iR2或10gR2要比11gR2稳定呢?

事实是: RAC这个组件只会随着版本的升级变得越来越成熟, 越来越稳定, 所以当一个决定使用RAC来提供服务时, 对oracle版本的选择则建议选择较新的版本,
虽然不敢用最新推出的版本,至少要选择"次新"的版本,如11gR1

之所以使用较新的版本, 是因为最新版本的用户群小, 那么只有自己遇到某个问题(而不是很多人遇到同样/类似问题)的概率就大. 那么希望从用户社区获得帮助的可能性就小, 这样不利于快速解决问题; 当然,理论上,较老版本的用户群更大, 解决同样/类似问题的可能性更大

所以,在版本选择上需要从获得用户社区的支持及关键组件的稳定性两个方面作出决策;
有的时候,还要考虑DBA对哪个版本熟悉些

上面啰嗦了一下版本选择的问题, 权且当作下面内容的背景资料, 因为在一般情况下,部署一个版本后, 持续不断的地升级/打补丁是避免不了的事情

打补丁是DBA日常管理中的重要内容, 很多与稳定性,性能有关的问题都是由于bug导致的,
老汤前前后后为多套rac打了多次补丁, 都是基于11.1.0.7.0之上的,从最开始的PSU1,一直到1/4出来的PSU3, 中间还打了不少one off patches
想以这个贴总结一下

1, PSU的概念及包含的内容
PSU即 patch set update, 顾名思义, 即对于'补丁集'的更新; 下面举个例子
Oracle Database 11g 11.1.0.6.0 ------&gt是11gR1的基础版本
Oracle Database 11g Patch Set 1 11.1.0.7.0 --------&gt11gR1的第一个补丁集
Patch 9352179 : applied on Wed May 12 15:40:48 CST 2010 --------&gtPSU3

这个PSU3即可以在11.1.0.7.0上打, 也可以在11.1.0.7.1或11.1.0.7.2上打, 因为
11.1.0.7.1实际上就是在11.1.0.7.0上打了PSU1
11.1.0.7.2实际上就是在11.1.0.7.0或者11.1.0.7.1上打了PSU2
而每个PSU总是包含了在它之前发布的那个PSU的内容, 即psu3是psu2/psu1的超级,psu2是psu1的超级
并且, 每个psu还包含自上个psu发布以来另外解决的一些缺陷(以one off patch形式存在)


2, PSU发布规范

oracle以季度为单位来发布PSU, 每年的1.1, 4.1, 7.1 ,10.1都会发布关键补丁更新

3, 如何打PSU
打补丁之前要仔细查看readme.htm文档
几个关键的步骤:
1) 检查readme.htm,列出主要注意事项,及打补丁的大致步骤
比如rac中,一般会要求停止nodeapps,instance,asm, 为了安全起见,也建议停止crs

2) 执行prereq CheckConflictAgainstOHWithDetail 检查补丁冲突
一般有两个情况, subset与conflict 都会在打补丁时回滚掉
subset不用关心,这说明这次要打的补丁包含了这个subset; 而conflict的补丁则要事先下载下来, 如果暂时没有,则提交SR申请补丁

3) 整理好打补丁的详细步骤, 反复check,并在测试环境运行通过
4) 开始打补丁, 打完后检查log, 检查补丁是否已经成功写入inventory, 这一步是可以rolling的
5) 更新数据字典/编译非法对像 --这一步因为需要open db来操作,无法rolling
有些psu需要修改数据字典

4, RAC中的rolling upgrade
这个地方的rolling仅仅只是指update 文件, make, relink阶段可以rolling; 而不是指更新数据字典阶段, 一定要注意这个区别

打补丁是个细活,事前一般要把方案做仔细,尽量全面测试各个步骤,老汤曾遇到过几个异常情况:
1 ) 在一个8节点的rac中,在update 库文件阶段非常慢, cpu很空,iowait严重 25%以上
发现是ar进程( 解压jar文件) 需要等io
而在同样配置的另一个8节点rac中打同样的psu,update库文件很则快, 猜测可能是cpu有缺陷

2) 在一个24节点rac上, 更新字典数据阶段非常慢
执行dbms_registry.loaded('AMD'); 时花了将近2小时, 发现session在执行各种数据字典表的统计信息收集任务,包括对ASH, AWR的一些的操作
而这个库是个数据仓库系统,有几百万个分区,对像非常多,所以字典表非常大. 那么每一个收集sql都需要跑较长的时间,加在一块时间就比较可观了

3) 在24节点的RAC上打psu3时,由于整个过程不用打crs的补丁, 所以没有停crs进程
在执行update库阶段,发现有个节点僵死了,等了一个多小时才启动成功, 这个节点错过了打patch的时间 (执行patch的进程无法远程cp文件到它上面)
而在随后打其它one off 补丁时, 由于那台机器已经ok, 最后一个one off 补丁成功打上去了

这里有2个问题,
a, 就是这个死掉的节点只打了一个补丁, 如何给它加上其它的?
b, $ORACLE_HOME/inventory/ContentsXML/comps.xml 被执行补丁进程的那个机器的comps.xml覆盖了
所以,当在这个节点上执行opatch脚本时会失败,因为它无法读取不存在的补丁记录

4) 打psu3时,先回滚psu2,而psu2中包含了某个patch,它解决了ORA-00600 [3619]
因为这个bug,DB不能open,必须recover database之后才能open (虽然gV$RECOVER_FILE中无任何文件需要恢复)
因为回滚了psu2,而在这个点上, psu3还没有打上 (要更新完字典了才算打上), 在这样一个'缺口'期, 这个bug会死灰复燃, 当进行到后面需要open db来更新字典( catbundle.sql)时,会报 ORA-00600 [3619], 这个时候需要recover database

所以, 有条件的情况下,最好将每个补丁的版本, apply的时间, 它解决了什么问题, 它被哪个包含,如果没有打上,如何绕过等关系记录下来,做到有据可查
当遇到问题时,才能做到有的放矢。[@more@]

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/26078027/viewspace-1052775/，如需转载，请注明出处，否则将追究法律责任。