3 Node ORACLE RAC项目手记

  • 3 Node ORACLE RAC项目手记
  • 前些时间做的项目,一直没有时间整理。目前好些,就整理一下过程文件。
        
      这个项目基本情况如下:
        
      原有2台IBM M85小机,Fastt500 盘柜,Oracle RAC数据库服务。
        
      新增加一台IBM P5 550小机放在2KM外的电信机房,增加2台HDS的盘柜,分别放在公司机房和电信机房,实现HDS的trueCopy.新项目改造后需求,3台小机实现Oracle的RAC数据库服务。
        
      开始我一直担心异地的HACMP对Oracle的RAC是否存在问题,由于没有先例和把握,只好做一步是一步了。后来证实这个担心是多余的。
        
      需求计划整个项目计划2个星期内完成。
        
      说明:
      公司机房--本地机房
      电信机房--远程机房
      本地机房小机2台M85:A机,B机 2cpu 4G 16G×2
      远程机房小机P5 550:C机 4CPU 8G 146G×2
        
      实施过程基本分为以下部分:
        
      我没有记录周详的安装步骤如AIX,HACMP,Oracle RAC安装流程等,不过碰到的问题都有记录,并有解决过程。
        
      1. 项目准备
        
      项目准备的主要工作是基本物料的准备和实施方案的确定。
        
      基本物料准备包括:机房条件检查,线缆统计和购买,相关介质准备。
        
      在机房检查过程中,发现远程机房UPS零地电压竟然70多,提出整改;由于本地机房和远程机房距离较远,中间是通过单模的光纤来连接的,因此需要设置单模的光纤跳线。
        
      实施方案确定:
        
      1.1 由于业务系统白天不能停,3台小机安装系统,设置HA,设置磁盘柜,安装OracleRAC这么多内容不可能在一个晚上完成。因此,必须考虑一套临时的过 渡数据库。经过讨论,决定将临时库安装在新设置的C机上。即需要在c机上安装2套Oracle数据库,一套临时的单实例版本,另外一套RAC版本。(主要 是c机的设置较高)
       
      1.2 由于本地机房和远程机房距离约2KM,无法实现串口的心跳线,因此只能通过IP网络或磁盘心跳。出于这个考虑,决定使用AIX 5204和HACMP 5.1版本,HACMP通过共享磁盘来实现心跳。规划IP地址等。
       
      1.3 由于原有的Oracle数据下有20多个用户,总约15G数据量,约300个连接数。而且数据分布也不合理,在system表空间中有用户数据,因此只能 通过全库级别的exp/imp来实现数据迁移(懒人的方法)。Oracle 版本定于Oracle 9201(这是个严重的失误,导致后来项目延期,问题多多)。(没有做物理备份)
       
      1.4 磁盘规划:盘柜中有2个LUN给Oracle RAC使用,大小都为100G,即总200G,全部设置为RAW设备,AIX中分别属于oravg1,oravg2.
       
      1.5 表空间设计:我看了一下原来的oracle,20多个用户中,数据主要集中在2个用户user1和user2。我就吧user1的表空间放在 oravg1,user2 的表空间放在oravg2。(后来证实这里犯了一个错误,导致IO出现瓶颈),同时对重要的表空间做LV的Mirror处理。
        
       
      2. 临时数据库系统准备和数据备份
       
      根据方案c机安装完成AIX和HACMP后,建立一个ora用户及划分50G空间给Ora用户,安装Oracle,建库,从A机exp全库,然后c机全库导入。比较顺利,一个晚上完成了,检查数据完整性后,第二天将业务就转换到了临时库上。
        
       
      3. 3台小机的AIX安装和HACMP设置
       
      A机、B机的AIX安装和HACMP安装设置基本没有什么大的问题,HDS的盘柜也非常顺利。
      AIX补丁:AIX 5204
      HACMP:最新
       
      HACMP5.1的设置还是安替换IP的方法设置,即IP替换而不是别名,由于做ORACLE 的RAC,相对来说HACMP比较简单,因为不必设置应用转换,只需要设置资源组共享就能了。我建立了2个VGravg1,oravg2都是 concurrent模式。只有一个资源组,包括了service ip,oravg1,oravg2.
       
      HACMP的心跳需要注意就是必须是ConCurrentVg的VG,此VG能存放数据,也就是说能和Oracle RAC存放的VG公用,我设置了oravg1。
       
      HACMP同步,测试启动HA,检查资源是否正常:
       
      lsvg -o (三机相同)
      rootvg
      oravg1
      oravg2
       
      netstat -in (service ip是否在线,每台机器都需要检查)
       
      正常后继续。
       
      这部分做了1天。
       
      HDS的TRUECOPY有HDS的工程师完成。

    4. Oracle RAC 安装和建库
        
      终于要开始安装Oracle RAC了,再次检查HACMP后开始安装Oracle。安装Oracle非常顺利,不过在建库的时候碰到了一些问题。
       
      建库LV准备:


      由于用户较多,因此需要的表空间也多,相对需要的LV也较多。LV建完成后将所有的Lv改Owner为Oracle

      #chown -R oracle:dba /dev/r_*

      #chown -R oracle:dba /dev/rr_*
       
      问题1:

      创建LV失败,告诉我说LV的名字超长。(小于12字符?忘记了)只好重新修改LV的脚本,重新建立LV。
       
      问题2:

      建库的时候,跳出个窗口告诉我PRKR-1064错误,说是共享的srvconfig设备无法访问。我试着在Oracle用户下执行srvconfig -init,报错,什么JAVA无法访问Rawdevices 如下:

      $srvconfig -init -f

      oracle.ops.mgmt.rawdevice.RawDeviceException: PRKR-1064 : General Exception in OCR

      at oracle.ops.mgmt.rawdevice.RawDeviceUtil.(RawDeviceUtil.java:136)

      at oracle.ops.mgmt.rawdevice.RawDeviceUtil.(RawDeviceUtil.java:2071)

      接着,我用dd命令测试:dd if=/dev/r_srvmconf of=/dev/null bs=8192

      分别在三台机器上执行,其中有一台报错,我一看属性,原来/var/opt/oracle/srvConfig.loc

      文件的属性错误,用chmod 777 srvConfig.loc后问题解决。
        
       
      小结:
       
      4.1 最佳通过脚本文件来做LV,这样万一出现问题,重做比较方便快捷。同时也减少出错的机会。

      4.2 另外,需要注意就是LV的名称长度有限制,最佳推荐使用Oracle例子的命名方式:如r_user01_1G,方便理解。

      4.3 一定要多做几个备用的LV,以备不时之需和以后扩表空间用。

      4.4 redo log文件一定要在建库的时候把相关的参数定好,如文件大小,每组有几个文件,一共多少组,否则会非常麻烦。

       4.5 注意每一个步骤,必须得每台机器上都做。
       
      这样,折腾了我2个晚上。
       
      5. Oracle 数据库迁移
        
      第二次数据迁移非常痛苦。一直EXP失败,后来发现buffer开得太(我开了1000000000)。
       
      IMP后导入成功,不过发现其他问题。
       
      这个折腾了我3个晚上。
        
       
      6. 出现问题,问题解决
       
      6.1 发现其中的A服务器CPU经常在100%,严重影响系统运行。检查了N多,都没有发现异常,最后A机重启后居然好了。没有办法解释。
       
      6.2 发现其中所有大表(500万)条记录只有只能在一个Node操作。现象如下:
       
      如果A机操作过A表,那么在B机或C机上查询一条A表得记录,得10多个小时(我狂倒),也就是更本无法查询A表。

      经过多方查证,基本确定是Oracle的一个BUG,于是下载9204,安装Patch。可是在安装Patch 9204到最后一步执行脚本root.sh得时候,其中A机
       
      执行了1个多小时更有完成,只好人工取消。(结果这里又留下隐患)。Patch完成,发现问题解决。
       
      6.3 升级到9204后,系统运行正常,回家。第三天客户报告说这2天得EXP导出都没有成功。网上一查,发现说使一个SQL得包没有正常运行。而且,运行那个包必须在特种模式下(migrate),也就是说必须得停库,只有晚上做。

      第二天晚上,我安说明,shutdown 库,startup migrate结果报错,说是RAC系统无法启动到Migrate下。没有办法,只好修改参数,cluster_database=false和PARALLEL_SERVER=false,然后:

      1. shutdown immedaite

      2. startup migrate

      3 @rdbms/admin/catpatch

       4. shutdown immedaite

      5. startup

      启动成功后将cluster_database=true和PARALLEL_SERVER=true
        
      6.4 发现磁盘IO非常不均,oravg1在Hdisk1经常100%,而oravg2在得hdisk2空得非常,检查后发现user1的业务量远大于 user2,虽然数据量差不多。所以说开始的时候设计出现问题了。还好,我在oravg2上有部分备用的LV,把他加了4G到user1的表空间,并把 user1的数据重新导出,导入后发现好多了。
        
      到这里,项目基本稳定了,不过其实事情更有非常多,如数据备份、带库、FAST T500等。
       
      项目后感:
       
      第一条:做事一定要仔细,最佳每一部都有记录,下破坏性的命令前一定要考虑后果;我用的是SecureCRT,我一般都会做Log记录,方便查询。

      第二条:碰到问题不要荒,其实目前这个信息这么发达的时代,我们碰到的大部分的问题都有解决方法,只是看怎么找到他。

      第三条:2个人出差比一个人好,尤其是后半夜,至少能有个商量的人,有时候其实问题非常简单,不过一个人容易走进死胡同(因为后半夜基本没有办法打电话)。当然老板不会那么好,每次都派2个人去。呵呵。
       
      第四条:碰到奇怪问题,如果真的穷途末路(黔驴技穷)了,那么restart机器或数据库等,也许有意外的收获,因为实事证实有一些问题是 没有道理的也无法解释的,不过重启能解决的。

你可能感兴趣的:(服务器)