前言
这次升级，前前后后总共耗费了十一个小时，从下午五点到凌晨四点，好在最终解决问题，才没有前功尽弃。按照用户的要求，这次要集中部署ORACLE RAC 10.2.0.4版本的测试环境，数据库数据文件、系统文件、日志文件、临时文件乃至系统参数文件一律使用裸设备，总计800GB。SGA、PGA共计44GB。每个实例占用系统CPU 16个，内存48GB。
事先实施的方案是在没有建库的情况下将clusterware以及数据库版本从10.2.0.1升级到10.2.0.4，再建库，划分表空间。但在升级完毕之后建库的时候遇到一个麻烦。因为数据量较大，对应的裸设备文件容量也大，比如sysaux和system就本别占用了6GB大小，还有一个520GB大小的表空间对应建立了52个裸设备文件，每个文件容量10GB。使用裸设备在DBCA下建库的时候系统报错，称不支持2GB以上的单个数据文件，左查右查没有找到行之有效的解决办法（系统参数和内核参数都没有做这方面的限制），认为是oracle 10.2.0.4的一个bug，所以只能将版本重降回10.2.0.3进行测试，果然就没有这方面的限制了。
于是乎，准备采取第二套方案，先在10.2.0.3版本下建库，划分表空间，再将ORACLE RAC升级到10.2.0.4。在这个过程中也遇到点麻烦，浪费了不少时间。之前在将10.2.0.4降到10.2.0.3的时候只降了clusterware而遗忘了database，版本不一致的问题导至建库完毕之后无法启动数据库，这时已是下午五点。而按照项目组的要求，整个实施过程必须在今天完成，也就是不能拖到第二天九点之前，加班是免不了的了，于是残酷的故事从这里开始……
整套升级方案是这样规划的：
1，关闭监听
2，关闭数据库
3，冷备数据库
4，升级clusterware补丁
5，升级database补丁
6，关闭副节点上crs
7，在主节点上进行非cluster模式下数据库升级
8，关闭主节点上crs
9，启动副节点上crs，在副节点上进行非cluster模式下数据库升级
10，重启两个节点的crs
11，进行版本的验证以及数据库运行情况的健康检查
阅读(2500) | 评论(0) | 转发(0) |
