How to install 10.2.0.3 CRS BUNDLE #1

安装完Oracle RAC 10.2.0.3之后,可以选择打上CRS BUNDLE #1 Patch(PatchID:6160398),这是一系列Patch的集合,不能简单地用“opatch apply”来完成。当然,其中的README文件详细描述了每一步应该怎么做。 这里只是说两件需要注意的事情。 1. 要打CRS BUNDLE #1 ,必须要先升级OPatch实用程序,至少要升级到10.2.0.3.3,因为Oracle 10.2.0.3自带的OPatch版本中没有napply这个命令。升级OPatch实用程序很简单,去Metalink上下载Patch 4898608,然后解压覆盖原先的OPatch目录就可以。 2. 仍然是OPatch的问题。必须将CRS_HOME和ORACLE_HOME中的OPatch目录都升级到10.2.0.3.3或者之后的版本,否则在Patch过程中给ORACLE_HOME打补丁的时候报如下错误。 UtilSession failed: Patch 6160398 requires component(s) that are not installed in OracleHome. These not-installed components are oracle.crs:10.2.0.3.0, OPatch failed with error code 73 虽然是作为Oracle的员工,还是得说,Oracle的Patch管理实在是有些不方便,大部分Patch都得靠眼睛去Metalink上找,找来以后还可能跟别的Patch冲突,然后还要去申请Merge Label Patch,总之是一个糟糕的体验。

Oracle9i upgrade to Oracle10g RAC

从昨天开始,正式全程参与某客户的数据库系统升级工作。工作内容是将客户的关键应用从原先的Oracle9.2.0.6单实例升级为Oracle 10.2.0.3 双实例RAC。 更加详细的工作内容包括: 1. 将原先存储在JFS2文件系统上的文件转移到GPFS中 2. 将原先单实例模式的Shareplex转换为RAC模式的Shareplex 3. 将原先的高级复制转换为简单的物化视图刷新 4. 使用Oracle Clusterware替代HACMP负责Shareplex资源的切换 总的来说,是一个很大的工程,数据库大小在800G左右,升级使用DBUA,单实例转换为RAC则使用rconfig实用程序。 工作的几个难点在于: 1. DBUA是否能顺利将Oracle 9.2.0.6升级为Oracle 10.2.0.3? 2. rconfig是否能顺利将单实例数据库转换为RAC数据库? 3. 能否正常在Oracle Clusterware中添加Shareplex资源并且保证在各种异常情况下顺利切换到另外一台主机上? 之前已经做过多次测试,希望这两天的正式升级会一帆风顺。 Update@2008-4-3 升级工作圆满结束,有惊无险。 1. 本来一直到rconfig转换单实例到RAC之前,整个进度都是提前了4个小时左右的,敲完rconfig的命令之后大家欢欣鼓舞地去开会,结果开完会回来发现rconfig失败了,一直处于悬停状态,整个主机没有任何负载,数据库实例也完全无法登录。根据回退方案将数据库重新转换为之前的单实例模式,成功启动完数据库以后,开始检查转换为RAC失败的原因。最后发现是ntp服务配置有问题,RAC两个节点的时间差异在1小时。重新调整ntp服务,然后再次转换,成功结束。此时,落后进度计划大概1个小时。 2. 后续的工作一帆风顺,应用上的几个问题也相继迅速地修改了,上线当天上午观察了一下主机情况,一切正常。于是中午就离开客户处了,没过2小时,客户电话说,机房忽然断电,所有设备全部意外down机 。。。我问UPS呢?客户说,就是一台UPS短路导致机房断电的。我FT。再赶回客户处,等着加电,幻想着加电以后GPFS文件系统全部损坏,然后再从带库恢复数据的凄惨景象。幸运的是,加电以后全部设备都安然启动,数据库也正常。Shareplex丢失了一部分数据,也都成功恢复。 3. 到今天为止没有更点儿背的事情发生,应用完全正常,宣告这次升级工作圆满结束。

Do we need HACMP?

上次在东方标准讲Oracle数据库存储的时候,曾经说过: 如果我们选择用纯裸设备来做Oracle10g RAC数据文件的话,那么在AIX平台就需要安装HACMP,在HP-UX平台就需要安装Service Guard。 这句话不完全正确,今天更正一下。 实际上无论在哪个操作系统(AIX,HP-UX,Solaris,Linux)上安装Oracle10g RAC都不再需要Vendor Clusterware(IBM的HACMP,HP的Service Guard,Veritas的VCS等),无论在存储方面是选择裸设备还是ASM或者是操作系统厂商提供的共享文件系统,比如AIX上的GPFS。 那么为什么提到AIX,如果一定要选择裸设备(此处提到的裸设备指纯裸设备,因为ASM实际上也是在管理裸设备)作为Oracle数据文件存储方式的话,我们建议安装HACMP呢?是因为AIX操作系统的特殊性,在AIX操作系统上,每个字符设备(对应一个rhdisk)只能对应一个存储上划分的LUN,而其它操作系统则可以在LUN上继续细分字符设备,比如LUN是128G,那么在AIX上每个rhdisk都只能是128G,每个rhdisk也就是一个裸设备,而其它操作系统则可以继续在这个LUN上划分出多个裸设备,大小可以自定义。 我们知道对于Oracle RAC来说,每个控制文件,每个联机重做日志文件,甚至spfile都要对应一个裸设备,那么如果在存储规划的时候我们创建了128G的LUN,那么在AIX上我们只能做成一个128G的控制文件,一个128G的联机重做日志文件,一个128G的spfile,因为单独依靠操作系统我们无法再细分了。 在AIX操作系统中,必须使用LVM(Logical Volume Manager)来划分LV(Logical Volume),每个LV的大小是可以控制的,在一个LUN上我们可以划分多个LV,因此在操作系统级别达到了规划存储的目的。此时HACMP的作用体现出来,如果要挂载Concurrent Volume Group(实际上不需要HACMP也可以创建LV和VG,但是却无法将VG设置为Concurrent模式,而非Concurrent模式的VG是无法被多个机器同时读写的),就必须安装HACMP,因此更严格地说,这种方式的存储应该称为Raw Logical Volumes,而不是Raw Disks,这两种都是Raw Devices。 实际上,如果我们在存储级别就详细规划LUN的大小,比如创建4个128M的LUN,1个给spfile用,3个给控制文件用,再创建8个256M的LUN,给8个联机重做日志用(4组,每组2个member),然后再继续规划用于SYSTEM表空间的,用于SYSAUX表空间的,用于UNDO表空间的,用于用户数据表空间的LUN分别是多大,那么也仍然可以不需要HACMP就在AIX上搭建起以纯裸设备为存储介质的Oracle10g RAC数据库。 结论是,因为Oracle Clusterware的存在,在本质上,无论选择什么存储方式,在任何操作系统上都不再需要第三方的集群软件。 最后再提一下ASM,对于ASM来说,底层可以是raw disks也可以是raw LVs,但是推荐是raw disks,因为本身ASM已经行使了类似于LVM的功能,因此无需再创建多余的LV了,而如果不选择ASM,那么就建议使用raw LVs。