从昨天开始,正式全程参与某客户的数据库系统升级工作。工作内容是将客户的关键应用从原先的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. 到今天为止没有更点儿背的事情发生,应用完全正常,宣告这次升级工作圆满结束。
Tag: Oracle Database
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。
深度解析Oracle 之 Redo & Undo
今天在东方标准完成第四次课程的讲授,题目是《深度解析Oracle 之 Redo & Undo》,Redo和Undo是Oracle之所以提供强大的可恢复性的基础,将Redo和Undo分开处理也同样提供了卓越的性能。 今天的讲座大概包括了以下几个部分: 1. 什么是Redo,什么是Undo 2. Redo和Undo如何在我们日常的数据库运作中互相合作的 3. 如何才能NOLOGGING 4. 事务的运行以及读一致性的实现 5. ORA-1555错误的产生已经处理方法 讲座的ppt可以在这里自由下载。 下周的课程交回给eygle手上,顺道恭喜eygle乔迁新居。