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机器或数据库等，也许有意外的收获，因为实事证实有一些问题是 没有道理的也无法解释的，不过重启能解决的。